Give us a Call +1 (720) 515-1377

Our 2010 ERP Report, of which the first installment was published last month, outlines several metrics that are of interest to most CIOs, COOs, and other executives about to embark on an ERP system implementation. Although the numbers improved relative to our 2008 study of hundreds of ERP initiatives across the globe, the data still shows that most ERP software implementations fail.

But first, how do we define implementation failure? People talk about failures all the time, whether it’s related to companies filing lawsuits against software vendors, pulling the plug on troubled implementations, or in some extreme cases, filing for bankruptcy due to their failed implementation (think Shane Co. in early 2009).

Aside from extreme cases such as these, there is a spectrum of implementation challenges that can result in varying degrees of failure. In short, we consider an ERP implementation to be a failure if one or more of the following occurs:

  1. Takes longer to implement than expected
  2. Costs more than expected
  3. Fails to deliver at least half of the expected business benefits

In our most recent study, which is technology-agnostic and one of the most thorough studies conducted in the ERP space, we found that there is a 72% likelihood that one or more of these three things will happen. There is a 31% chance that two or more of these things will occur.

If we assume that these are three valid failure points, then there are a number of things companies can do to avoid one of these three outcomes, most of which are outlined in our report. Perhaps the quickest and most direct way to ensure these things don’t happen is to have realistic expectations to begin with. A realistic view of what an ERP implementation will cost and the business benefits that can be realized will go a long way toward avoiding these failure points. It is important to augment software vendor sales hype with a realistic view from independent and objective sources that fully understand ERP and your business.

Want to learn more about our 2010 ERP Report? View the brief video presentation below, which provides an overview of these and other findings from our study.


  1. Gabrielle Ford

    Very interesting presentation which brings to light an issue that may be worth thinking about: If ERP success is measured in terms of on time, within budget and realising expected benefits, and 72% of the companies that participated in your study experienced difficulties with at least one of these metrics, then how is it that only 28% of Executives are dissatisfied? 67% of companies failed to realise at least 50% of the expected benefits, yet less than half that number of Executives were dissatisfied with the outcome. Does this mean that either a) Executives are measuring success in some way other than the metrics identified here, or b) that expected benefits are set so high that a lower than 50% realisation is acceptable?

    I would also like to mention that in my opinion, avoiding software customisation as a way of cutting costs could be detrimental to the overall success of the implementation due to work practice incompatibilities that may arise as a result of the business model embedded in the ERP software..

  2. Candice Mazur

    I think Gabrielle raises some valid points.

    Additionally… what are some ways to re-set expectations? Across the board there is a major disconnect between the business development (sales) and the team on for delivery. Prices are set, promises are made and SOWs are signed… all seemingly in a silo… we exhibit the very behaviors that we warn our clients against.

  3. Janine Mackenzie

    I don’t really agree with the comments about software customisation being so essential. You will find that most customisations are driven by the companies need / want to tailor the new ERP system to mimic their old comfortable system. Managing change in the company will circumvent the need for customisation in most cases.

  4. Gabrielle Ford

    I agree that mimicking outdated processes is not constructive. However, I think it is equally counterproductive to impose a business model onto a company that does not comfortably meet the users’ needs. Although change management can be effective during the early stages of implementation, I’m suggesting that if the vanilla implementation creates significant misfits between the users’ needs and the system functionality, the new business model will not be institutionalised and users will institute workarounds in order for them to revert back to what they know and are comfortable with. Customisation, on the other hand, can alleviate this problem by tweaking the system to align better with the users’ needs.

  5. Dave McCulloch, PMP

    The experience of 26 implementations offers the notion that there isn’t much value in entertaining the debate over success or failure of ERP. Despite years of experience, the housing construction proces hardy ever delivers a product on time or budget. So, multi-million dollar technology overhauls are late and cost more than the Sales folks tell us. Surprise, surprise.

    Let’s face it, the vendor supplied, monolithic software paradigm is the “business as usual” state for just about all business models. In the time before that, we didn’t have the debate over whether the home grown stuff was a success or failure. Most frequently, the debate was over “when is it going to be done”. It is the ERP sales folks who need to entertain this dialog.

    The big picture here is the reality that your vendor relationship is going to last a very long time and effectively managing the impacts of that is going to drive the perception of success or failure.

  6. Anne Brennan

    I can only relate to my 20 years of a mid-market VAR. I have seen it all. I have never seen an ERP implementation fail since we will keep at it until it is successful. I have seen many customer disappointments. Usually, there is a driver for the new ERP system. The one I see the most is growth which is the catalyst for a new system. So from the beginning there are growing pains with new people coming aboard with various backgrounds, change in management and a core of people who have been there since the beginning and are nervous about their futures and cling to the past. Oftentimes, the “past-clingers” are the ones who want the system to look just like the old one even if they think it is deficient. The new folks do not have any history and are fearful that one of them will leave with deep rooted knowledge of the company that no one else knows and then the system enhancements are requested. Many companies have enhancements specific to their company that have been developed over 15 years. When companies try to engineer the new systems to look somewhat like the old, the clock and burn rate in dollars starts to increase deeply affecting the estimated implementation. Another area that absolutely kills an engagement is data conversion. Of course all current software has data conversion tools. But really, do you need to have every one of the 1,000 fields in historical records to match up with the current system. $$$$ We have recommended that history be downloaded to a database with query tools instead of populating the new tables. We get pushback from mostly the accounting folks. I have actually asked the question “how often do you look back on “x” piece of data from 5 years ago? The answer is “not often” but we want to have it. So the beginning of a perfectly good implementation goes sour right away with these two areas, data conversion and backward compatibility. At this critical juncture the decision maker is very nervous about the future of the implementation. We urge clients to pay up front for a gap analysis before they buy the software because there is going to be some that won’t come out until the implementation begins with. Identifying the areas that are going to give us trouble in the beginning helps with setting expectations. We also try to continue to re-inforce that this is not easy. Putting in a new ERP system when trying to run a business is very difficult and stressful. As for things going over budget which the salespeople will not tell you, as a salesperson it is like building a house as mentioned by Dave McCollugh. You quote $500,000 for a standard build house and mention that extras will cost more. The customer only hears $500,000, wants granite, triple crown moulding and a pool and can’t understand why the price is $600,000 at the end. On a hot muggy day in the summer when the customer is relaxing by the pool, the cost doesn’t even factor into it. At about one year after the implementation, no one lovingly speaks of the old system anymore and the pain fades away.

  7. Mark Chinsky

    I think a big factor is that given the tough economy, fewer new ERP opportunities, the desperation of ERP salespeople is causing many to way underestimate the services of a project knowing that its ‘only an estimate.’

    Customers are encouraging this by making price one of the top 1-2 factors in the purchase decision and in the end they are getting what they paid for.

    If more prospect’s read your well done blog posts, we’d have a much more educated and realistic prospect. Unfortunately too many just want to see the lowest cost proposal and then wonder why its over budget.

  8. Hugo Cid

    Most of ERP disasters are related with trying to turn the ERP doing things outside the ERP scope. It’s like to use the big semitrailer to take the kids to school. One can do that, but it’s better to use a family car or even a bike.
    Most of ERP’s are good, some are excellent most them are sold with too much non sense promises.

    • Eric Kimberling

      Thanks for reading Hugo. That’s a great analogy to use when describing certain projects. We absolutely believe in the right tool for the job as well. If we can help your ERP project in any way, please let us know.


Submit a Comment

Your email address will not be published. Required fields are marked *