ERP programme recovery: establishing the real position first

Late is not the same as broken

Programmes run late for ordinary reasons: a data source arrived in worse condition than expected, a key person left, an integration turned out to be two integrations. Those programmes recover on their own once the obstruction clears, and the correct response is patience plus a revised plan.

A structurally broken programme behaves differently. The date moves repeatedly and by similar amounts. Testing keeps surfacing the same class of defect rather than new ones. Nobody in the room can state, without caveats, what remains to be built. Scope is described differently by the sponsor, the delivery lead and the business users, and each description is sincere.

The reliable signal is not the size of the delay. It is whether the organisation can describe what is left with confidence. When it cannot, replanning produces another plan of the same quality as the last one.

Signals worth taking seriously

• The same defects reappear after being closed, which usually means environments or data are not controlled.
• Requirements are being clarified during build rather than before it, so design decisions are being made by developers under time pressure.
• Cutover has never been rehearsed end to end, and the migration approach exists as a document rather than as a tested run.
• Business users have stopped attending, which is normally withdrawal rather than satisfaction.
• Status is reported as a percentage complete that nobody can decompose into finished, tested items.
• The partner relationship has become contractual, and both sides are protecting position rather than solving the problem.

Three or more of these together rarely resolves through effort alone. It resolves through re-establishing facts.

The order that matters

The instinct in a stalled programme is to fix the most visible problem. That is usually the wrong first move, because the visible problem is often a symptom of an upstream one. We work in a fixed order.

• Establish the true position: what exists, what is tested, what is only designed, and what is assumed. This is evidence gathering, not opinion gathering.
• Control the environments and the data. Until builds and data are reproducible, no test result means anything and no estimate is safe.
• Re-baseline scope against what the business actually needs to go live, separated from what it would like eventually.
• Re-establish decision rights, so that a single named person can settle a design question the same week it is raised.
• Only then agree a date, and agree it against gates rather than against a milestone chart.

Skipping step one to reach step five faster is the most common failure in recovery work. A date agreed on unverified information is the same commitment that produced the current position.

The part that is not technical

By the time a programme is described internally as being in trouble, people are tired and reputations are involved. Someone recommended the platform. Someone signed the business case. Someone has been reporting green.

Recovery work that ignores this stalls, because the information needed to establish the real position is held by people who have a reason not to volunteer it. We run the examination as a factual exercise with no attribution of blame, and we are explicit with sponsors that this is the condition for getting accurate answers.

It also means being honest about our own findings. If the platform choice was sound and the delivery approach was not, we say so. If the requirement was never achievable in the budget available, that has to be said to the board, not softened.

What a recovery should leave behind

A recovery is not finished when the system goes live. It is finished when the organisation can run the platform without the recovery team, which means the controls introduced during recovery have to be ones the internal team can operate.

In practice that means documented environments, a tested cutover, a defect process the business understands, and reporting that shows finished work rather than effort. Anything that only functions while an external team is present is not a recovery, it is a dependency.