Why do ERP projects fail?

The short answer

ERP projects fail because a company tries to do two hard things at once — change how it works, and change what it runs on — and plans only for the second. The software project has a budget, a timeline and a partner. The business change has none of those. It has a steering committee that meets monthly, key users who are “involved as needed”, and data that will be cleaned “later”.

The specific causes are remarkably consistent across companies, industries and decades: processes nobody defined, requirements that grew after the contract, data that was never cleaned, a standard system bent to fit old habits, the daily users left out of the room, decisions starved for months, and a go-live treated as a date rather than a state. Every famous disaster is three or four of these at the same time, and every one of them was visible months before it happened.

What is said less often: these are all failures of translation — of the work needed to fit a rigid system to a real company, by hand, under time pressure. That is a property of how ERP has been built, and it is worth separating what the customer got wrong from what the architecture made likely. This article does both.

What “failure” means — and how often it happens

You will read that “50 to 75 percent of ERP projects fail.” You will also read that most companies are satisfied with their ERP. Both are true, because “failure” means four different things, and the numbers change with the definition.

Read together, the numbers say something more useful than any single one: the normal ERP project is somewhat late, somewhat over budget, and delivers less than the slide deck said. Outright catastrophe — the abandoned system, the company that cannot ship — is rarer, perhaps one project in five or six. But the everyday failure, the project that goes live and quietly does not deliver, is the majority experience. That is the one this article is mostly about, because it is the one you will not read about in the news.

The famous ones, and what each teaches

The disasters that made the papers are worth a minute each — not for the schadenfreude, but because every one of them is a small company’s mistake at a scale where it became visible.

Notice that none of these companies lacked money, consultants or software brand names. What they lacked was a decision about how they wanted to work, a go-live that was a state rather than a date, and someone willing to say “not yet” to a steering committee.

The seven causes, in the order they strike

Failure is rarely one thing. It is a sequence, and the sequence is so regular that you can date each cause to a phase of the project.

1. Nobody decided how the business should work

The project starts with “implement the system” instead of “this is how an order should flow through the company from now on.” The analysis phase then becomes the place where that decision is supposed to happen — with consultants on the meter, in workshops where three departments each defend their version. Software multiplies clarity and chaos with equal enthusiasm; if the process is undecided, the system faithfully implements the argument.

2. The requirements were the vendor’s, and then they grew

Two failure modes with one root. Either the requirements came from the vendor’s template — a catalogue of their features phrased as your needs — or they were never written down at all, and are discovered in month six as “but we obviously need that.” Additional scope found mid-project is the single most cited cause of budget overruns. A twenty-page requirements document, written before the first demo, is the cheapest insurance in the whole project; we explain how in How do you choose the right ERP?

3. The data was going to be cleaned “later”

Every project discovers its data in the first migration test, and every project underestimates what it finds: duplicate customers, article numbers in four formats, prices that live in someone’s head, the fields repurposed in 2019. Cleaning is assigned to “the business”, which is busy running the business, and postponed until it collides with go-live. Then the new system starts life with the old system’s errors — and, unlike the old system, everyone trusts it.

4. The standard was bent to fit old habits

The instinct is to make the new system do exactly what the old one did, plus the fixes. Each customisation is approved to avoid a fight, each is small, and together they are the budget — and the upgrade problem for the next decade. Lidl is the extreme case; the ordinary case is a mid-sized company that spent 40 percent of its implementation coding around the standard and is now stuck on a version from 2021 because the customisations would break.

5. The people who use it every day were not in the room

Surveys have named change management as the number one reason for ERP failure for twenty years, and it has not changed because the underlying mistake has not changed: the project is run by management and IT, and the people who will spend eight hours a day in the system meet it at training, two weeks before go-live. They were never asked where the system had to be fast, what the exceptions were, or what they would do when it did not fit. So they do what people do — they route around it, and the shadow spreadsheets return.

