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:
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.
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.
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.
Leave a Reply