Risk and failure
Why ERP Projects Fail and the Numbers Behind It
There is a grim statistic that follows ERP projects around, and it is repeated so often it has become wallpaper: more than half of ERP implementations exceed their budget, and a meaningful share are considered failures by the business that bought them. I have lived inside enough of these projects to tell you the numbers are not wrong, but they are also not the helpful part. The helpful part is the pattern behind them.
What the statistics actually say
If you read the industry surveys with any care, a consistent picture emerges. Depending on the year and the firm surveyed, somewhere between 50 and 75 per cent of ERP projects overrun their budget or schedule. The most cited figures come from Panorama Consulting's long-running ERP Report, which has tracked average cost overruns of around 50 per cent and schedule overruns of around 54 per cent for years, and the Standish Group's CHAOS research shows the same picture for software projects more broadly.
The uncomfortable truth is that these numbers have barely moved in thirty years. That persistence is the real finding. It tells us we are not failing because of new technology, we are failing at the same old things, governance, people, data and scope, and no shiny platform fixes any of those.
Failure is usually a people problem
The most common cause of failure I have seen is not technical. It is change management done too late and too thinly. A business buys a new ERP, assumes the organisation will simply adapt, and then finds that finance, operations and sales are each doing their own thing with the new system within a quarter. The technology works. The adoption fails.
This is why real practitioners spend as much effort on the people as on the platform, and why the plan needs a change workstream from week one. Underestimate this and you will not read about the collapse in a technical post-mortem, you will read it in the quiet resignation of a finance manager who never accepted the new process. The discipline of handling this is covered properly in our guide to planning an ERP migration step by step.
I was once brought in after a go-live that had gone perfectly on the technical side. Every interface worked, every reconciliation tied out. Six months later the project was declared a failure because the warehouse team had quietly kept their old spreadsheets and the sales team had found a workaround. Nobody had ever shown them why the new way was better.
Data, the silent failure
The second silent cause is data. Projects fail not at go-live but in the months after, when executives try to report against the new system and find the numbers do not add up. Dirty master data, duplicated customers, mismatched part codes, all of it imported faithfully on day one, slowly poisons trust until the leadership concludes the tool is the problem.
It is a failure entirely avoidable by effort spent early. The work is unglamorous, but it is the difference between a go-live that closes and one that quietly unravels. For the practical detail, our field guide on cleaning master data before you migrate walks through exactly how to do it without blowing the budget.
Scope and the moving goalpost
The third cause is scope, and it is a slow death rather than a sudden one. The project starts with a sensible scope, then one department asks for "just one small extra report", then another requests a custom interface, and before anyone notices, the fixed-price build is a bespoke software project in disguise. Every addition adds time and risk, and the schedule slips a week at a time until the overrun matches the surveys above.
The defence is a change control board with real teeth and a definition of done that everyone signs. Decide what is in and what is out, and hold the line, because the boundary is what protects the schedule. If you get pulled toward a bespoke build, ask whether the underlying problem is better solved by the standard product or by changing the business process. This is the same judgement as in choosing an implementation methodology.
How to avoid the received story
The good news is that every one of these causes is a management decision, not bad luck. Build change management in early, clean your data before you move it, and hold scope with discipline, and you remove the three biggest reasons ERP projects fail. That leaves the technical work, which is the part vendors and consultants most enjoy and, ironically, the part that least often brings a project down.
If you are at the start of this, the cheapest investment you can make is the honest case for whether the project should run at all. Read how to tell if your business is ready to migrate before you commit a penny, because not starting the wrong project is the surest way to avoid failure entirely.
Frequently asked questions
What percentage of ERP projects fail?
Exactly how you define failure changes the number, but industry surveys consistently report that 50 to 75 per cent of ERP projects overrun their budget or schedule, and a substantial minority are later judged failures by the business. The figure has stayed stubbornly stable for decades.
What is the biggest cause of ERP implementation failure?
Poor change management and adoption, followed closely by dirty data and uncontrolled scope. Technical issues are rarely the primary cause. Most failures are people and process problems that a strong governance structure prevents.
How can you avoid ERP failure?
Start change management early, clean master data before migration, control scope with a board that has authority, and secure realistic executive sponsorship. The technology is rarely the problem; the discipline around it is.
Why do ERP projects run over budget?
Mostly from scope creep, underestimated data work, and change requests added after the plan and price were set. Budgeting realistic contingency for data and adoption, and controlling scope, are the two most effective safeguards.
Sources and further reading
The argument in this article draws on public research. Where you want to go deeper, these are the sources cited in the text and further reading.
