Seven reasons ERP implementations slip, and how to catch them early

ERP projects rarely fail suddenly. They slip by a fortnight, then another, and somewhere around month five everyone privately knows the date will not hold. Each of these patterns gives a signal weeks before it becomes a delay.

1. Discovery was a formality

The commonest root cause. Discovery is run as a week of meetings producing a document nobody reads again, and configuration starts against assumptions rather than findings. The gaps then surface during user testing, when changing them is at its most expensive.

Early signal: the scope document contains no surprises. Real discovery always turns up at least one process that works differently from how management described it.

Ask: “What did you find that we did not already know?” If the answer is thin, discovery has not happened yet.

2. Data migration was scheduled last

Migration is planned as a task near go-live, on the assumption that exporting and importing masters is mechanical. Then it turns out the item master has four spellings of the same supplier, opening balances do not agree with the trial balance, and nobody can say which of two customer records is current.

Cleaning data is slow, and it is work only your team can do, because only your team knows which record is right.

Early signal: nobody has yet pulled a full export of masters and looked at it.

Ask: “Can we see the item and customer master exported today?” Do it in week one, not week twelve.

3. The scope grew without the date moving

A module is added. A report becomes “just one more”. An integration is agreed in a corridor. Each addition is small and reasonable, and the go-live date stays where it was because nobody wants to be the person who moves it.

Early signal: no change log exists. If additions are not being recorded and costed, they are being absorbed.

Ask: “What has been added since the scope was signed, and what did each item cost in days?”

4. One person is carrying the project

A single capable person is the project owner, the superuser, the tester and the trainer. The project moves at their pace and stops entirely when they take leave or get pulled into month-end.

It is also a serious risk after go-live: when that person leaves, the organisation loses its only operating knowledge of the system.

Early signal: the same name appears against every open item.

Ask: “Who else can test the purchase flow?” If nobody can, that is the finding.

5. Users saw the system for the first time at training

Configuration runs for months, and users meet the result a fortnight before go-live. They immediately raise objections that are correct, obvious and expensive to address at that point. Adoption then suffers, because the first experience of the system was being told that what they asked for was too late.

Early signal: there has been no demonstration to anyone outside the core team in a month.

Ask: “When did an actual end user last click through this?” Fortnightly demos to real users surface this cheaply.

6. Customisation replaced a decision

Two departments disagree about a process, so the system is built to support both. This is the most expensive form of delay, because it is invisible: it looks like progress, it is billable, and it creates a system that is harder to use and harder to upgrade than the business needed.

Early signal: a requirement is justified by “that is how the Kochi branch does it” rather than by a business reason.

Ask: “Which standard behaviour does this replace, and what happens if we simply use the standard?”

7. Go-live had no exit criteria

The date was set at kick-off and never attached to conditions. As it approaches, the question becomes “are we ready?”, which is unanswerable, so the project either goes live unprepared or slips indefinitely while people argue about readiness.

Early signal: go-live is a date rather than a checklist.

Ask: “What specifically must be true for us to go live?” Write it down in week two: balances reconciled to an agreed tolerance, every role trained, a rehearsed cut-over, a rollback plan, and a named owner for each open issue.

The common thread

Every one of these is a communication failure rather than a technical one, which is why the remedies are questions rather than tools. A fortnightly review that asks them honestly will catch most of this while it is still a fortnight, not a quarter.

The other common thread is that each of these slips is cheaper to fix early by roughly an order of magnitude. That is the whole argument for raising them when they are still awkward rather than urgent.