In this issue, we’ll focus on the formation of the implementation team, who should be on the team, who not, what areas they’ll come from, and how to organize the team so the company isn’t driven off the proverbial cliff with no one at the wheel. Topics include:
- How NOT to create an implementation team
- Project leadership – selection and administration
- Selecting team members
- Success example story
How NOT to create an implementation team
To continue a recurring theme in this topic we touch once again on the CYA factor, and the importance of confronting it head-on. This same thought process should be carried over into selecting the team leadership and members. This kind of activity is overhead, extra baggage and waste of the first magnitude, and can in itself cause a project to fall short.
Remember – once the project is done, no one will care in the least who said what at a meeting, or what the basis for a minor decision as – only that it was successful, and if/where it is not, what is underway now to correct it. When serious CYA activity is going on, it is prima facie evidence that there is a lack of trust. When you find this going on, drag it and whatever “sacred cows” are involved out into the open, shine light on it with candid, honest discussion, then provide leadership and support to re-establish trust.
We mention this in the context of team formation because of far too many examples we’ve seen where teams were selected with the desire to absolve one’s self of blame of any sort for possible failure, not only of the implementation project, but of possible operational short-falls that could result from the implementation.
By identifying implementation team mistakes, we will concurrently illuminate their logical opposites, Best Practice team formation methods. Here are some of the bigger, yet surprisingly common mistakes companies make when assembling an implementation team.
- Have an external project manager – assign project management to a person who is an outsider, not in any way a part of the company’s success, failures, or culture. He/she will be an “expert” in a mysterious, dangerous process, but if/when it crashes, will be long gone.
- Depend heavily on external skills and resources - hire temps, consultants, people hired only for the project. This will make the internal people feel completely incapable of performing on their own, and thus remove ownership from it. Almost all huge implementation failures have this element in common.
- Reassign key internal people full time to the team – remove them from their daily jobs and responsibilities. This way, they cannot fully own the resulting success or evaluate risks. They will now be in “their own little world.” Meanwhile, life moves on in their former departments, new political alliances are formed, new in/out groups, and new “secret handshakes” created. They must “sell” everything they do to those still in their old departments and work groups. Challenges, high potential for difficulties and failure are virtually assured.
- Assign expendable people to the team – when department managers are asked to select people for implementation teams, it is VERY hard for them to select their best people – or even harder, to take the responsibility on themselves; they just feel way too overwhelmed. Further, they depend on their best people to keep things together, working well – vital for their own performance reviews, raises, etc. So, the “weakest link” is often selected. Once again, challenges, high probability for difficulties or failure are virtually assured.
- Create a large team - with many people on the team, they’ll have to spend a lot of time in meetings, communicating with each other, resolving disagreements, etc. This dramatically increases project overhead, adds confusion, decreases individual ownership. Once again... You can see where this leads – once again.
- Make a long schedule – allowing a long time for the team to prepare, convert and Go-Live greatly adds to the number of meetings, CYA projects, and changes in team members, none of which actually moves the implementation forward. When new people join the team, they have to “get up to speed” – all extra work, with no added value on the actual project itself. With a long project, the percentage of time devoted to status reporting, meetings, communications, reporting to top management, collaborative sessions with work groups, changes in business processes and strategy – all dramatically increase, thus once again – increasing the probability of difficulties or failure. A short, tight schedule may appear counter-intuitive, but it is a fact. A multi-year implementation project is almost assured of never succeeding fully, simply because of leadership changes, both within the company, and on the team alone.
This depressing “checklist” is included here, in an otherwise positive-oriented set of guidelines specifically because we, and others, have so frequently seen them in actual practice. Although it is widely known that implementation projects are risky, what is NOT so widely discussed are the causes of the risks. We’ve just covered some of the major ones – where problems or failure were almost built-in from the start.
To take an example – sky-diving – the act of jumping out of a perfectly good airplane couple of miles above the earth’s surface, would appear to be highly risky, and it is, if you aren’t prepared. Just “going for it,” in this situation can and has resulted in a greatly shortened life span. Similarly, in a complex business change, i.e., software implementation, rigorous planning, preparation, education and training virtually eliminate risks, just as it does in sky-diving. And high blood levels of testosterone won’t bridge the gap.
This depressing “checklist” is included here, in an otherwise positive-oriented set of guidelines specifically because we, and others, have so frequently seen them in actual practice. Although it is widely known that implementation projects are risky, what is NOT so widely discussed are the causes of the risks. We’ve just covered some of the major ones – where problems or failure were almost built-in from the start.
To take an example – sky-diving – the act of jumping out of a perfectly good airplane couple of miles above the earth’s surface, would appear to be highly risky, and it is, if you aren’t prepared. Just “going for it,” in this situation can and has resulted in a greatly shortened life span. Similarly, in a complex business change, i.e., software implementation, rigorous planning, preparation, education and training virtually eliminate risks, just as it does in sky-diving. And high blood levels of testosterone won’t bridge the gap.
Project Leadership – selection and administration
Strong, internal project leader – Select a key leader, not “manager”. A key hands-on executive or relatively senior manager (not the IT manager) should take this role – he/she will be a powerful force for ownership. Here’s how to keep from overwhelming this person:
- Add project administration – provide a full-time project administrative assistant to the leader – most of the project management work can be handled by a capable assistant. The most time intensive part is gathering status information, preparing reports, presentations. o ·
- Add key role deputy – assign a capable deputy, a fully-capable “stand-in” who can, if/when needed for the functional manager serving in the project leader role. This can and will off-load the leader, so he can have enough time to effectively lead the implementation project, while remaining effective in his / her primary functional role – essential for full ownership.
We have found there is frequently a lot of confusion over the roles of project leadership, management and administration. Leadership is clearly the most powerful and critical, yet most of the time for getting a project to move forward is devoted to administrative work.
Keeping the project leadership securely in his/her power base of a key line management role insures that reality is an integral part of the change/implementation process and keeps ownership solidly in place as well. The Best Practice here is to select a real, effective leader, keep that person in their primary job, while providing supplementary support to back-fill the person in their primary leadership role, while off-loading as much of the project administrative work as possible.
This strategy allows the project leader to truly be physically and emotionally able to continue to provide leadership in the primary business role, yet also effectively lead the change process for the company, including his/her own work area as well at the same time.
Selecting team members
In the NOT to do it discussion, we eliminated many of the most common, yet failure-driving ways to create an implementation team. Similarly, the theme of hands-on, leadership based individuals who are capable of the degree of ownership of the results in their own work areas, plus the implementation team we can concisely summarize how the team should be assembled and who should be on the team:
- Strong, functional managers as team members – everywhere possible, assign a strong manager for team membership, one who exhibits real leadership characteristics, more than just someone who really knows the functional area. Follow the same guidelines described above for insuring that these people have enough time to effectively carry the dual responsibilities of their functional management role plus the implementation project role. Off-load and support them in their regular job role to allow quality, effective time for the implementation project.
- Keep the team small – a highly focused, tight, small team of intensely motivated people who really know what they want to accomplish, will move mountains, quickly to get it done. Communication lines will, on a small, tight team, be short, concise, and trust-filled.
- Continuity – ideally, the implementation is the same team that performed the “as-is” and “to-be” business process analysis, and which thoroughly understands the business strategy and its critical success factors.
Note the common thread of ownership – the before and after work, having people remain in their line roles, and keeping communication and responsibility lines within the team short and effective, with a minimum of overhead. And, of course always selecting people who exhibit real leadership qualities. This “follow-me,” lead by example method has proven very, very effective in countless situations of change within work groups. A solid leader helps people feel relatively safe and secure in the midst of change, potential confusion and what they feel will be the chance of mistakes.
Success Example
One company we are familiar with, a $ 50 million/year high tech manufacturing company, was unable to utilize much of its implementation consulting budget that it had planned. The company is highly customer focused, with many short-notice on-site visits by key customers. Consulting resources from the software company had to be scheduled in advance, and frequently were cancelled at the last minute, or went under-utilized while they were on-site.
This forced the management to “do it themselves” – using Webinar and conference calls to tap into outside expertise just for educational purposes, so they could learn what was needed. Since they were working nights and weekends, they really wanted to get it done soon, yet since the team was entirely composed of key line managers, making sure it went well was critical.
As a result, all of the planned functions in the new system went into live use only a few months after starting, with only a small portion of the external consulting support that had been planned being utilized.
This simple example illustrates the key points involved in Best Practice implementations – all centered around maintaining effective ownership of the before and To-Be processes, and all steps between the two. In this instance, the company’s leadership was able to simultaneously keep things moving well in their work groups while moving the implementation forward, without the off-loading and back-filling steps recommended above. However, in a larger company, this may not have been possible – the additional work would be more than could be handled by some evenings and weekend work.
In our next issues, we’ll continue the implementation discussion, moving onto the topics of education and training, and the all-important conference room pilot.
If you like this article and think it's helpful, please spread the word and digg it.
-
No comments:
Post a Comment