|
By
Paul Deis, CEO, PROACTION
Download Article - PDF Version
Article Summary:
The preparation process – i.e., the “front-end” of a
Best Practice enterprise software implementation
project sets the basis for what follows. This
article explains the common thread of ownership and
effective leadership upon which a successful,
low-risk implementation project is based. In a
subsequent article, we will discuss the Best
Practice way of organizing and preparing the
implementation team, and then in a third article,
the activities of the implementation team –
conference room pilot, go-live preparations and
support. Topics:
-
Background and context factors
-
Ownership – the overriding principle
-
Leadership – key best practice
-
Top management interface
Background and context factors
Few business areas seem to be so risk-filled as
implementation of new Enterprise software systems.
Research has shown consistently that more than 70%
of all ERP system implementation result in one form
of short-fall or another, ranging from acceptable
performance with no real measurable benefit but at a
higher operating cost, down through several
gradations of difficulty to outright failure.
Collapse or bankruptcy does occasionally result,
although rare.
A
sane business leader reads these research findings
and thinks “Yikes! Do we have to do this?
There must be a way to reduce or eliminate
this terrible risk, isn’t there?”
Fortunately, there most definitely is.
Understanding and following proven Best Practices
can and will lead to an almost zero-risk
implementation project. These are NOT a mystery,
although if one doesn’t know about them, they are.
Absent proper preparation, implementations become
the business equivalent of just jumping out of a
perfectly good airplane and hoping that your
parachute will open OK. “Banzai!” is not a Best
Practice.
In this first of three articles, we discuss the Best
Practice way to prepare for an implementation
project. This involves understanding the common
thread of ownership and leadership that runs through
all facets of successful implementation projects.
Ownership – The Overriding Principle
At every level in a Best Practice implementation
project there is the principle of ownership. The
project that comprises the implementation is, itself
a process – one that results in a slew of other
processes. This means that the project manager, the
team members, and adjunct participants such as those
in functional work groups whose role is to interface
with the implementation team – all of these
individuals must feel the ownership of their
tasks, that it is their job to see it through
to successful completion, and to work as a team to
bring this about.
The principle of ownership and its importance can
hardly be overemphasized. Here is why:
|
· |
Risk
mitigation - The
team will not just “jump off the cliff”
blindly. They’ll move when they are ready –
because it is their project, their
success.
o |
|
· |
Details –
ownership helps insure that participants are
truly paying attention to relevant details –
and ignoring irrelevant ones.
o |
|
· |
Education and training
– when non-owners attend classes, one is
lucky if they a) show up, b) stay awake, c)
retain much. In contrast, if it is my
project, my success at stake, I
will pay attention and make sure
I retain everything I need.
o |
|
· |
Preparation for Go-Live
– a goal driven team that owns the outcome,
the success, will not agree to a go-live
until they know they are truly
ready. At this point, the risk of failure
or serious problems is virtually zero.
o |
|
· |
Painless transition
– if the team owns its success, and is
prepared, the Go-Live is almost just another
work day. There is little or no
additional re-training
of everyone, because they are prepared,
looking forward to working with a new,
better system and work flows. |
Leadership – Key Best Practice
When a team of change agents, which is what an
implementation team is, is organized, it is vital
that, at the very start, that top management display
real leadership – backing the team’s efforts, making
sure everyone in the company understands their role,
its importance, and that management is “in the boat”
with the team – and will succeed or fail with
the team. The oldest project joke is that the
most important task at the start is to “figure out
who to blame when it fails.” Unfortunately, this is
what happens all too often. Make sure there isn’t
even a suggestion that this could happen and your
project will go well.
Experience – remember that most people on a project
team have, at most, participated in one, perhaps two
implementation projects in their career. This is
OK, normal, but needs to be factored in. They are
learning both how to do this one, and how to
do them in an overall sense.
The Machiavelli principle – implementation projects
“establish a new order” which has long been
identified as carrying high risk to its leader – one
where there are few friends, and many enemies. In
many of the unfortunate situations the project
management ends up consistently in a defensive
posture, working in a conflicted state where each
step forward exposes the manager to more criticism,
opposition, and various fears.
Bearing this principle in mind, senior management
can, in effect, “shield” the project manager by
providing solid, consistent backing. This must go
beyond just budget to clear, explicit leadership via
words and deeds that clearly show support and an
intention to share all risks associated with the
changes being made.
If there is even a hint by top management
that, in the event of a short-fall in the project
that “heads will roll,” everyone will take cover,
and the project will soon make no steps forward
without solid CYA material in place, greatly
hampering its effectiveness.
Top Management
Interface
Every major project in a mid to large sized company
needs a process to connect it with the CEO, ideally
the Board of Directors, key investors, and C-level
executives. There are several ways to accomplish
this, such as:
|
· |
Executive Management Team (EMT)
– in mid-sized or smaller companies, the
project leader can just interface directly
with the executive top management team.
This provides an immediacy and a reality to
the endeavor, as the EMT is fairly closely
involved, and must understand and concur
with all major issues, resolutions and
decisions.
o |
|
· |
Steering Committee
– these can be very effective, or not,
depending on how they are constituted, their
charter, and how they are led and operated.
We define a Steering Committee as an
appointed group of senior level executives,
either a mix of “C” level and below, or
managers who are most affected by the
project. Typically these are not the EMT,
but are appointed by the EMT to function in
their behalf. Hazards with Steering
Committees:
o |
|
|
· |
Disconnected from top management
– since the project SHOULD be tightly tied
to the company’s business strategy, having
an additional reporting layer (read: “insulation layer”)
allows the EMT the costly luxury of
imagining that they don’t need to be
concerned with it, never a good idea.
o |
|
|
· |
Second-guessing / excessive approvals
– a poorly led steering committee will
require the project manager and his / her
team to review each detail with the
committee at its (monthly) meetings, until
they fully understand it, then approve it.
This severely hobbles forward progress,
needless to say. It occurs when there is
weak or no trust of the judgment of the project manager and
the team. The trust issue should be
addressed head-on, here as in all other
circumstances where it occurs and changes
made so trust can function – this is the
only way true, effective delegation can
occur.
o |
|
|
· |
“No-shows”
– key managers may miss meetings delaying
key decisions, or producing “I’m not
involved” attitudes in the missing manager’s
mind. It can also foster an attitude of
“abdication” instead of delegation.
o |
|
· |
Single Senior Executive Responsibility
– if the single executive is the CEO or
President, this can work, unless his/her
availability and access is very limited,
typically the case. More likely, if the CEO
says “I’ll manage this myself” it is a case
of inability to delegate, which of course
severely hampers the project.
Alternatively, if another senior executive
assumes this role, it CAN be very
effective. While there are some great
exceptions, generally this should not be the
CFO, unless the person in this role is
unusually operationally oriented. Otherwise
it’s like having the CFO have reporting
responsibility for all of IT. The financial
function, in too many of these cases, ends
up with everything it needs, while the
operational functions wait, or worse, are
starved of budget and leadership. When in
doubt, remember the objective of the project
– to improve (operational) performance of
the business. |
Summary of Factors
– in the area of project leadership interfacing with
the top management of the company, as we’ve seen,
the mechanism or process used is not the major
factor – it is how it is run or used that determines
success. Some guidelines for a Best Practice
executive interface:
|
· |
Keep the goal in mind
– The goal here is a fast-moving, low-cost
process that transitions the company from
operating with its current systems and
processes, to a new one. Everything that
aids this process adds value to it, and
activities and actions that do not subtract
or are just waste – expensive waste. A Best
Practice, of course, is to constantly strive
to improve this, as with other processes by
eliminating waste and improving quality.
o |
|
· |
Summary level reporting only
– one big time/cost waster is elaborate
PowerPoint presentations and reports, which
don’t add value. One of our favorite report
Best Practices is that of a major global
corporation. You are limited to one 11 x 17
piece of paper, both sides, but can do
anything you want with it. This is the
paper equivalent of the “stand-up” meeting –
key issues only.
o |
|
· |
Frequent is better
– more frequent, short, informal, summary
level meetings which focus on unresolved
issues that need top management involvement,
budget, time-line, schedule, or resource
issues. This allows the project to move
fast, change plans and directions quickly,
without having get bogged down in the “why
did the plan change?” kind of discussion, a
waste of time.
o |
|
· |
Confront CYA head-on
– inherent in this kind of reporting
structure and project is the desire to look
good, look like you knew what was going on
from the start, etc. The evidence that CYA
forces are operating is when one sees an
expansion of presentation materials,
reports, minutes of meetings, emails and
memos to “document” discussions and
decisions, multi-media presentations, and
other time-consuming items that do not move
the project ahead. Once the project is
done, none of this will matter and the extra
baggage can, itself, cause the project to
not meet its objectives.
|
In the next installment we will discuss how to form
and prepare a successful implementation project team
– how to select the team members, and the education
and training component both for the team members,
and others in the organization.
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
Subscribe To Proaction's RSS Feed
