Why ERP programmes drift, and the checkpoints that catch it

ERP programmes have a reputation for failing dramatically. In practice they rarely do. They drift.

Scope expands quietly. Integration work gets scheduled "after the core is stable". Testing coverage is described in a plan and then measured in optimism. By the time anyone says the word drift, the go-live date is already a political commitment rather than an engineering one.

Drift has a shape

Almost every drifting programme shows the same three symptoms, in roughly the same order.

1. Scope grows without a matching decision

A requirement is added because a process owner raised it in a workshop. It is reasonable on its own. Nobody asks what it displaces, and nobody records the trade-off.

The fix is not "no change requests". It is making every addition cost something visible: a date, a scope item removed, or an explicit acceptance of risk. Programmes that write that down stay honest. Programmes that accept changes in meetings do not.

2. Integration becomes the residual category

The core platform is scoped carefully. Everything around it — the systems that stay, the data that has to move, the reports that still matter — is scoped as whatever is left.

Integration is where ERP programmes actually fail, because it is the only place where two organisations' assumptions have to agree. Treat it as first-class work with its own owner, its own plan and its own readiness criteria, not as a phase that begins after configuration.

3. Testing measures coverage, not confidence

A test plan that reports "85% of scripts executed" is answering the wrong question. The useful measures are: which business scenarios have been proven end to end, and which of those were proven with real data volumes.

If nobody can name the five scenarios that would stop go-live, the programme does not yet know whether it is ready.

The checkpoints that catch it

You do not need more governance. You need three or four moments where something uncomfortable has to be produced.

Before selection is finalised: current-state process maps including known exceptions. If these do not exist, the requirements were written against an imagined business.

Before build starts in earnest: an integration plan naming systems, owners and data flows — including the systems nobody wanted to own.

Before migration rehearsal: a data cleansing scope with named responsibilities, and a reconciliation approach agreed in advance.

Before go-live: a readiness decision made against written criteria, by someone with the authority to say no. A date that cannot be moved is not a plan; it is a hope with a calendar entry.

What this means for your programme

If your programme is already in flight, none of this requires a restart. A short independent review usually establishes where scope, integration or testing has drifted, after which the question is what to change — not who is at fault.

The honest position is that some drift is normal. What is not normal is discovering it in the week before go-live.