Every transformation roadmap has a list. Very few have a sequence. The list ranks capabilities by importance; the sequence ranks them by dependency — and the difference decides whether the programme compounds or stalls.
In what order should transformation capabilities actually be installed — and why does most sequencing get this wrong?
The reversal
The dominant sequencing heuristic is 'quick wins first'. Cross-industry research on transformation delivery1 shows that quick-win sequencing produces early momentum and late failure: the capabilities that would have unlocked the next twelve months are deferred because they were not quick, and the programme runs out of runway before they land. The higher-leverage heuristic is dependency-first — sequence the capability that unlocks the greatest number of downstream capabilities, even if it is slower and less visible. Quick wins are then extracted along the way as by-products of the dependency chain.
The insight stack
What actually moves the P&L
Map dependencies before priorities
For every capability the transformation intends to install, document which other capabilities it depends on and which it enables. The dependency map — not the priority list — is the sequencing artefact. Capabilities that enable many others belong at the front; capabilities that depend on many others belong later, however visible or politically attractive they are.
Front-load data, decision rights, and cadence
Three capabilities enable almost every other: data infrastructure, decision-rights clarity, and operating cadence design. Whatever the transformation's headline outcome, these three should sit in the first two quarters. Attempts to install downstream capabilities without them tend to produce brittle results that reverse within a year.
Sequence capital-intensive capabilities against evidence, not year-plans
Capital-intensive capability installs — platform builds, ERP replatforms, large process redesigns — should be sequenced against an evidence gate: the preceding lighter-touch capabilities have produced the operating clarity that justifies the capital. Sequencing them against a year-plan invites capital-before-clarity, which is the pattern behind most transformation over-runs.
Reserve the last quarter of the roadmap for absorption, not new capability
Transformation roadmaps that fill every quarter with new capability installs produce absorption failure: the operating team never gets the runway to integrate the changes, and the last-quarter capabilities are installed onto a team that has not yet absorbed the earlier ones. The compounding pattern reserves the last quarter for absorption, hardening, and business-as-usual transition — not for the final capability push.
Re-sequence on evidence, not on schedule pressure
Schedule pressure produces the wrong re-sequencing decisions: capabilities are dropped or brought forward on political rather than dependency grounds. Formal re-sequencing every two quarters, against the updated dependency map and the emerging evidence, keeps the roadmap aligned with the business the transformation is producing rather than the business it was designed for a year ago.
Case example
A £310M industrial group re-sequencing a stalled roadmap
The problem: an eighteen-month transformation had installed six of nine planned capabilities but produced only 30% of forecast operating impact. Dependency mapping surfaced that the two capabilities enabling most downstream value — a data-infrastructure baseline and a decision-rights refresh — had been sequenced last because they were unglamorous and slow. The remaining budget was re-sequenced: the two enabling capabilities were installed in months 19–24; the three deferred capabilities were re-launched in months 25–30 onto the new foundation. Twelve months after the re-sequence, operating impact reached 82% of original forecast, and the two capabilities the original roadmap had listed as final became the enabling layer of the next transformation cycle.
Mini-playbook
Six-step dependency-first sequencing
Build a dependency map covering every capability in the roadmap.
Front-load the three enabling capabilities: data, decision rights, cadence.
Gate capital-intensive installs on evidence from the lighter-touch predecessors.
Reserve the final quarter for absorption, not for new capability.
Re-sequence every two quarters against updated dependency and evidence.
Extract quick wins as by-products — never as the organising principle.
How Strategy Labs installs this
Anchored to Transformation Roadmap
Strategy Labs sequences transformation roadmaps inside CAE using a dependency-first template. The seven-stage engagement lifecycle carries the dependency map, the evidence gates, and the absorption quarter as governed artefacts, so re-sequencing decisions are anchored in evidence rather than in schedule anxiety.
Dependency benchmarking, decision-latency analysis, and capability-maturity baselining run inside PDC, so the sequencing is calibrated against primary evidence and comparable-organisation reference data — not against generic transformation templates.
Frequently asked
Related questions executives ask
- How is dependency-first different from a critical path?
- A critical path assumes fixed activities and computes the fastest route through them. Dependency-first sequencing asks a prior question: which capability, if installed first, most reduces the risk and duration of the remaining programme? It is a strategic question, not a scheduling one.
- Doesn't this delay early results?
- Not usually. Front-loading enabling capabilities produces less-visible but larger downstream throughput; quick wins are extracted as by-products. The pattern that delays results is priority-first sequencing that installs downstream capabilities onto a missing foundation.
- How often should the roadmap be re-sequenced?
- Every two quarters is the workable cadence. More frequent re-sequencing produces churn; less frequent lets the roadmap drift from the reality the transformation is producing.
Over to you
If you re-drew your current transformation roadmap in dependency order rather than priority order, which capability moves to Q1 — and what does that reveal about your first year of results?
Continue reading
More Transformation Systems briefings
Why do most transformation programmes fail in execution, not in design?
Most transformation programmes fail not because the strategy was wrong, but because the programme was a project list held together by a Gantt chart. Architecture, not activity, is what compounds.
Read briefingWhy does 'benefits tracking' consistently overstate transformation value?
Every transformation has a benefits tracker. Almost none has a value-realisation system. The gap is why most boards discover, two years in, that the reported £40M and the audited £11M are describing the same programme.
Read briefingWhy do so many transformations stall at the seam between strategy and delivery — and what closes the gap?
Roughly seven in ten transformations fail. Almost none of them fail on strategy. They fail on the joinery between the strategy and the delivery team — the linkage layer that translates intent into weekly operating decisions.
Read briefing
Discussion
(…)Comments are moderated before appearing. Your email is only used for moderation and is never shown publicly.
Loading discussion…