Why ERP implementations fail — and how to prevent it

July 7, 2024

Key takeaways

McKinsey research with the University of Oxford (5,400+ IT projects) found large IT projects run on average 45% over budget and deliver 56% less value than predicted; Gartner predicts more than 70% of recently implemented ERP initiatives will fail to fully meet their business-case goals by 2027.
Most overruns trace to management and people — strategy, stakeholders, teams and change — not to the technology itself.
The recurring causes are over-customisation, poor data quality, scope creep, underestimated effort, weak change management, and high-stakes cutovers with no fallback.
Lidl (over-customisation), Hershey (skipped testing and a badly timed big-bang cutover) and Revlon (botched cutover and supply-chain disruption) each illustrate a named cause that was visible before go-live.
Prevention is ordinary discipline: an accountable owner, standard-first processes, data as its own workstream, controlled scope, honest contingency, early change management, and a tested way back.

An ERP failure rarely looks like a failure on the day the contract is signed. It looks like a sensible project with a credible plan. The trouble accumulates quietly — in a decision to customise rather than adapt, in a scope that grows a little each week, in data nobody had time to clean, in users who were told rather than involved. By the time it shows up as a missed go-live or a system people refuse to trust, the causes are months old.

This is worth saying plainly because the numbers are sobering. A study by McKinsey, conducted with the BT Centre for Major Programme Management at the University of Oxford and covering more than 5,400 IT projects, found that on average large IT projects run 45% over budget and 7% over time while delivering 56% less value than predicted. More strikingly, it found that 17% of large IT projects go so badly they can threaten the very existence of the company. For ERP specifically, Gartner predicts that by 2027 more than 70% of recently implemented ERP initiatives will fail to fully meet their original business-case goals, with as many as 25% of those failing catastrophically.

The useful insight in the McKinsey research is not the size of the overruns but where they come from. McKinsey attributes roughly half of all cost overruns to weakness in managing strategy and stakeholders and in mastering the project content, with poor performance on building effective teams and core project-management practices accounting for a further share of the overspend. In other words, most overruns trace to management and people, not to the technology. That is the through-line of everything below: the common causes of ERP failure are organisational decisions, and they can be managed.

Over-customisation: the most expensive habit

Modern ERP packages encode a standard way of running finance, procurement, inventory and the rest, distilled from many businesses. The temptation is to bend the software to match exactly how you work today. Each customisation seems reasonable in isolation. Together they create technical debt that has to be re-tested and rebuilt at every upgrade, and they remove the one advantage of buying a package — that someone else maintains the standard version.

Lidl is the cautionary example, documented by Panorama Consulting Group. The retailer spent an estimated EUR 500 million over roughly seven years on a custom SAP system, in large part because it chose to customise the software heavily to preserve its existing practice of valuing inventory at purchase prices rather than the SAP-standard retail prices. Combined with over-reliance on external partners and insufficient internal ownership, the project was abandoned in 2018. As Computer Weekly reported, a memo from Lidl head Jesper Hoyer explained that the original strategic goals could not be achieved without the retailer spending more than it wanted — the objectives would have required spending well beyond the half a billion euros already sunk.

The discipline here is to treat every customisation as a request to justify, not a default. If a standard process is merely unfamiliar, adapt the business. Reserve customisation for the few processes that genuinely differentiate you, and write down the reasoning each time, so the next team understands what it is maintaining and why.

Poor data quality undermines everything built on it

A new ERP system is only as trustworthy as the records loaded into it. Years of accumulated habit — duplicate suppliers, part numbers that mean different things to different teams, balances adjusted by hand and never explained — do not announce themselves until you try to load them cleanly into a system that expects discipline. Software Connect lists inadequate data quality among the common root causes of ERP failure precisely because it quietly undermines the integrity of everything else.

Bad data does not only cause go-live problems. It erodes trust afterwards. When the figures in the new system do not match what people know to be true, they go back to their spreadsheets, and the single source you were trying to build never takes hold. Data cleansing and reconciliation deserve to be a workstream with its own owner and milestones, started early rather than squeezed into the final weeks.

Scope creep and underestimated effort

Scope creep is rarely a single bad decision. It is dozens of small, defensible additions — one more report, one more integration, one more edge case — that together inflate cost and timeline past the point the business case can carry. Software Connect names both scope creep and underestimated timelines and budgets among the recurring causes of failure, and they tend to travel together: an underestimate leaves no slack, so every addition pushes the project further behind.

The defence is a written, agreed scope with an explicit process for changing it. Not a freeze — requirements do evolve — but a discipline where each addition is costed against time and budget before it is accepted, and where someone with authority decides whether it is worth the slip. The effort estimate itself should carry honest contingency, particularly for data work and testing, which are the tasks most often under-scoped.

Weak change management and the big-bang cutover

Two failure modes sit close together here, both about people and timing. The first is weak change management. Gartner notes that ERP initiatives commonly fail through a lack of executive commitment and a failure to understand the organisational change required. The change-management research firm Prosci puts the people side of change — resistance to new processes, inadequate training, weak adoption — at the centre of why implementations fail, and positions structured change management as a primary driver of success. A technically sound system that people will not use has still failed.

The second is the high-stakes cutover with no way back. Hershey’s late-1990s ERP project, documented by Pemeco Consulting, compressed a recommended 48-month timeline into 30 months to beat a Y2K deadline, abbreviated or skipped systems testing, and went live with a big-bang cutover in July 1999 — right before its peak Halloween and Christmas season. The company could not process roughly $100 million in orders, contributing to an approximately 19% drop in quarterly profit. Revlon’s 2018 rollout, as reported by The CFO Club, disrupted its supply chain so badly that it reportedly could not ship about $64 million of products and spent roughly $53.6 million to remediate the lapse; its shares fell almost 7% in 24 hours and shareholders filed a lawsuit. The pattern in both is the same — a switchover with skipped testing, poor timing, and no fallback.

Change management belongs in the plan from the start: name an executive owner, involve the people who use the system while decisions are still open, and train before go-live rather than the week of it. The mechanics of phasing, parallel running and rollback are a subject in their own right; the point for failure prevention is simply that a cutover with no fallback turns one slipped module into a business crisis.

A prevention checklist

None of these causes is exotic, which is the encouraging part: they are visible early and manageable with ordinary discipline. The following is a short list to test a project against before and during the work, not after.

Name an accountable executive owner — not a steering committee that meets monthly, but a person whose job it is to make decisions and unblock the team.
Default to the standard process; justify every customisation in writing, and reserve it for the few processes that genuinely differentiate the business.
Treat data as its own workstream with an owner and milestones; start cleansing and reconciliation early, and agree the figures that must match exactly before any sign-off.
Fix scope in writing and run every addition through a costed change process, so each one is weighed against time and budget by someone with authority to say no.
Build honest contingency into the estimate, especially for data and testing — the tasks most often under-scoped.
Invest in change management from day one: involve everyday users while decisions are open, and train ahead of go-live, not during it.
Do not test cutover readiness with the go-live itself — keep a tested way back, and avoid period-end and peak trading for the switchover.

The bottom line

The evidence points consistently in one direction: ERP projects fail for organisational reasons more than technical ones. The McKinsey and Oxford research traces most overruns to strategy, stakeholders, teams and project management; Gartner and Prosci point to executive commitment and the human side of change. The named disasters — Lidl, Hershey, Revlon — are each a clear instance of a cause that was visible long before go-live.

We have spent enough time inside these projects to believe the failures are largely preventable, and that prevention is unglamorous: own the decisions, respect the data, hold the scope, and bring people with you. If you are about to start, or are partway through one that feels heavier than planned, the most useful thing you can do is check it honestly against the list above while there is still time to act on the answer.