Effective Project Management in ERP Implementation

The sheer size and complexity of ERP implementations makes managing these projects difficult.
ERP management involves mainly two things, people and technology. An ERP package impacts
the entire organization and can affect nearly every employee in the organization. And in some
cases, it will not be possible to know who will be affected and how, which can lead to many
problems. It is also hard to get a clear vision of the technological portion of the implementation
because of the combination of hardware and software involved. Irrespective of whether one
module or multiple modules are being implemented, one must ensure consistency and full
integration across the various subprojects, which is an enormous effort.

Perhaps the single most decisive element of ERP success or failure is the knowledge, skills,
abilities, and experience involved in project management. 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.

A project manager must have certain charctersistics if he is to pull off a successful

implementation. A few of these are

1. Flexibility to roll with the changes as the project progresses.

2. They must be able to work with nearly every individual in the organization

3. They must 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.

4. 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.

In order for efficient project management, one must understand the main activities involved in
ERP Implementation. The main activities that help to achieve an efficient and streamlined ERP
project are (2) (3)
1. Embrace Overall Goals and Objectives

The main questions to ask in this phase are

What is the project trying to achieve?- Why are we doing this?- What is the payback going to
be?

It is imperative that senior management defines these objectives and embraces the project up
front. This is usually done by forming a steering committee composed of senior executives to
drive these goals and objectives. The executive steering committee has two functions. The
first is to advise and act as a sounding board for the ERP project team. The second is to help
with the resolution of issues that cannot be settled by the ERP project team.

One of the main reasons for failures of ERP projects is caused by the lack of direction and
support by senior management. Senior management must provide the oversight and support
required to make the project successful. The goals and objectives must be disseminated
through the organization and become well known to all levels of the organization. The goals
and objectives should be put into a formal project charter before the project begins.

The Project Charter is a document that should basically state in concise terms: what the goals
and objectives of the ERP project are, who is responsible for the outcome of these objectives,
who will participate in the project, what the timeframe will be, a list of deliverables, what are
the project policies and procedures, and how will people know when the project is
completed. The project charter becomes the formalization of the first activity.

2. Defining Requirements

ERP implementations are the designing of the information system for a business. If the
requirements are not defined in advance and well understood, the result may turn out to be a
composite of what other people think the system should be rather than what is right for the
business.

Defining requirements should consist of an overview of how the new system will function, a
list of specific required business functions and processes that must be able to be performed in
the new system, and finally the policies and procedures that will need to be in place to
support the new system. Input will be required from many parts of the organizations to fill in
the detailed requirements (similar to Software Requirement Specifications document). It is
this input from throughout the organization that makes the requirements reflective of the
organization. The defining of the project charter and defining of requirements should be
completed before the ERP project is officially started.

3. Review As Is and Create To Be

It is necessary to make sure that all business processes are in place and supported with
documentation before the ERP system is implemented. To construct processes to either
support software after the implementation, or to design business processes during
implementation is a clear recipe for disaster. “Review As Is/Create To Be” means to review
the current business processes (As Is) and define any desired changes or new processes (To
Be) that the organization would like to put into place. Reviewing As-Is processes serves two
major purposes. The first is that gaps in existing functionality and missing processes come to
light. This exercise can be considered a gap-analysis for comparison with the To-Be design.
This forces to the forefront any processes or procedures that conflict with the business and
gives visibility to make sure that any new process are compatible.

The second phase of this exercise is to define the To-Be i.e. the way the functionality of the
system will interface with the business processes. This is where the possibilities of the new
system come into reality. It is at this point in the project that the users of the system can put
forward their ideas on how the system should be.

4. Use of Education and Training

The training that is provided by the software vendor is one of the most critical elements of
risk in the ERP implementation. The project manager must make sure exactly what kind of
training is going to be provided before the contract is signed. Many software vendors use test
data in the education of their software. This test data more often than not consists of products
and items that do not reflect what the customer makes and many times will not have any
resemblance to the working environment of the customer.
Training should be done using real company data in a test environment to simulate the ERP
package software running the business. This means loading a subset of the items, bills-of-
materials, routings, customers, suppliers, etc. into a test environment for simulation with the
ERP software. By loading the actual data, the user has a look and feel of the information that
they use every day and any gaps in the software will be much more visible. This method
combines the software-training phase with prototyping.

