Building a Better ERP Estimate

There are several documented examples of ERP implementations that went over budget or did not hit the original go-live date.  There are also many explanations out there to explain why these ERP implementations did not meet budget or timeline.  Instead of repeating common information out in the ERP blogosphere, I would like to speak to a root cause that is typically overlooked by our industry – inaccurate ERP implementation estimations.   In the next sections we will take a closer look at building a better ERP estimate.

Rule #1 – Have the right type of information to calculate an ERP Estimate

Developing a competent estimate for an ERP implementation or major customization can be a challenge for both seasoned consulting partners and a new ERP customer.   In a previous life I developed ERP implementation estimators for one of Tier-1 ERP software vendors.  I also developed both Time & Materials as well as Fixed-Price ERP implementation estimates – some good, some not so good.

Simply stated – an ERP implementation estimate is based upon your current understanding of the following areas:

Information Drivers for ERP Implementation Estimates
Information Drivers for ERP Implementation Estimates

 Let’s focus on some specific areas that are typically overlooked or under appreciated. 

Area Description
Customer Participation Implementation partners are generally good about estimating their level of effort to support ERP implementations but fall far short in estimating the effort for the customer.    In the majority of ERP implementations, customer must make available their best and brightest resources to support the implementation.  Odds are that these resources play a major role in current operations.  The ERP estimate should include any need to backfill existing business resources.
Project Scope Project scope refers to the implementation activities that need to be performed and who is responsible for performing the task(s).  Unfortunately, customers see this as an area to reduce implementation costs by taking on activities that they do not have the skills/resource availability to complete (ex. Organization Change Management).  People make ERP successful.
Product Scope Too often business processes and product scope is defined only at the product level (example: we are implementing the ERP’s Purchasing module).  How can I tell what business activities and features are out of scope?  Developing focus is much harder to develop and maintain. 
Implementation Partner Constraints  Every implementation partner has constraints!  It is a just a reality that should be factored into any ERP estimate.  For example, how much lead time should be given for an Implementation partner to replace a consultant?

You can never hope to create a realistic estimate without having valid information on the drivers that influence scope, schedule, and resources.  The next step is to understand your level of comprehension of the information that drives the ERP estimate. 

 Rule #2 – Understand the type of ERP Estimate you are calculating

Per the Project Management Institute’s Body of Knowledge (PMBOK) there are three types of estimates for a project.  These estimates are based upon your level of understanding for project scope, constraints, and assumptions.

Levels of ERP Estimate Accuracies
How Understanding Drives Estimate Accuracy

Simply stated – the more you know about the task(s) at hand the greater the probability of calculating a realistic estimate!  The trouble is that too many ERP implementations do not generate a definitive estimate.   A majority of implementation partners generate estimates during the sales cycle where estimates may approach a budgetary accuracy – at best.  To compensate for the estimation accuracy (-10% to 25%)  many implementation partners incorrectly utilize contingency reserves and management reserves to plug the potential estimate gap.   This is just a bad estimating practice which will most likely result in budget challenges further down in the implementation.  Fortunately, there are steps we can take to develop better ERP estimates.

Rule #3 – Drive to validate and refine your ERP estimate

Estimates can and should change as you learn more about the project.  However, there is an expectation out there that estimates should be defined once and they should be completely accurate.  Here is where I see the process break down.  Once an Implementation partner communicates an estimate too often the customer will latch and consider it an iron-clad promise.  The key driver for this phenomenon has more to do with the Implementation partner setting the wrong expectation when an estimate is communicated.   Customers encourage this behavior by focusing on cost as the key competitive differentiator.  Also, there is a perception in the market that if an implementation partner cannot provide a single estimate then the Implementation partner does not have the experience.  Customers, this may be the case but do not blindly jump to that conclusion.

Best Practices for obtaining ERP Estimates from your Implementation partner

Over the years I have been asked by customers what is the best approach to get a reliable, cost-effective estimate from Implementation Partners.  When should a customer request a fixed price estimate versus a time & materials estimate?  Following are some general guidelines I would like to communicate based upon my experience:

  • Fixed Price versus Time & Materials: Have the Implementation partner provide a Time & Materials estimate for project planning, requirements gathering, and fit/gap.  Once the Fit/Gap is performed you should know exactly what you are up against and then ask for a competitive bid/fixed price estimate to complete the remaining work.
  • Complete Information:  Always ask the Implementation Partner to provide an estimate with the following information
    • Product Scope
    • Project Scope
    • Assumptions
    • Constraints
    • FTE Hour Requirements for both the Implementation Partner and customer resources
    • Estimate accuracy – let customers know up-front that the estimate will change
  • Quantify Reserves: Ask the implementation partner if the estimate contains either a contingency or management reserve.  If so then ask what % of the total estimate is for reserves.  If this % is greater than 10% then this is a sign that the Implementation partner did not gather enough information to generate a realistic estimate.  If the implementation partner does not calculate a reserve then consider this estimate suspect (red flag).
  • Knowledge Transfer:  Just as important it is for an Implementation partner to perform knowledge transfer to enable customer resources to support ERP, it’s as important for the customer to educate the Implementation partner on the unique aspects of their business model.  The better the understanding the better the estimate.