6. Decisions starved, and the project lead had another job

Projects stall on the customer side far more often than on the vendor side. A steering committee that meets monthly turns a four-month project into an eight-month one; a project lead with the job on top of their real one answers questions on Fridays. Meanwhile the consultants bill, the team waits, and the momentum that carried the kick-off drains away. Every project needs one owner with the time and the authority to decide within days — and most SME projects do not have one, because the person who could do it is the CEO, and the CEO is busy.

7. Go-live was a date, not a state

The date was announced to the company in month three. By month nine the plan serves the date: testing is compressed, training shortened, the parallel run cancelled, the peak season ignored. Go-live should be a set of conditions — these tests passed, this data reconciled, these people trained, this fallback ready — and if the conditions are not met, the date moves. Every company in the previous section went live on a date.

Anatomy of a failing project

Put the seven causes on a calendar and you get the same story, in almost every company that tells it. If you are in a project now, find your month.

The last line is the important one. Most failed ERP projects are never called failures. They go live, they are declared a success, and the company spends the next decade paying for a system it works around. That is what “70 percent do not fully meet their goals” looks like from the inside.

Early-warning signs

Every cause above is visible months before it does damage. These are the signs, and each one has a phase where it can still be fixed cheaply.

What the survivors did differently

The companies whose projects worked did not have better software or more money. Their projects are boring to describe, because they did a handful of unglamorous things, in the right order, and refused to skip them under pressure.

None of this is secret. It is in every implementation methodology every vendor publishes. The reason it is skipped is that every item costs time before go-live, and the pressure in an ERP project always points toward the date. The survivors are the companies where someone had the authority to resist that pressure — and used it.

Whose failure is it?

Ask a vendor why ERP projects fail and you will hear the seven causes above, all of them on the customer’s side of the table: undefined processes, slow decisions, dirty data, absent users, scope creep. Ask a customer and you will hear about consultants who did not understand the business, a system that could not do the obvious thing, and a price that doubled. Both are describing the same project, and both are right — which should tell you something about the project.

Look at the seven causes again. Every one of them is a failure of translation: of the work required to fit a rigid, generic system to a specific, living company, by hand, through consultants, under a deadline. The customer’s process has to be decided in advance because the system cannot bend later. The data has to be perfect before migration because the system cannot understand it. The users have to be trained because the system will not adapt to them. Every deviation has to be coded because the standard is fixed. And every one of those steps costs consulting days, which is why the pressure toward the date never lets up.

The industry has spent forty years describing that as the customer’s job and the customer’s failure. It is more honest to say that the architecture made the failure likely and then charged for the attempt. The customer mistakes are real. But they are mistakes that a system which could adapt to the company — instead of the other way round — would make far less consequential. That is not a defence of slow decisions or dirty data. It is a description of why the same decisions and the same data sink one project and barely dent another.

How AI changes the odds

If most failure is translation, then a system that needs less translation fails less. That is the honest case for AI-native ERP, and it is worth stating precisely rather than as a slogan.

Three of the seven causes are directly about translation, and they shrink. Customisation stops being a coding project when the people who use the system can reshape it in plain language — a field, a workflow, a view — and change it again next month, so the fear of cementing the wrong process loses its force. Data cleaning stops being a three-month sprint the business has no time for when migration is assisted by a system that understands what the old data means and asks about the rest. Scope creep stops being a budget catastrophe when the discovered requirement is an afternoon’s change rather than a change request at a day rate.

Four of the seven do not disappear, and it would be dishonest to claim they do. A company still has to decide how it wants to work. Someone still has to own the project and decide within days. The people who use the system still have to be in the room — though a system that adapts to them makes their involvement productive rather than defensive. And go-live is still a state, not a date. What changes is the cost of every mistake: in a system that adapts, an undecided process is a week of iteration, not a six-figure customisation, and a late discovery is a Tuesday, not a crisis.

Frequently asked questions