The user learns the software while testing with data that is used in the business. The added
benefit is that, in many cases, a total of up to six weeks can be shaved from the
implementation timeframe by using this technique. This is based on an implementation
timeframe of six months or more. The time saved can be put into other areas of the project
such as Conference Room Pilot, etc. It not only saves time, money, and reduces the risk of
project failure; it provides a much more comprehensive and cohesive way to introduce the
user to the software.

5. Business System Test or Conference Room Pilots

The definition of the Conference Room Pilot (CRP) is a trial run of pre-defined business
processes through the new system in a test environment using real business data from the
organization. The CRP is designed to be the final verification that the new system is set-up
correctly to function in the live business environment. It is also the last chance to test the
people and processes that are going to support the system before going live. The CRP can
last anywhere from a couple of days to a couple of weeks.

The general rule is that the larger the system and the more functionality being installed, the
longer the CRP. All functions, plants, and personnel should take part in the CRP. The
Conference Room Pilot should be conducted by the end users of the software with as little
assistance as possible by the implementation consultants. The ability of the software to
successfully conduct business should be shared with end user and senior management alike.
A successful CRP sets the stage for transition into the cutover phase.
6. Execute Timely Cut-over

After all of the analysis, education and testing of the new ERP system, a decision is made to
begin the go-live process and cutover. Cutover means that data from the legacy system is
moved into the new ERP system. Parameters are set, interfaces completed, end user
education is completed, and final system preparations are carried out to support going live.
This phase of the project carries perhaps the greatest risk to project management. Once the
conversion begins, a company is committed to going live and any slippage of the cutover
schedule has a financial price that will have to be paid. A clear schedule must be defined in
advance and carried out to exact detail to assure success of this phase of the project.

One of the biggest problems that occur in this phase is the mapping of data. In many cases
the data is mapped in advance from one system to another then automatically loaded. This is
a good technique that can run into serious problems if the mapping i.e. matching of
information fields from one system to another is not correct. Other issues such as when to
stop production, when to stop taking of sales orders in the legacy system are other timing
issues that will have to be decided to effectively manage ERP Implementation

7. Going Live and Beyond

After the Go-Live, People within the organization now consider the implementation a
success and the ERP implementation team has been disbanded. In many organizations that
have just gone live on a new ERP system this is the scenario. The reality is that the real work
is just beginning. The ROI and goals that had justified the purchase the system has yet to be
achieved. In fact, it may be months before any detectable signs of improvement are noticed.

It is well known that when any new task or activity is learned, that a period of inefficiency
occurs as part of the learning curve. As the activity becomes more familiar to the person
performing the task, the previous efficiencies return. When a new enterprise-wide business
system is implemented at a company, a learning curve happens, but on a much larger scale. If
the scale of the change is large enough in a company, a different and more complex
phenomenon occurs.
 A learning curve does occur on an individual level, but also a sharp decline in performance
metrics can also occur at the company level. This phenomenon of declining performance at
the company level is sometimes referred to as the ‘Valley of Despair’. This valley describes a
fall in performance metrics followed by a slow rise to previously established performance
levels. The ‘Valley of Despair’ is a natural reaction to a major change that occurs at the
company level when the new business system is implemented. But it can be lessened and
managed with the setting of proper expectations during the initial stages itself.

A few major areas of concern for Project Management (4) are

1. 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. 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 decide
which business processes will be included in the implementation. If an organization has more
than one business unit or line, the team must decide which divisions and technologies need to
be included in each phase of the rollout. To prevent scope problems, the project charter or
mission statement is used. Also, clearly define change control procedures and hold everyone
to them.

2. Managing Risk on ERP Projects

Managing risk on an ERP project is crucial to its success. To keep the failures at bay there
are generally 5 steps to managing risk:

a. Find potential failure points or risks

b. Analyze the potential failure points to determine the damage they might do

c. Assess the probability of the failure occurring

 d. Based on the first three factors, prioritize the risks

e. Mitigate the risks through whatever action is necessary

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 under-qualified project manager and no clear objectives for the project.

Assessing the likely impact and the probability of the failure requires 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.

Based on the first two factors 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 and make the entire team aware of those risks
sufficiently minor to avoid detailed management attention, but which the team should watch
for potential problems.

Risk Mitigation can be done 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.

3. The Right Staff

It is absolutely critical to get the right people involved early. Each business area with which
the ERP software will communicate must be involved. A project manager can develop
recognition programs that help retention. ERP projects can be long and frustrating so it is
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.
4. 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. This can
be done by pairing up consultants with corporate employees in both technology and business
areas. The consultants and corporate staff work side-by-side throughout the implementation
thereby ensuring a nearly constant flow of information from consultants to corporate staff,
and prevent the "knowledge drain" that usually occurs when consultants roll off projects. A
method to offset the troubles caused by brain drain is to document each and every step of the
implementation so that in case any key person leaves, his replacement will be able to quickly
come up to speed and takeover. Also, back-up plans need to be put in place so that the back-
up for each role can be identified in case of such issues. Other method like incentives, salary
increase and providing accelerated career growth can be adopted,

5. Monitoring Progress

Project Managers must create very specific work assignments for software developers. They
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. 

6. Managing Chaos

Managing an ERP project is a huge effort because of the 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 hand that both
encourages and motivates project team members and 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.

Agile Project Management (PM) Methods

This is a recent trend in PM for ERP Implementation. In today’s world of faster time to market
pressures, rapidly changing requirements, the Internet, and powerful programming languages,
there is a need to bring in developments like ERP faster so as to grab competitive advantage. \

Wikipedia defines Agile methods as “promoting a disciplined project management process that
encourages frequent inspection and adaptation, a leadership philosophy that encourages
teamwork, self-organization and accountability, a set of engineering best practices that allow for
rapid delivery of high-quality software, and a business approach that aligns development with
customer needs and company goals.”.

Any agile process must include three major attributes (7)

• Incremental, Iterative, and Evolutionary – allowing adaptation to both internal and

external events.

• Modular and Lean – allowing components of the process to come and go depending on
specific needs of the participants and stakeholders.

• Time Based – built on work cycles, which contain feedback loops, checkpoints, and
guidance on using this information in the next cycle.

Applying Agile Principles

Assume Simplicity – As the project evolves the simplest solution is best. Overbuilding the
system or any artifact of the project must be avoided. The project manager should have the
courage to not perform a task or produce an artifact that is not needed for the immediate benefit
of the stakeholders.
Embrace Change – Since requirements evolve over time, the stakeholder’s understanding of
these requirements evolve as well. Project stakeholders themselves may change as the project
makes progress. Project stakeholders may change their point of view, which in turn may change
the goals and success criteria of the project. These changes are a natural part of an ERP project
and processes must be able to accommodate them.

Enabling The Next Effort – The project can still be considered a failure even when the team
delivers a working system to the users. Part of fulfilling the needs of the stakeholders is to ensure
the system is robust enough to be extended over time.

Incremental Change – The pressure to get it right the first time can overwhelm the project.
Instead of trying to develop an all–encompassing project, incremental developments i.e. develop
a small portion of the system.

Maximize Stakeholder Value – The project stakeholders are investing resources, time, money,
facilities, and etc. to create a system to meet their needs. They will expect a return on this
investment.

Manage With A Purpose – This can be done by creating artifacts that have stakeholder value.

Multiple Project Views –There is need for a wide range of presentation formats in order to
effectively communicate with the stakeholders, participants, and service providers so as to ensure
acceptability of the ERP system.