There are many of my peers who would consider ERP estimation more of an art than a science.  In my humble opinion, this is a bad philosophy that either results in generating an unrealistic estimate or the customer spending more money than is required.   Customers should also be realistic and understand that estimates created in the early stages of an ERP implementation will change and focus on making the right decisions for mutual success.  Level of effort estimations for ERP implementations are based upon the current understanding of the ERP implementation.  Some ERP estimates are easier to calculate given a predefined implementation scope, however, there will always factors unique to a customer that must be explored, defined, and refined during key milestone implementation activities.

Join the community! 16k followers across 100 countries!





15 responses to “Building a Better ERP Estimate”

  1. cerrolinacole Avatar

    Great information here for the readers. I found very good contend of the ERP estimate. We are thankful to your article. The details your given at here is so useful to us and many other people. Keep sharing your in future.

    ERP Software

  2. Russell Avatar

    I went to seminar that included a discussion on time and price estimating for IT projects. One of the suppliers present said that, if he gave a true estimate of time and costs then he would never get a contract because all the other suppliers lied as well.

    When it was suggested that there should be a regulating code of conduct, all the suppliers disagreed saying that they would always lose to the one liar.

    How do you fix that?

  3. Ed Avatar

    The fix — don’t do business with those suppliers. Not all service companies take the approach of winning the deal at ‘any price’.

  4. Ari Smith Avatar

    Great article! We have found that there are basically two major issues: #1 Typically, to save money, there is not enough up front detailed level “discovery” conducted of existing legacy software to be able to complete a realistic functional design that the customer can sign off on and #2 The customer’s users resist adopting best practices and want their new software to work the same way their old legacy software worked usually resulting in out of budget enhacement requests.

  5. Brett Beaubouef Avatar

    Thank you Russell for your comments. That is a hard nut to crack. I believe that educating the buyer (customer) is key. When I supported and presented consulting estimates I also educated the client on how estimates are created by SIs and how to compare estimates fairly. I did not mind loosing an opportunity as long as it was a fair fight. Being a trusted advisor for a potential client is a far greater competitive advantage rather than having the cheapest resources. That is what I always tried to recommend to the services sales people I supported. Just my humble opinion given my limited view of the world – I still have much to learn.

  6. Michael Hawn Avatar
    Michael Hawn

    I have over 40 SAP and 3 Oracle finicials implementations supporting 20 employees up to 10,000 users and have seen the Assumptions being the place that causes issues the most. Clients should work to remove all assumptions and assign responsibilities to either the company or to the partner. Transparency is key to a successful implimentation.

    The other area that is overlooked is Bussiness Change Managment as all ERP Implimentations are more successful if the business changes to the best practices instead of trying to change the software to match how business is done before an ERP implimentation. This impacts the users and ERP software does not make it easier for the users, it enables better business decisions possible as the data CN better be validated and controlled. ERP removes any manulating of numbers that are reported.

    Third issue is customers miss construe the basic implimentation as an end but it is only the beginning to build a base application that can then be enhanced and extended based on adding business value.

  7. Brett Beaubouef Avatar

    Excellent points Michael! I also agree that assumptions should be validated and revisited throughtout the project. The business proces change is an area that is underestimated because there is only a vague understanding of the change required from “as-is” to “to-be” business process model. Thank you for sharing! – Great stuff.

  8. Peter R Hill Avatar

    Brett’s comments about educating the buyer/customer are a key component in establishing credibility and setting realistic expectaions. The use of a range, rather than a single figure estimate is also worthwhile. The reason for the range needs to be explained to the buyer – “if x&y happen then you can expect to be at the lower end of the range but if a&b happen then it is likely that we will be at the upper end.”

    The use of history data has not been mentioned. If you collect history data about your ERP implementations then you can analyse this to improve your estimates as well as using the history to support your estimates and educate the buyer. Sound history data can be used to undermine low bids and expose the charlatans and incompetents.

  9. Abraham Cherian Avatar
    Abraham Cherian

    Excellent article and comments from the readers. Agree, very often when business process re-engineering is involved, the cost of change management is often overlooked. This results in an uneasy situation between the IT and business folks post go-live. The other issue I have noticed is that, in a highly outsourced IT environment, the suppliers tend to ‘pad up’ the estimates to take care of so called unknowns.

  10. Gerry Poe Avatar

    Breaking it down at different levels is insightful on your part. Appreciate drilling down into those items that are often overlooked. Thank you.

  11. […] Bron : ERP the Right Way! Lees meer… […]

  12. Michael Benedick (@ERPSoftware4RU) Avatar

    Great content. Thanks for sharing.

    1. Peter Heinicke Avatar

      Thank you for the idea of putting in constraints explicitly. We will build a better proposal from now on because of it.

  13. Online ERP software Avatar

    Really i appreciate the effort you made to share the knowledge. Thanks for the great read.

  14. […] can only be addressed during the implementation. A best practice is to have the ERP vendor generate multiple value estimates based on multiple scenarios (best case, most likely, worst […]

Leave a Reply

%d bloggers like this: