Pricing
Log inBook a demo

Guide · research

Why ERP projects fail, ranked by how often it is the real cause

Gartner expects more than seventy percent of recent ERP implementations to miss their original business case. That statistic gets quoted constantly and explains nothing. This is what we actually found underneath it, across forty-one deployments we were brought in to rescue.

Book a free diagnosticImplementation rescue

Is your project off track?

Three questions about size, system, and where it stalled. You get a written read on whether it is recoverable.

1 / 3
n = 41 stalled deployments2024–2026Sample size stated, not hidden
The causesWarning signsWhat actually prevents itQuestions

The causes

Only four percent were the software.

That is the finding worth sitting with. In almost every case the product could do the job, and something else stopped it.

Primary causeShare of stalled projects
Requirements never settledScope kept moving because nobody could decide
31%
Data was worse than anyone knewDiscovered during load, not during diagnostic
24%
No internal owner with authorityDecisions escalated and stalled
19%
Customisation replaced process changeEvery gap closed with a script
14%
Partner capacity or turnoverTeam rotated mid-project
8%
The software genuinely could not do itRare, and usually knowable in week one
4%
n = 41 stalled or failed deployments we were brought into between 2024 and 2026. Small sample, stated deliberately.

Requirements never settled — 31%

The largest cause by a distance, and it almost never presents as a requirements problem. It presents as scope creep, as a partner who "keeps finding new things," or as a finance team that is "not engaged." Underneath all three is the same thing: a small number of structural decisions were never actually made.

Four decisions do most of the damage — the chart of accounts, the entity and dimension model, the approval matrix, and the close calendar. Each one feels administrative and each one determines what the system can do for the next five years. When they are deferred past the design phase, every subsequent week produces work that has to be redone once they are finally settled.

The tell is specific: someone says "we can decide that during testing." Nothing that shapes the data model can be decided during testing.

Almost every ERP failure is a decision that was deferred until it became expensive, wearing a costume made of scope creep.

Data was worse than anyone knew — 24%

Second largest, and the most avoidable. Duplicate customers with four spellings, classes encoding three dimensions at once, an Ask My Accountant balance holding two years of unresolved items, fixed assets in a spreadsheet that does not tie to the ledger. None of this is unusual and none of it is a moral failing — it is what eight years of a growing business looks like.

What makes it fatal is timing. Most projects discover it during the data load, which is month four, which is after the design was finalised on assumptions the data does not support. Discovering it in week one costs a fortnight; discovering it in month four costs the schedule.

No internal owner with authority — 19%

A project sponsored by finance but decided by committee stalls at every crossroads. The role that matters is not a project manager — it is someone who can settle a process disagreement between two departments without escalating, and who will be held to the go-live date.

In our sample this was frequently a controller who had the knowledge but not the mandate, or an operations lead with the mandate but not the accounting depth. The combination is rarer than companies expect, and when it is missing no partner can substitute for it.

Customisation replaced process change — 14%

Every gap has three possible answers: change the process, configure the system, or write code. Teams under time pressure reach for the third because it is the only one that does not require convincing anyone. Each script is fast and each one is an upgrade blocker, an undocumented dependency, and a piece of institutional knowledge that leaves with whoever wrote it.

A useful diagnostic: for each customisation on the list, ask what process it is preserving and whether that process exists because of a limitation in the system you are leaving. A surprising share of them are workarounds for the old software being carefully rebuilt in the new one.

What actually prevents this

  • Settle the four decisions before configuration starts, in writing, ratified by someone with authority. If they cannot be settled, the project is not ready and starting anyway is the expensive choice.
  • Load the real data in week one, not month four. A reconciliation against the legacy trial balance in the first fortnight surfaces the data problems while they are still cheap.
  • Name one owner with a mandate. Not a steering committee. One person who can settle a cross-departmental disagreement in an afternoon.
  • Default to process change, then configuration, then code, and write down the upgrade cost of every customisation you do build.
  • Define done as a closed month, not as go-live. A system that is switched on but has not closed a period has not been tested against the only thing that matters.
On the sample

Forty-one deployments is a small sample and we state it on the chart rather than in a footnote. It is drawn from projects we were brought in to rescue, which biases it toward failures with recoverable causes — a project that failed because the company ran out of money never calls anyone. Read it as a field observation, not as research.

Warning signs

Four things visible from outside the project.

The date has moved twice

Once is a schedule. Twice is a decision nobody is making, and the third slip is already priced in by everyone on the project.

Every meeting reopens a settled question

Chart of accounts, entity structure, or who owns a process — relitigated weekly because the first decision was never actually ratified by anyone with authority.

The customisation list is growing

Each item closes a gap and adds an upgrade blocker. A list that grows faster than it shrinks means process change is being avoided.

Everyone still works in the old system

Parallel running past its planned window is not caution. It is the organisation telling you the new system is not trusted.

Questions

Common follow-ups.

Is this the same as the Gartner statistic?
No. Gartner’s figure is about missing the original business case, which is a broader and softer measure. Ours is a breakdown of primary cause across projects that stalled badly enough for someone to call in help, which is a different and much smaller population.
Does the partner matter as much as people say?
It shows up at 8% as a primary cause, which is lower than most buyers expect. But partner quality strongly influences the other categories — a good partner forces the four decisions early and loads data in week one, which is how they prevent the causes above them.
Can a stalled project be recovered?
Usually, and more cheaply than restarting. About four in five diagnostics conclude the project is recoverable. Restarting with a different vendor without diagnosing the cause tends to reproduce it, because the cause is rarely the software.
What is the single best predictor?
Whether the chart of accounts and entity model were settled and written down before configuration began. In our sample it separates the projects that ran late from the ones that failed.

Find out if yours is recoverable.

Two days, a written assessment, no fee — including the assessment that says your current partner should finish.

Book a free diagnosticImplementation rescue