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:
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.
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.
Join the community! 16k followers across 100 countries!
Leave a Reply