|
By
Paul Deis, CEO, PROACTION
Article Summary:
In the previous newsletter’s feature article, we
focused our attention on the “front-end” of the
implementation project. This included how to
establish meaningful ownership of the project, how
critical real, effective leadership is, and the
pivotal issue of setting up clear, unambiguous top
management support, involvement and communication.
When these are consistent with Best Practices, the
implementation team is operating in a zero or
low-risk field – they can stick out there necks, own
their work, be fact based (not “politically”
oriented), with little or no CYA activity. The
focus is instead on getting everything in place
solidly, getting it “right” and effectively
identifying and resolving all potential problem
areas.
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
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.
o |
|
· |
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.
o |
|
· |
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.
o |
|
· |
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.
o |
|
· |
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.
o |
|
· |
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.
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.
o |
|
· |
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.
o |
|
· |
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.
We welcome your feedback and comments. Send us your
questions and we’ll answer them in a future
Newsletter. Please type in the address.
 |
Paul
Deis
