Research · updated August 2026

The seventy percent figure, examined

Almost every ERP article cites a failure rate between 50 and 75 percent, usually without a source. We went looking for where the number comes from, and the answer is more interesting than the statistic: most of these studies are measuring something buyers would not call failure.

Worried about yours?

Tell us where your project is. We will tell you honestly which risks apply and which do not.

1 / 3
11 cited studies tracedDefinitions comparedWe use the figure too
11frequently cited studies traced to source
4distinct definitions of "failure" among them
2that measured abandonment rather than overrun
3with no published method at all
typical elapsed weeks · highlighted phases are where buyers under-investRealising you need to look · usually 6–18 months of tolerating itBuilding requirements3w · the phase that determines everythingShortlisting2w · three products, not tenDemos & scenarios4w · your data, your workflows, or it proves nothingReferences & diligence2w · two customers who left, not just two who stayedNegotiation3w · licence and implementation, togetherImplementation20w · where the decision is actually tested

Where elapsed weeks go in a typical buying process. The two highlighted phases are the ones buyers under-invest in and the ones that predict outcomes.

What we found

What tracing the sources actually shows.

This is less a research finding than an act of citation archaeology, and the result changes how the figure should be used.

Most citations lead nowhere

Three of the eleven most-cited figures trace to articles with no published method, sample, or definition. They are quoted authoritatively because they have been quoted before.

Four definitions of failure

Exceeded budget. Exceeded schedule. Failed to deliver expected benefits. Abandoned. These produce wildly different rates and are quoted interchangeably.

Overrun is not abandonment

Only two of eleven measured projects that were abandoned. The rest measured overrun against an original estimate, which is a different and much more common thing.

The estimates were the problem

A project that overruns an estimate nobody defended is evidence about the estimate as much as about the project. Several studies do not distinguish the two.

Benefit realisation is rarely measured

The most useful definition — did it deliver what it was bought for — is also the least measured, because it requires a baseline almost nobody establishes.

The figure is still directionally right

Our own sample of stalled projects and every practitioner we know supports the conclusion that these projects go badly at a high rate. The number is soft; the phenomenon is not.

Why we bothered

We quote the seventy percent figure on our own site, which is why we went looking for its provenance. If we are going to use a statistic in sales material, we should be able to say where it came from and what it counted.

The honest answer is that the specific number is soft. It comes from a small number of studies with incompatible definitions, several of which are twenty years old, and it has been repeated into apparent authority. We will keep using it, with this page attached, and you should discount it accordingly.

We cite this figure ourselves. This page exists because we could not say where it came from, and that seemed like a problem worth fixing publicly.

What definition would actually be useful

A buyer wants to know one thing: what is the probability that this project delivers the outcome I am buying it for, within a range of cost and time I would have accepted in advance.

Almost no study measures that, because it requires a baseline recorded before the project starts and revisited afterwards — and organisations that have just completed a difficult ERP implementation are not eager to run that assessment. The measurement gap is not accidental.

Overrun against what

Most of these studies measure variance against an original estimate. That is worth knowing and it conflates two different failures: a project that went badly, and a project that was estimated badly.

In our own sample of stalled implementations, the original estimates were frequently indefensible on day one — a six-month timeline for a nine-entity migration with unexamined data. Counting that as an implementation failure is true and misses where it actually went wrong.

What we would say instead

Rather than a rate, three statements we can support from our own work and would defend. Requirements that were not derived from transactions are the most common cause of stall. Data quality is nearly always worse than the diagnostic phase established. And a project without someone empowered to make cross-departmental decisions in a day will queue until it stalls.

Those are more useful than a percentage because they are actionable. A buyer cannot do anything with a seventy percent failure rate except worry; they can do something about all three of those.

How we measured this

We traced the eleven most frequently cited ERP failure statistics appearing in vendor material, analyst content, and trade press between 2023 and 2026, following citations back to a primary source where one existed.

For each we recorded: the definition of failure used, sample size, sample composition, publication date, and whether a method was published. Three had no traceable primary source. Four dated from before 2010 and described enterprise on-premise implementations that bear limited resemblance to mid-market cloud deployments.

This is citation analysis, not new primary research. It does not establish a better failure rate and it does not claim to. What it establishes is that the widely quoted figures are weaker than their usage implies.

Our own complementary sample — 41 stalled deployments, analysed by primary cause — is published separately and has its own substantial limitations, chiefly that it is self-selecting toward severe failures.

Questions

Common follow-ups.

So is the 70% figure wrong?
It is soft rather than wrong. The underlying phenomenon — these projects go badly at a high rate — is well supported by practitioner experience including ours. The precise number is not.
Why do you still quote it?
Because it is directionally right and widely understood. This page exists so that anyone who asks where it comes from gets an honest answer.
What would a better statistic measure?
Whether the project delivered the outcome it was bought for, within a cost and time range the buyer would have accepted in advance. Almost nobody measures that, because it needs a baseline.
Are cloud implementations better?
Probably, and we cannot demonstrate it. Several of the foundational studies predate cloud entirely and describe a different kind of project.
What should we actually worry about?
Requirements not derived from transactions, data worse than the diagnostic found, and no one empowered to decide across departments. Those three explain most of what we see.

Three risks beat one statistic.

Requirements from transactions, data examined properly, and a decision-maker with real authority.