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.

Summary 

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.

About these ads

About Brett Beaubouef
For the past twenty years Brett has helped customers select, implement, and manage ERP solutions across five industries (manufacturing, professional services, staffing, retail, and telecommunications). Business process knowledge and experience includes human resources, benefits, compensation, recruiting, time & attendance, finance, resource scheduling, contract administration, services procurement, sales, billings, project accounting, and project/portfolio management. Software selection experience includes evaluation of both ERP software and proposed implementation services. Brett has recently authored a book on leading ERP/COTS implementation strategies.

14 Responses to Building a Better ERP Estimate

  1. 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 says:

    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 says:

    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 says:

    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. 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 says:

    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. 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 says:

    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 says:

    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 says:

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

  11. Pingback: Building a Better ERP Estimate | Pardaan.com

  12. Great content. Thanks for sharing.

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 4,139 other followers

%d bloggers like this: