|
| ERP Implementations Series |
Given their extensive scope, duration, investment and complexity, ERP
implementations are probably one of the most complex endeavors pursued by
organizations. Moreover, they are often a matter of endurance with many
junctions, skirts, turns, shortcuts, ups and downs, a continuous carousel in
which the various issues tend to misbehave like little monsters, many of them
haunting one’s dreams unexpectedly during and long after implementations.
Probably, the main drivers are the scale and mass of such projects as they
touch all or most important aspects of organizations. Just consider the
typical project done for a single department and multiply its complexity by a
constant number representing the number of departments in scope. And the more
one goes into details, the higher the complexity. To move forward the parties
need to compromise, and as no one wants to do that, the discussions are
prolonged, the discussions get personal, issues are escalated, and probably
more negative effects can be met.
Tensions can be rooted in politics, in the friction between different goals,
in the need to prioritize requirements, postponing or leaving things out of
scope, or by pushing an agenda other parties don't agree with. Besides the
typical constraints of projects, there’s the complexity of performing a huge
amount of work within a limited period, time during which the resources must
be available, the quality must match the expectations, and there are so many
aspects to be considered!
Of course, not all implementations are like this, though each such project is
a real exam of maturity for the people involved in it. Sometimes, it’s better
to have people who care about the decisions made. On the opposite side, there
are organizations that go almost blindly with the solutions suggested to them,
with all the effects resulting from this. Probably, the middle way between
these two extremes is more indicated, though it’s hard to find such a path
through all complexity.
An ERP implementation is highly dependent on the initial conditions under
which the project has started, the commitment made by the various parties
involved in the project, the way resources are made available, on what’s
considered in plan, on the communication that takes place, the planning done
and its enforcement, etc. Of course, some topics can be addressed also later,
though delays tend to create more delays that can have a ripple effect through
the project. Under normal circumstances the backlog and other aspects can be
manageable, though it’s enough for a few issues to gather momentum so that
their cumulative impact can have an exponential impact.
Certain sensitive project topics can easily lead to crises and abnormal
behavior, though such situations are usually exceptions (until they are not).
It’s important to have in place the processes and procedures that can be used
to address this kind of situation, and, not less important, have them
communicated to the team. Moreover, it’s not necessary to reinvent the wheel -
the processes defined in IT and project methodologies can be used and adapted
for this purpose.
It's important to have in place all the processes, procedures and checkpoints
needed to support the project. The people participating in a project should
have some hands-on experience with them, including the exceptions (e.g.
escalation procedures). It’s useful to have a mentor or some experienced
person who can help with advice and even attend meetings and provide
constructive feedback. Just having some awareness sessions with no feedback
can be as dangerous as not having any training at all! It’s suboptimal to use
the implementation itself as an environment for learning though in extremis
this approach may work as well.
No comments:
Post a Comment