Why ERP Projects Fail

Ignore the statistics

You will find claims that 50, 60 or 75 per cent of ERP projects fail. The figures come from surveys with inconsistent definitions of failure — over budget, late, or not delivering expected benefit are three different things, and most studies blend them.

What is worth knowing is not the rate but the mechanism, because the failure modes are few and they repeat. Four of them account for almost everything.

One: customising around a broken process

The commonest and most expensive. The system does something differently from how you do it today, so the system is changed to match.

Sometimes right. Usually the process being preserved is not a business requirement at all — it is the shape of your previous system's limitations, or an accommodation for a person who left in 2019.

The cost is paid repeatedly. Every customisation has to be retested at every upgrade, and enough of them eventually mean you cannot upgrade at all. Businesses stranded on a version from years ago are rarely there by choice.

Warning sign: a change request whose justification is that this is how we have always done it, with no figure attached to what the difference is worth.

Two: data nobody cleaned

The project plans a migration and treats it as a technical task with a duration. It is not technical. It is a long series of decisions about which version of each fact is true, and only people who know the business can make them.

Unmade decisions surface after go-live as duplicate customers, items with inconsistent units, and balances that will not reconcile. Each one erodes confidence, and confidence is what makes people use the system rather than keep a private spreadsheet.

Warning sign: the first test load has not happened by the time configuration is complete. If data work is scheduled to start after configuration, it is already late.

Three: no internal owner

The assumption that the vendor will deliver the project. They will not, and it is not their job. A vendor configures software; they cannot decide your chart of accounts, adjudicate between two departments wanting different things, or insist a reluctant manager adopt a new process.

Those decisions need one internal person with the authority to make them and the availability to make them quickly. A steering committee meeting fortnightly is not that: it means every decision costs up to two weeks, and an implementation contains hundreds.

Warning sign: decisions sitting open for more than a week, or a project where the most frequent status update is awaiting a decision.

Four: go-live treated as the finish

The vendor demobilises on go-live because that is their contracted milestone. The internal team, exhausted, returns to the day job. Then the first month-end arrives, in an unfamiliar system, with nobody assigned.

This is when workarounds get invented, and workarounds set hard. A spreadsheet introduced in week two to get past one problem is still there two years later, and it is now the reason three other things do not work.

Warning sign: no budget and no named people for the eight weeks after go-live.

The sequence it usually follows

Failing projects tend to deteriorate in a recognisable order, which is useful because the early signs are cheap to act on.

1. Scope grows quietly. Individually reasonable requests, no single one large enough to challenge.
2. The timeline holds while the content shrinks. Testing and training are compressed because the date is fixed.
3. Data work starts late and is handed to whoever has capacity rather than whoever has knowledge.
4. Go-live happens on time and in name. Several processes are running on manual workarounds.
5. The first close takes three weeks and needs the old system to verify it.
6. Confidence goes. People revert to spreadsheets, and the system becomes an expensive place to retype things.

Step two is the cheapest place to intervene, and the one most often missed. When the date is fixed and the scope is not, something gets cut, and it is always testing and training because they are the only things with no external dependency.

What predicts success

The failure modes are better documented than their inverse, which is unhelpful if you are about to start. The projects that go well tend to share four things, and none of them is about the software.

A narrow first scope. The businesses that succeed go live with less than they wanted and add later. Finance and one operational area is a good first phase; everything at once is how a timeline becomes fiction.

A willingness to change process. Teams that adopt the system's standard way of working, except where a process is genuinely differentiating, finish sooner and upgrade cleanly for years afterwards. This is mostly a leadership decision rather than a project one — someone senior has to be willing to say that a long-standing way of working is not worth preserving.

Data treated as a workstream. Not a task inside the plan but a stream with its own owner, starting before configuration and running the whole length of the project.

A defined done that is not go-live. Successful projects set the target as a clean close in the new system and resource the weeks up to it. Go-live becomes a step rather than a finish line, which is the correct relationship.

What recovery looks like

Projects in this state are recoverable, and rarely by pushing harder on the original plan.

• Stop and inventory the workarounds. Each is a configuration gap or a training gap; until they are listed, nobody knows which problem they have.
• Re-scope to the five processes that must work. Defer everything else explicitly rather than letting it drift.
• Fix the data properly, even if that means a second migration. Everything downstream depends on it and no amount of training compensates.
• Name an owner with authority, if that is what was missing. This is usually the single highest-impact change.
• Reset the definition of done to a clean month-end close, and resource the weeks leading to it.