Rapid Feedback – The time between an action and the feedback on that action must be
minimized. For this the project manager must work closely with the stakeholders, to understand
the requirements, to analyze those requirements, and develop an actionable plan, which provides
numerous opportunities for feedback so as to minimize rework.

Working Software Is The Primary Goal – Not the production of extraneous documentation,
software, or management artifacts. Any activity that does not directly contribute to the goal of
producing working software should be examined to determine its value.

Travel Light – Since every artifact must be maintained over its life cycle, the effort needed to
maintain these artifacts must be balanced with their value.
SME Vs Large Enterprises

The obvious difference between SMEs and LEs lie in the obvious leverage LEs have in terms of
resources like money, people etc. Studies (1) (5) (6) have suggested that

1. SMEs experience more knowledge constraints than LEs in ERP adoption.

2. SMEs differ from LEs in important ways affecting their information-seeking practices
that impact information and technology (IT) adoption. These differences include lack of
information systems management, concentration of information-gathering responsibilities
to a small number of individuals, lower levels of resources available for information-
gathering

3. There is a lack of knowledge and expertise, with respect to project management, in how
modification, feedback and management should be made and organized to enable ERP
systems implementation.

From this, one can see that in terms of project management, which is but one of the critical
success factors in ERP, SMEs and LEs differ widely. SMEs are subject to much more constraints
and ERP project management should be tuned in to these restraints and develop plans
accordingly.

An Example for ERP Implementation Failure due to PM

I was able to see a good example of the ERP implementation failure due to ineffective project
management (PM) in my SIP organization (AIG). Almoayyed International Group (AIG),
established in 1979, is a global business group with a wide range of interests in Information
Technology, Business Automation, Integrated Engineering Solutions, Safety and Security,
Ironmongery and Fabrication, Electrical and Instrumentation Solutions, Packaging, Freight
Forwarding and Logistics Services.

AIG has split its operations into diversified business sectors, mainly Almoayyed Computers,
Almoayyed Commercial Services, Almoayyed Trading and Contracting, Almoayyed Safety and
Industrial Centre, Apple Centre, Almoayyed Ironmongery and Fabrication Services, Almoayyed
Electrical and Instrumentation Systems, Almoayyed-AGIL and Freight Logistics and Season
International Trading apart from its operations in other GCC countries. Its main area of
operations is in the Middle East and it has forged alliances with the major players in each
network and serves as the main dealer for their products in the Middle East.

The company had decided to go in for Oracle ERP and implemented the financial module first.
However, they saw ERP as just a software instead of appreciating the change it brought to the
organization. No proper training was provided to the end-users and they were also not included
in the testing of the ERP also. Also, after implementation, some of the employees who were
familiar with ERP left the organization which adversely affected them. Scheduling of ERP
implementation was too short (5 to 6 months) which did not take into consideration the factors
listed above,

The company lacked any previous experience with ERP and as a result did not have enough
domain and technology expertise to go forward with it. They had recruited fresh people and
consultants to implement ERP. However, from whatever I was able to understand, this had
caused a friction between the managers and the implementation team. As a result of this, there
was a huge resistance to change and a lot of grumbling was going around regarding why they
should use the new ERP system.

Conclusion

The focused management of the above mentioned activities by the ERP project manager will
enhance the success of any ERP project. Placing a major focus on these activities and setting
expectations around them will help create a sense of direction within the project and organization
that may not otherwise occur. Assuming the software purchase is viable for running the business,
unsuccessful projects can be traced back to an activity mentioned above that was not well
managed.
 References

1. “Experiences of ERP Use in SMEs” by Paivi Iskanius

2. “A model of ERP project implementation” by Anne Parr

3. “ERP Project Management – An Activity Based Approach”

4. “ERP Project Management is key to a successful implementation” by Charles Trepper

5. “The ERP Project Risk Assessment – A case study”

6. “Critical Success Factors of ERP Implementations in Belgian SME’S” by Claude

Doom and Koen Milis

7. “Agile Project Management Methods for ERP: How to Apply Agile Processes to
Complex COTS Projects and Live to Tell About It” by Glen B. Alleman