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.

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.

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.

Follow

Get every new post delivered to your Inbox.

Join 4,137 other followers

%d bloggers like this: