Why Seven in Ten Transformation Programmes Stall
Roughly seven in ten transformation programmes fail to deliver their business case. Having audited a good number of them after the fact, the causes are consistently organisational rather than technical.
Pattern one: the business case was never owned
The benefits case is written to secure approval, then filed. Nobody in the operating business carries a target that depends on it, so when the programme slips there is no constituency fighting for the outcome — only for the go-live date.
Intervene by assigning every quantified benefit to a named operational owner before the build starts.
Pattern two: data migration is treated as a task
It is not a task, it is a programme inside the programme. Unreconciled opening balances are the most common reason a technically successful go-live becomes an operational crisis in week two.
Intervene by requiring a full reconciliation rehearsal on production-like data before any cutover date is committed publicly.
Pattern three: readiness is asserted rather than tested
Sites report themselves ready because reporting otherwise is career-limiting. Nobody has actually run a day of business end to end in the new system.
Intervene with independent readiness assessment against objective criteria, and give each site a real route to say no without penalty.
Pattern four: the integrator and the client are managing different projects
The integrator manages to contract; the client manages to expectation. The gap stays invisible until change requests start arriving, at which point both parties are correct and neither is delivering.
Intervene by making scope disputes a scheduled governance item rather than an escalation, so they surface while they are still cheap.
None of these are technology failures, which is why adding technical resource to a stalling programme so rarely helps. The intervention point is almost always governance, and almost always earlier than it feels.