ERP
Project Management Is Key To A Successful Implementation
By
Charles Trepper
Enterprise Resource
Planning (ERP) systems have fundamentally changed the work of IT
organizations. The sheer size and complexity of ERP implementations makes
managing these projects difficult. There are really two basic sides to ERP
management, people and technology. An ERP package touches the entire
organization and can affect nearly every employee. And in some cases, an
ERP project manager may not be able to know who will be affected, which
can lead to some nasty surprises. One mismanaged ERP implementation left a
southeastern electronics manufacturer unable to accept deliveries and
nearly closed a plant.
It's also difficult to get a clear vision of the technological portion
of the implementation because of the vast combination of hardware and
software involved. The project manager must cope with thousands of parts.
Whether you are implementing one module or multiple modules, you must
ensure consistency and full integration across the various subprojects,
which is an enormous effort, even for an experienced system architect.
I did an informal survey of experienced ERP project managers from
various corporate IT departments and Big 5 consulting companies, and
assembled an unofficial list of the major problems faced by ERP project
leads and managers. Almost everyone mentioned size first. Staff problems
and organizational politics also ranked in the top ten.
| Rank |
Issue |
| 1 |
Project Size |
| 2 |
Staffing (Includes Turnover) |
| 3 |
Risk Management |
| 4 |
Unreasonable Deadlines |
| 5 |
Funding |
| 6 |
Organizational Politics |
| 7 |
Scope Creep |
| 8 |
Unexpected Gaps |
| 9 |
Interfaces |
| 10 |
Resistance To
Change |
According to the Eden Prairie, Minnesota Gartner Institute (a spin-off
of the Gartner Group), the gap between the promise of an ERP system and
the business value actually delivered once the project has been deployed
is great. Enormous cost overruns, deadlines missed in some cases by years,
and even abandoned implementations make clear that managing ERP projects
is a complex task.
Successful Project Management
Perhaps
the single most decisive element of ERP success or failure is the
knowledge, skills, abilities, and experience of the project manager. An
ERP project manager must understand both the business and the technology.
To avoid customization, businesses frequently change their business
processes to fit the new software. An ERP project manager must understand
the impact of the ERP implementation on the business, and work with
business managers to ensure a smooth transition from the "as is" to the
"to be" business operating environment.
To help educate project managers, The Gartner Institute created a
project management certification program that includes an ERP specialty.
The program and its courses focus on the critical issues that make ERP
projects different from typical application development projects. This
includes planning for the unusually large risk and complex
cross-functional issues that accompany most ERP projects.
Using the findings from an on-going Gartner Institute research study,
which involves brainstorming sessions with experienced project managers,
the course provides the core project management techniques that account
for the success or failure of ERP projects. Some core topics include
gathering business requirements, blended workforce project organization,
entry-, exit-, and acceptance criteria issues, change control and closure.
The Gartner Institute also includes risk management, project planning, and
scope management as major tasks for project managers.
A project manager must be flexible enough to roll with the changes as
the project progresses, and not lose it when unpleasant surprises pop up
as they always do during ERP implementations. They must be able to work
with nearly every individual in the organization, from the most technical
IT staffer or plant engineer, to the mailroom and building maintenance
staff. They must also possess the ability to learn extremely fast, because
they will need to understand business issues in areas of the organization
with which they are unfamiliar.
An ERP project manager must also be highly disciplined. They must be
able to clearly envision the project end game, and then hold the entire
organization to the road that leads to that successful end. This means
bringing other team members back on track when deviations occur or
distractions arise. They must also be willing to make tough decisions, and
understand that those decisions will upset some and please others. A thick
skin is certainly an asset.
Successful Project Manager
Characteristics
A successful ERP project manager…
- is flexible
- is disciplined
- is a quick learner
- is a good decision maker
- has ERP experience
- has business experience
- has political clout
- has a good formal education
- is well liked
- motivates staff
Source: Gartner
Institute. |
Deciding On Project Scope
Scope
management procedures must also be created and enforced to prevent "never
ending project" syndrome. Constant scope changes, whether increases or
decreases, cause confusion among project team members. The primary focus
of scope management is on defining and controlling what is and is not
included in the project. The project manager must work with other
departments to clearly define the project scope. If the project scope is
not defined properly, required work is missed, jeopardizing the project
success. On the flip side, work outside the scope of the project may be
done, hurting the budget.
The scope of an ERP project has several components. The ERP project
team must decided which business processes will be included in the
implementation. This decision, in turn, effects which ERP functionality
will be implemented. If an organization has more than one business unit or
line, the team must decide which divisions to include in each phase of the
rollout. The IT organization must determine which technologies will be
replaced and upgraded, and which will exchange data through interfaces,
until the rollout is complete.
To prevent scope problems, make sure a project charter or mission
statement exists. Be sure to really nail down the project requirements,
and have them documented and signed by the users and senior management.
Clearly define change control procedures and hold everyone to them. Tight
change control procedures may end up causing tension between the project
team and those who do not get changes they want. Ultimately, though, the
project can't be successful if the project team is trying to hit a
constantly moving target.
| Managing
Risk on ERP Projects |
| Managing risk on an ERP
project is crucial to its success. What is a risk? Simply
defined, a risk is a potential failure point. There are
thousands, maybe even millions of potential failure points on
an ERP project, in the form of untested technology (and
untested staff!), political landmines, and even nature's fury.
(A tornado during an ERP weekend go live? Yes, it's happened.)
So, how do you keep the failures at bay? While various risk
management books and methodologies offer variations on a
theme, there are generally 5 steps to managing risk:
| 1. |
Find potential failure points or
risks |
| 2. |
Analyze the potential failure points to
determine the damage they might do |
| 3. |
Assess the probability of the failure
occurring |
| 4. |
Based on the first three factors,
prioritize the risks |
| 5. |
Mitigate the risks through whatever
action is necessary |
Project team members must rely on their
experience and advice from others to find potential failure
points or risks. Track through the entire project plan and
look for areas of uncertainty. One of the easiest and most
effective ways to find potential failure points is to talk to
other organizations that have done the same projects. Cost
estimates are probably the most common potential project
failure point. Other potential failure points include lack of
an executive sponsor, an underqualified project manager, and
no clear objectives for the project.
The next step is to determine the severity of the potential
failure on the budget, project timeline, or the users'
requirements. Assessing the likely impact and the probability
of the failure occurring is more art than science, requiring
in-depth knowledge of both the ERP package and the business. A
risk management team should be built that brings together
those individuals that have the knowledge and experience to
know what might happen. This team must have experience in
implementing the specific ERP package for an organization
approximately the same size and in the same industry as yours.
Based on the first two factors, prioritize the risks.
Decide which risks should be eliminated completely, because of
potential for heavy impact on critical business processes. Set
up a monitoring plan for risks that should have regular
management attention. Make the entire team aware of those
risks sufficiently minor to avoid detailed management
attention, but which the team should watch for potential
problems.
You mitigate risks by reducing either the probability or
the impact. The probability can be reduced by action up front
to ensure that a particular risk is reduced. The project risk
plan should include a set of steps to recover from each risk,
should failure occur. The team must know the person
accountable for recovery from each specific risk, and the
action to be taken to resolve it. The team must know the
symptoms of the impending failure, and act to prevent it from
occurring if possible. An example is to test a particular
operating system or hardware component to prove that works
prior to go live. Doing a pilot implementation or prototyping
the first set of ERP interfaces are both examples of risk
mitigation.
| | Discovering Gaps
No software, no matter how big and
sophisticated fits every organization perfectly. And although ERP vendors
will tell you that their software will solve all your problems, there will
still be gaps. These gaps may be small, or extremely large and
problematic. ERP project managers frequently run into political minefields
when doing gap analyses. The main problem is that each time a gap is
identified that costs additional dollars to fix, someone, somewhere in the
organization is going to ask, "Why did we spend all that money if the
software doesn't do what we need?" This can cause the executive sponsors
to look bad, and push back at the project manager to "make the gaps go
away." This, in turn, leads to user frustration and dissatisfaction with
the rollout.
To solve this problem, be extremely thorough in the package selection
process, and make sure everyone at every level knows what the software can
and can't do. Start creating a gap document early, because the gap
analysis document is very useful for stakeholder management. It provides
direction on project management, and provides a clear knowledge of what
will need to be done. The review of gaps and design of the adapted
implementation program should detail the change scope, cost, and benefit,
as well as the adapted project plan.
The Right Staff
It's absolutely critical
to get the right people involved early. Leaving out the wrong person has
both project-related and political implications. A project manager must
look at the scope of the project beyond the ERP software itself, and
examine the interfaces to be built. Each business area with which the ERP
software will communicate must be involved. There's often a tendency to
develop "tunnel vision," where the ERP implementation team only works with
those users and organizational staff immediately involved with the
rollout. Invariably, the project team discovers that a critical piece of
knowledge is missing because they didn't get the right person involved
early.
Of course, one of the major issues with any IT project is the staffing
issue. Good technology staff, particularly those with deep ERP experience
are extremely hard to find. Since it's difficult to transition ERP team
members on and off projects, it's a good idea to identify staff members
that are critical but are high turnover risks early in the project. A
project manager can develop recognition programs that help retention. ERP
projects can be long and frustrating so it's also helpful to set up events
for employees to communicate and vent about the working environment.
Another trend is to implement flextime to allow employees greater
flexibility in setting work hours within limits. Some studies show that
flextime results in significant productivity increase and employee
satisfaction.
Preventing Brain Drain
Another problem
faced by ERP project managers is the need to integrate consultants with
corporate staff and ensure a smooth knowledge transfer when the
consultants leave. One large midwestern food producer solved the problem
by pairing up consultants with corporate employees in both technology and
business areas. The consultants and corporate staff worked side-by-side
throughout the implementation. This helped ensure a nearly constant flow
information from consultants to corporate staff, and prevented the
"knowledge drain" that usually occurs when consultants roll off projects.
Project Scheduling
Scheduling and
organizing ERP projects is like herding cats. You have lots of people,
lots of subprojects, and many potentially conflicting political and
organizational issues. It's extremely important to consider all of the
issues and develop a clear, concise, and thorough project plan before
starting the implementation. An expert project manager creates a plan that
addresses the major issues, and is flexible enough to change as the
project hits the inevitable bumps in the road.
One of the major problems with scheduling large projects is accounting
for time issues with people assigned to the project. These must be
identified in the schedule. The proper dependencies and human resources
should be requested prior to creating and dating activities in the
schedule. It's also important to account for vacations, sick days, and
other leave that frequently takes people away from the project
unexpectedly. A critical path analysis should also be performed on the
project schedule, to determine any potential "show stoppers". A critical
path analysis determines which resources absolutely must be present at
certain times in the project for it to succeed. For example, if the
database for a new ERP system will be built on Tuesday, then the database
administrator (DBA) must be there on Tuesday to do the work. In this case,
the DBA is the critical path person for the database build task.
Interfacing With Other Systems
An ERP
system typically becomes the "center of the universe" for the organization
when it's implemented. However, because of gaps in the functionality, time
constraints, and political issues, there are usually many interfaces to
other systems. Interfacing with legacy data may involve connections to all
mainframes, Unix, Windows NT, and other systems. The interfaces must have
the ability to handle complex data sources and legacy data types. Other
client/server systems must also exchange data with the ERP system. The ERP
software may interface with external business partners via electronic data
interchange (EDI) or electronic funds transfer (EFT) protocols. With
e-commerce on the rise, ERP systems must also be able to send and receive
data over the web, particularly in those organizations involved with
electronic commerce.
Managing the discovery, analysis, design, and implementation of
interfaces can be a nightmare. The data translation and movement
requirements alone can cost tens of thousands of dollars. One large
midwestern food producer needed a team of 4 people for nearly 3 months to
design a set of interfaces for one client/server system. Scope management
can help here. The project manager can prioritize interfaces so that
mission critical systems engaged in daily processing can exchange data
when the ERP software is implemented. Interfaces to systems that do
periodic processing- monthly or year-end-can be completed after the
initial implementation. Work must be properly prioritized, and ERP team
members must focus on immediate needs.
Typical ERP Interfaces
| Interface |
Typical Data Types Exchanged |
| Legacy |
Mostly historical financial data not
converted |
| Client/server |
Sales automation and reporting data |
| Other ERP/MRP/MRP II |
Transaction data from specialized systems (e.g.
manufacturing) |
| Data Warehouse |
Large volumes of historical reporting and decision
support data |
| External - Business Partners |
Transaction data including purchasing/sales, EDI,
EFT |
| External - Web |
Customer information, web-enabled
databases |
Monitoring Progress
"Riding herd on the
cats" means using compassionate micromanagement. While it's generally a
bad idea for project managers to try and do everything themselves, they
must create very specific work assignments for software developers.
Project managers should schedule technical and management reviews at least
once a week and track progress carefully against the original plan. It's
also important to do a project review at the end of each phase and the
project as a whole.
Success criteria for ERP projects are frequently inadequate or even
non-existent. The success criteria should be clearly defined in the
procedures, methods, and techniques that are part of a high quality
project control system. Standards and techniques for measuring the quality
of performance expected from the new system should be defined early, and
redefined as needed over the life of the project. If success measures are
obsolete at the end of the project, then the project can't be evaluated as
a success, and may be seen as a waste of money. And who wants to waste $50
million?
Managing Chaos
Managing an ERP project
is unlike any other effort because of the huge number of variables, people
and risks involved. The complete replacement of an organization's
information systems has a tremendous impact on the people in the
organization, the company, its suppliers and even its customers. An ERP
project manager must guide the project with a firm, practiced hand that
both encourages project team members to find new ways to innovate, and at
the same time, ensures that everyone and everything is moving in the right
direction. An ERP project manager must possess an intimate understanding
of the business and how it will change when the ERP system is rolled out,
and must also have a solid technical foundation. Anybody seen a cape and
some tights around here somewhere?
Charles Trepper is a consultant specializing in project management and
training issuse. He can be reached at chtrepper@uswest.net
|