Gathering ERP requirements

Get it wrong the first time! The case for ERP iterations.

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:

Every ERP Implementation is Unique
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.

Estimating for ERP Implementations
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.

Gathering ERP requirements
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.


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.





12 responses to “Get it wrong the first time! The case for ERP iterations.”

  1. […] prototyping during the sales cycle to define core requirements, validate software results, and eliminate […]

  2. Brett Beaubouef Avatar

    Well, this is a first for me because I will argue with my own blog. I hope I win.

    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?

    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,


  3. Arthur Panton Avatar
    Arthur Panton

    Excellent approach!

  4. […] not a “light switch” that you can turn on and customers think differently. There must be an evolutionary process to better align customer expectations with ERP strategy and direction. Let me provide a real life […]

  5. […] What if we could bring in different approaches in such way as to complement and progressively elaborate (iterate) business requirements?   This is the aim of the blended approach – to leverage different techniques in the process […]

  6. […] Bron : ERP the Right Way! Bekijken… […]

  7. […] and not just a brainstorming event.  IT needs to move up the business value chain with a rapid, iterative delivery method.  Governance is not an acceptable substitute for properly educating users on the […]

  8. […] I firmly believe that all four validation methods should be employed at part of defining business requirements.  Unfortunately, not all of these validation steps occur during the deployment.  The great advantage with ERP is that you have working software that you can easily demonstrate and confirm how business requirements would be handled.  Do not guess – prove what is possible! […]

  9. […] value realization; however, the value proposition is dependent upon appropriate expectations and implementation approach.  The purpose of the following article is to provide insight to ensure customers make realistic […]

  10. […] the ERP selection stage and refined during the early design stages of the ERP implementation.  Do not limit yourself to performing this exercise only once.  The analysis performed during an organizational Fit/Gap will drive future decisions and […]

  11. […] JIT End User training is a big bang approach – one time shot to get end-user training right. It also gives end users limited time to internalize the change. This approach naturally requires additional support and creates a greater potential for user errors. […]

  12. […] differentiated business requirements, even late in the implementation cycle.  Rapid, iterative processes take advantage of change for the customer’s competitive […]

Leave a Reply

%d bloggers like this: