We have all heard the phrase “Get right the first time” used as part of an effort to reduce costs and accelerate implementations. Unfortunately, many have interpreted this to mean doing an activity once. We attempt to run ERP implementations as a production process. Good production processes deliver the anticipated result (a known result), for a standard cost, within a given time. In contract, ERP implementations are more of an exploration process given the customer variability. Consider the following illustration:
Unique Factors for ERP Implementations
A recurring problem we have with ERP implementations is that we try to “big bang” activities and do not provide an opportunity to learn, adjust, and correct for success. Iterating certain implementation activities will give us that opportunity. Let me provide you with a just a few examples.
Project Estimating
As stated in the Project Management Institute’s (PMI) Project Manager’s Body of Knowledge (PMBOK) there are three types of estimates or what I like to call “levels of understanding”. Estimating is based upon our level of understanding regarding effort, scope, assumptions, constraints, and objectives.
ERP Estimates
As you move further into an ERP implementation the better we are able to estimate. Why? The key reason is that you have more proven information to base your estimation. I worked on generating ERP implementation estimates for the last 10 years and I can safely say that I could never generate a definitive estimate without first going through a detailed fit/gap. Yet, we expect to hit an implementation estimate that was created before any implementation work is done. There should be no surprise to the fact that most ERP implementations do not hit their budget given the level of accuracy associated with the estimate.
Gathering Requirements
Another area for an iterative approach is in requirements gathering. Recently, I was asked what the best approach for gathering requirements was and my response was that there is no one good approach.
Methods for gathering ERP requirements
Do not limit yourself to one method for defining requirements. The more methods (perspectives) you employ to gather requirements the greater the probability for success because the project will have the opportunity to create a holistic requirements definition.
Summary
I firmly believe that every customer’s ERP implementation is unique. Because every ERP implementation is unique there are a large number of unknowns that we try to address given the limited information we have. We should take a risk-adverse, iterative approach to remove implementation uncertainty. Do you think this cause and effect could apply to other areas of an implementation (example: testing, development)? I am interested to hear your thoughts.
ERP the Right Way! 
Well, this is a first for me because I will argue with my own blog. I hope I win.
QUESTION
Great theoretical approach for estimating but how would you implement in the real world? My management only wants one estimate and they will hold me to that estimate. How can I change this?
ANSWER
I must admit it is hard to address with management because the majority of ERP estimating done today is flat out wrong. Following is the approach I have taken – sometimes it works and other times I just have to deal with limited funds handed to me.
The first step is to educate management on estimating including the types of estimates, accuracy of estimates and how estimates can be improved/validated. Every estimate is based upon our best understanding of project objectives, scope (product, project), risks, constraints, and assumptions. Production IT ERP processes (applying patches) are much easier to estimate than IT discovery and development processes (ERP Implementation, ERP Upgrade).
Second – I communicate the accuracy for the estimate. Every estimate will have some level of accuracy (+ or -). This range can be addressed via a contingency reserve or a management reserve.
Third – I educate management on the triple constraint. Even if the funding remains the same we may need to address schedule, scope, or quality based upon further discovery. Understanding reality – you may need to move forward with funding originally allocated to the project. Today, we still lack the business processes and tools to perform real time project portfolio management.
Fourth – and this is most important. I tell management how I will further gather information to refine and increase the confidence of the estimate. It is important that as a PM you aggressively determine the unknowns, validate the assumptions and level of effort in the original estimate.
I hope this provides a little better insight. It’s the best method I can come up with out in the field. Feel free to poke holes through my logic or provide other suggestions.
Always learning,
Brett
Excellent approach!