Why transformations fail — the 7 failure modes and the operating spine that prevents them
The short answer
Transformations almost never fail because the technology wasn't good enough. They fail in seven predictable, organisational ways: (1) no honest baseline — the programme starts from where people say things are, not where they are; (2) maturity scored to flatter — every capability rated a 3, so the scorecard is nobody's honest view; (3) everything is Wave 1 — no sequencing, forty initiatives all 'critical', none finishing; (4) strategic builds before quick wins — credibility spent before it's earned; (5) no operating model for the after — the change lands and nobody owns running the new way, so it drifts back; (6) governance by status deck — decisions narrated, not made; (7) value asserted, never proven — no baseline, no target, no actual. The fix is an operating spine with six linked segments: assessment, capability maturity, roadmap, target operating model, governance, and value. Skip one and the spine bends.
The operating spine — six segments, in order
- 01
Honest current-state assessment
Write down where you actually are, by domain — core systems, process, data, AI, operating model — with the specific pain and the business impact, not a slogan. 'Data is a bit messy' is not an assessment; 'master data is fragmented across three systems with no owner, which drives bad availability decisions' is. The business-impact line is what earns the funding.
- 02
Capability maturity, scored honestly
Score each capability today and at target on a 1–5 scale anchored to observable behaviour — and remember a scale with no 1s or 2s is a lie. Target is not '5 everywhere'; pick the level each capability genuinely needs. The gap, weighted by business value, is the raw material for the roadmap. The maturity radar's shape tells you where to spend.
- 03
The roadmap — waves, quick wins first
Turn the gaps into initiatives, sequenced into waves. Quick wins first — visible, low-dependency work that proves the team can ship and earns the credibility the big builds need. Sequence by dependency, not enthusiasm. Cap work-in-progress per wave. Every initiative gets an owner and an expected value, or it won't happen and you can't prove it later.
- 04
Target operating model — who runs it after
For every capability the roadmap builds, name who operates it in steady state. If the answer is 'the project team' or 'TBD', the change will drift back the moment the programme closes. A transformation with no operating model for the after is a renovation nobody moves into. The shift is usually from organised-by-system to organised-by-capability.
- 05
Governance that decides
Write down the decision rights — who can approve a scope change, a re-sequence, a budget move, and at what threshold. Give every RAID item an owner and an action. Run a steering forum that makes the decisions only it can make, instead of watching a RAG dashboard change shade. A steering meeting that produced no decision was a status email with chairs.
- 06
Value — baseline, target, actual
For each initiative, capture a baseline before you start, a target, and a measured actual — net of the run cost the capability creates. Roll it into one executive scorecard: planned versus realised, by wave. Value appears after delivery, as adoption lands — exactly when the team is disbanding — so keep the value tab live past go-live, or you'll deliver the capability and never capture the benefit.
Transformations fail on discipline, not technology
I have run transformation programmes, and the thing that surprises people is how rarely the technology is the problem. The cloud platform works. The new ERP works. The AI model is fine. What fails is the discipline around them — and it fails in the same seven ways almost every time.
- No honest baseline. The programme starts from where people say things are. Six months in, the “quick win” turns out to depend on a system nobody owns.
- Maturity scored to flatter. Every capability is a 3. A scorecard with no 1s and no 2s is one nobody was honest enough to fill in.
- Everything is Wave 1. Forty initiatives, all “critical”, all starting at once, none finishing. The programme runs out of attention before it runs out of money.
- Strategic builds before quick wins. The 18-month platform replacement starts before the two-week integration that would have proven the team can ship. Credibility is spent before it is earned.
- No operating model for the after. The change lands and nobody is accountable for running the new way. Within two quarters it drifts back.
- Governance by status deck. Decisions are narrated, not made. The steering committee reviews colour, not choices.
- Value asserted, never proven. “Productivity up 20%” with no baseline, no target, no actual. Finance stops believing the programme, and the next round is harder to fund.
The fix is an operating spine
A transformation is not a project plan. It is an operating spine with six segments, each feeding the next:
Assessment → Capability maturity → Roadmap → Target operating model → Governance → Value
Each segment prevents one or more of the seven failures. Skip one and the spine bends: a roadmap with no maturity baseline is a wish list; an operating model with no roadmap is an org chart for a company that doesn’t exist yet; value with no baseline is a press release. The six steps above are the spine in order — work them, and the boring, disciplined transformation that actually lands becomes the one you are running.
Part of The Job, Decoded — the operator’s series on what enterprise-operations roles actually are. This is the transformation manager, decoded.
Frequently asked
Why do most digital transformations fail?
Not on technology — on discipline. The seven recurring failure modes are all organisational: no honest baseline, maturity scored to flatter, everything treated as Wave 1, strategic builds attempted before quick wins, no operating model for the after, governance that narrates instead of decides, and value asserted without a baseline. Notice technology is not on the list. The cloud platform or the AI model is almost never why a transformation fails.
What is a target operating model and why does it matter?
It is how the organisation runs after the capability lands — the owners, the decision rights, and the hand-offs. It matters because a roadmap delivers capabilities but does not, by itself, say who runs them in steady state. If no one is named to operate the new way, the organisation drifts back to the old way within a couple of quarters. The operating model is what makes a transformation permanent rather than temporary.
What does 'quick wins before strategic builds' actually mean?
Sequence the roadmap so Wave 1 contains work that finishes — visible, low-dependency improvements — before the 18-month platform replacement. Two reasons: the quick wins prove the team can ship and build the credibility the big builds will need, and they generate the data and momentum the strategic work depends on. Starting with the strategic build spends credibility before it is earned.
How do you measure whether a transformation is actually working?
With leading and lagging indicators together. Leading indicators move early and warn early: initiatives completed versus planned, gate pass rate, RAID closed versus opened, budget burn versus progress. Lagging indicators are the proof: realised value versus baseline, the maturity re-score, adoption of the new operating model. Run both — a dashboard with only lagging indicators flatters the programme until the value fails to appear and it is too late to act.
The done-for-you version: a 10-tab Excel workbook — current-state assessment, a capability-maturity radar, a multi-wave roadmap, a target operating model, governance and a RAID log, and a value tracker — plus a 15-page operating handbook that carries one worked example through all six moves.
Get the Digital Transformation Operating Model & Roadmap Toolkit — $149 →Written by Petko Petkov — 15 years inside enterprise IT operations. Vihren Labs publishes operator-grade templates and playbooks for the enterprise IT stack.