What ERP failure statistics actually say — and why they contradict each other

If you are evaluating whether your ERP programme is at risk, you will quickly meet a statistic. Seventy percent of implementations fail. Or fifty-five. Or seventy-five. The figure varies, the confidence never does.

We went looking for the source. What we found is worth understanding before you let any of these numbers inform a decision.

The numbers do not agree

Published claims about ERP outcomes span an extraordinary range. Secondary articles attribute failure rates in the high sixties and low seventies to Panorama Consulting, along with cost overrun figures well above one hundred percent.

Panorama's own published summary of its 2026 report describes something considerably more modest: that more than a quarter of organisations exceeded their project budgets. "More than a quarter exceeded budget" and "average overruns of one hundred and eighty nine percent" are not the same claim, and the second does not follow from the first.

The same firm's 2019 report was widely cited for the finding that 88% of organisations successfully implemented ERP. A separate study by Mint Jutras reported a single failure across a sample of several hundred organisations.The same research houses have been cited for both "most ERP projects succeed" and "most ERP projects fail" — sometimes within the same few years.

Why the range is so wide

Three things drive the divergence, and none of them is fraud:

• "Failure" is undefined. Does a project fail if it goes live late? Over budget? If it delivers but nobody adopts it? Each definition produces a different number, and few sources state which they used.
• Samples are self-selected. Organisations that engage a consultancy to review a troubled programme are not a random sample of all ERP programmes.
• Citations get laundered. A figure appears in one article, is quoted by a second without checking, and by the tenth repetition it has acquired an authoritative source it never had.

The irony worth noting

Commentators have pointed out the obvious problem with the seventy percent figure: almost everyone who cites it does so while positioning themselves as the remedy. A statistic that is universally quoted by parties with an interest in it being alarming deserves scepticism regardless of whether it is true.

What to measure instead

Industry base rates cannot tell you whether your programme is in trouble. They are the wrong unit of analysis. Your programme has specific evidence available, and that evidence is knowable:

1. Whether a full business cycle has been executed end to end on migrated data.
2. Whether data reconciles to source, with a signature from outside the migration team.
3. Whether the open severity-one defect count is falling or merely being reclassified.
4. Whether cutover has been rehearsed against the clock, and what the longest run took.
5. Whether training was delivered on the configuration that will actually exist.

Every one of those has an answer today. None of them requires knowing what happened to anyone else.

Our position

We do not quote a failure rate, because we cannot verify one we would be willing to defend. What we can say from practice is narrower and more useful: programmes that reach a go-live gate without documented end-to-end testing and signed data reconciliation encounter problems at a rate that is obvious to anyone who has watched it happen.

That is not a statistic. It is a description of a mechanism, and mechanisms are more actionable than base rates.

How a statistic gets laundered

The mechanism is worth understanding because it applies well beyond ERP.

1. A research firm publishes a finding with a stated methodology and defined scope.
2. An article summarises it, dropping the methodology and rounding the figure.
3. A second article cites the first, now attributing the rounded figure to the research firm.
4. A third cites the second. By now the caveats are gone and the number reads as established.
5. The figure appears in vendor marketing, then in analyst decks, then in board papers.

At no point does anyone lie. Each step is a small, reasonable compression. The end result is a number with an authoritative-sounding source that does not say what it is quoted as saying.

The most dangerous statistics are not the false ones. They are the ones that were true under conditions nobody repeats.

Questions to ask of any ERP statistic

• What counted as failure? Late, over budget, cancelled, or delivered but unadopted? Each yields a different figure.
• Who was sampled? Organisations that engaged a consultancy are not representative of all implementations.
• How many organisations? A dramatic percentage of a small self-selected sample is not a base rate.
• When? Cloud ERP deployment differs materially from on-premise projects of fifteen years ago.
• Who benefits from the number being alarming? Usually whoever is quoting it.

Why we decline to publish a headline figure

It would be straightforward for us to select the most alarming defensible number and put it at the top of this page. It would probably improve engagement.

We do not, for a reason that is commercial as much as ethical. Our proposition is that we verify claims rather than repeat them. A firm that opened with an unverifiable statistic while selling verification would be demonstrating the opposite of what it sells.

If a prospective client checks one of our numbers and finds it does not hold, we have lost more than the engagement — we have proved the case against ourselves.

What we will say

From assessment work, a narrower and more defensible observation: the programmes that encounter serious trouble at go-live are, with striking consistency, the ones that could not produce documentary evidence of end-to-end testing and signed data reconciliation when asked six weeks earlier.

That is a statement about a mechanism, not a population. It cannot tell you what percentage of projects fail. It can tell you what to go and check this week, which is a more useful thing to know.

Using benchmarks responsibly

None of this means industry research is worthless. Used properly, benchmarks are useful for orientation — understanding what typically goes wrong, what the common failure modes are, which variables recur across studies.

What they cannot do is tell you the probability that your programme will fail. That depends on your evidence, your governance, your data, and your partner — none of which is in the benchmark.

A reasonable use: "research consistently identifies change management and data migration among the leading causes of difficulty, so we will look hard at both." An unreasonable use: "seventy percent of these fail, so we should expect to fail."

Find out where your programme actually stands.

Six questions, an instant score out of 100, and a plain reading of the risks your status reports may not be showing you. Your answers never leave your browser.

Get your free score