What Constitutes an ERP Failure?

It’s often been said that 80% or more of ERP implementations are considered failures. In fact, one of the findings of our 2013 ERP Report is that most ERP projects take longer than expected, cost more than expected, and fail to deliver expected business benefits. In addition, in our 2013 ERP Report: Organizational Change and Business Process Management due out next week, we find that 41% of organizations experience some sort of material operational disruption at the time of their go-live.

While the fact patterns may suggest that ERP implementation challenges may be more common than any of us would like to admit, there is no clear definition of what constitutes ERP failure. One of our blogs published last week focused on how to define ERP success for your organization, so we thought it would only be fitting to explore the other side of the coin by describing what constitutes failure.

First, it helps to explain what ERP failure is not. Although cost overruns and project delays are frustrating and more common than they should be, they do not in and of themselves necessarily indicate project failure. Instead, they are more often symptomatic of unrealistic expectations. ERP vendors and system integrators often oversell and oversimplify the ERP implementation process, which commonly leads to these project overruns.

In other cases, implementation delays and budgetary overruns can be caused by poor project management, inefficient focus on organizational change management, and lack of attention to business process reengineering. In these situations, it is the actions of the implementing organizations and their ERP consultants that contribute to the delays, so it could be argued that these are failures.

However, the more cut and dry definition of ERP failure is related to overall business benefits and return on investment. Since most executives are responsible for safeguarding company assets and ensuring a positive return on investment, it is hard to argue that the executive or project team that leaves millions of dollars of unrealized benefits on the table hasn’t failed in its ERP implementation. Just as executives are typically held accountable for realizing overall corporate revenue and cost targets, so too should executive success or failure be determined by optimizing the return on investment of ERP implementations.

The even more commonly accepted (and troubling) definition of failure is related to operational disruption. In our study of nearly 200 ERP implementations across the globe, we found that 41% realize some sort of operational disruption – such as not being able to ship product or close the books – at the time of go-live. This type of business interference is much more measurable and conducive to results that can commonly be agreed upon as failure.

Length of ERP Operational Disruption

It is interesting to note that most operational disruption and implementation challenges are not caused by the software itself or other technical challenges. In fact, as our report to be published next week will show, most companies find this to be the relatively easy part of an implementation. It’s all the other stuff that creates problems.

For example, about three years ago, we helped a mid-sized client evaluate and implement a leading Tier II ERP system. As is the case with any rollout, there were hiccups along the way. In particular, the client’s engineers and sales reps were having trouble getting comfortable with how the product configuration processes would handle their relatively complex engineer-to-order industrial products. Our ERP consultants recommended delaying the go-live by 30 days to give the organization additional time to adapt to the new business processes, but the client instead opted for a “Hail Mary” flick of the switch. In other words, they essentially rolled the dice that this decision would not affect their business.

Unfortunately, this gamble did not pay off. The client did not build enough safety stock to account for a potential disruption to its supply chain. In addition, these critical engineering processes weren’t fully defined or understood at the time of go live, so the company experienced lost revenue of more than $2 million as a result – even though the extra 30 days would have only cost them an additional $70,000. This is just one instance of some of the mistakes and lessons we’ve seen in the industry over the years that inevitably lead to failure.

The good news is that most failures are avoidable. Organizations with the right focus on project governance, business process reengineering and organizational change management more commonly succeed in their ERP implementations, even against the backdrop of the statistics outlined above. However, they need the right expertise and methodologies to ensure that they set their projects up for success.

Learn more by watching our free, on-demand webinar, Lessons Learned from Failed ERP Implementations.

About Eric Kimberling

After 15 years of ERP consulting at large firms including PricewaterhouseCoopers and SchlumbergerSema, Eric realized the need for an independent consulting firm that really understands ERP. He began his career as an ERP organizational change management consultant and eventually broadened his background to include implementation project management and software selection. Eric’s background includes extensive ERP software selection, ERP organizational change and ERP implementation project management experience. Throughout his career, Eric has helped dozens of high-profile and global companies with their ERP selections and implementations, including Kodak, Samsonite, Coors, Duke Energy and Lucent Technologies. In addition to his extensive ERP experience, Eric has also helped clients with business process reengineering, merger and acquisition integration, strategic planning and Six Sigma initiatives. Eric holds an MBA from Daniels College of Business at the University of Denver.

Related Posts


  1. After 35 years working with companies implementing MRPII and ERP it is clear that organisations set themselves up for failure long before they even commence the implementation of the technology component (software) of an ERP project.
    The acquisition strategy or “why do we want it and what do we expect from it” is poorly defined leading to a confusion of objectives compounded by fixing budgets without a review of the quantum of work to be done followed by expectations that paying money to ERP vendors and their consultants will produce a result. Your research results continually demonstrate that the current approach by organisations does not produce the results expected yet industry is slow to change what is a flawed strategy for implementing ERP.
    The ERP industry apologists are big on blaming someone else for the many ERP bad outcomes but the reality is unless the current ERP approach is radically changed then we will continue to see ongoing failures.
    After 35 years of integrated systems it seems impossible that we cannot get the implementation model right…or maybe there is so much money to be milked from the existing methods that there is no incentive for the ERP industry to change!

  2. It’s probably more critical to define “success” in ERP rather than failure. There is a very large grey area of less than successful ERP implementations that were not objective failures. We can adapt our definitions to suggest that there are less “failures” than is thought.

    My sense is that we need to define success in terms of implementation and sustainability as:

    1) Delivered on time
    2) Delivered within budget
    3) Achieved expected benefits
    4) Achieved expected ROI
    5) Achieved expected annual costs (all costs including upgrades, internal training, maintenance fees)
    6) Enabled business change after installation

    Some diversion from meeting any on these objectives (with the possible exception of the 6th) could be permitted based on unique conditions like increased budget by 10% but achieved ROI 25% faster.

    My sense is that this type of thinking will result a bell curve where the majority of implementations fail to meet 2 to 3 of these conditions. Organizational size, IT capabilities, location, vertical market, ERP footprint, vendor selection etc. are likely to play a role in increasing or reducing risk of not achieving some of these objectives. That’s where we could create an excellent risk matrix.

Leave a Reply

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


Enter Text From Image Above