Quick Navigation
- Start here — What a roadmap is
- Defining transition states
- Sequencing principles
- Dependency mapping
- Capacity and risk
- Communicating the roadmap
- Maintaining the roadmap
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
A transformation roadmap isn't a Gantt chart. It's not a list of projects with dates. It's a sequenced set of decisions and transitions that move the organisation from its current architecture to its target architecture — accounting for the fact that the organisation must continue operating while it transforms. I've seen roadmaps that were beautiful diagrams with no path to get there. And I've seen roadmaps that were thirty projects with target dates and no dependencies mapped. Neither survived contact with reality.
Transition states are as important as the target state. Organisations live in transitions — not in the target state. The roadmap is the plan for how to get there without breaking what's running today.
Roadmaps must be maintained — stale roadmaps are worse than no roadmap. Realistic sequencing requires honest assessment of capacity and risk. Dependencies must be mapped before sequencing can be trusted.
Keep it in mind.
1. What a transformation roadmap is — And what it is not
Most "roadmaps" are lists of projects with dates — or aspirational diagrams that show a beautiful target state with no plan for how to get there. Neither is useful.
A real roadmap answers three questions:
Where are we now? Current state — honestly. Where are we going? Target state — driven by strategy. How do we get there? Transition states — sequenced.
flowchart TD
ROADMAP["🗺️ Transformation Roadmap"] --> WHERE["📍 Where are we now?\nCurrent state — honestly"]
ROADMAP --> GOAL["🎯 Where are we going?\nTarget state — driven by strategy"]
ROADMAP --> HOW["🔗 How do we get there?\nTransition states — sequenced"]
WHERE --> TRANS_1["Transition State 1\nCoherent, operable"]
TRANS_1 --> TRANS_2["Transition State 2\nCoherent, operable"]
TRANS_2 --> TARGET["Target State\nGoal architecture"]
A roadmap is: sequenced decisions and transitions. Each transition state is coherent and operable. Dependencies are mapped and respected. Capacity and risk are honestly assessed.
A roadmap is not: a list of projects with dates. An aspirational target state with no path. A Gantt chart that pretends to predict the future. A document that is written once and never updated.
Roadmap = sequenced transitions — each one coherent, each one operable, each one enabling the next.
Try it yourself — The roadmap audit
Look at your current roadmap. What is it?
| What it is | What it should be |
|---|---|
| e.g. List of 30 projects with dates | Sequenced transitions with dependencies mapped |
If your roadmap doesn't have transition states, it's not a roadmap. It's a wish list.
2. Defining transition states — The intermediate architectures between now and the goal
Most transformations try to go directly from current state to target state. But the gap is usually too large to cross in one step. Transition states are the intermediate architectures — each one coherent, each one operable, each one closer to the goal.
Transition states are designed, not discovered.
flowchart LR
CURRENT["📍 Current State\nWhat exists today"] --> TS1["🔄 Transition 1\nFoundation built"]
TS1 --> TS2["🔄 Transition 2\nIntegration modernised"]
TS2 --> TS3["🔄 Transition 3\nDomains autonomous"]
TS3 --> TARGET["🎯 Target State\nGoal architecture"]
Designing a transition state means answering four questions:
Coherent — is this a valid, operable architecture — not a broken half-state? Valuable — does this deliver value — not just prepare for the next step? Stable — can the organisation operate on this state for an extended period? Enabling — does this enable the next transition — or does it create blockers?
The Strangler Fig pattern is a classic transition strategy. Build new capability alongside old. Redirect traffic to new capability. Remove old capability. Repeat.
Each transition state must be coherent and operable — the organisation lives here while it transforms.
Try it yourself — The transition canvas
Take your transformation. Design the first transition state:
| Question | Your answer |
|---|---|
| What changes in this transition? | |
| What business value does this deliver? | |
| Can the organisation operate on this state? | |
| What does this enable for the next transition? |
If you can't answer the second question, this isn't a transition state. It's a preparation step.
3. Sequencing principles — What drives order, and what makes sequencing defensible
Sequencing decisions are often political — whoever argues loudest goes first. But sequencing has objective rules: dependencies, foundations, risk, and capacity determine the right order.
Five principles drive defensible sequencing:
flowchart TD
SEQ["🔗 Sequencing Principles"] --> DEP_P["Dependencies first\nWhat must exist before what"]
SEQ --> FOUND["Foundations before features\nShared capabilities before specific"]
SEQ --> RISK_P["Risk first\nFail fast on high-risk items"]
SEQ --> QUICK["Quick wins early\nBuild credibility"]
SEQ --> CAP["Capacity-aware\nRespect what teams can deliver"]
DEP_P --> ORDER["📋 Defensible Order"]
FOUND --> ORDER
RISK_P --> ORDER
QUICK --> ORDER
CAP --> ORDER
Dependencies first — what must exist before what. Platform before services. Foundations before features — shared capabilities before specific capabilities. API gateway before API consumers. Risk first — high-risk items early — fail fast. Pilot the hard technology first. Quick wins early — build credibility with early value. Unblock a stuck team first. Capacity-aware — respect what teams can actually deliver. Don't plan 12 months of work for a 4-person team.
The sequencing algorithm: map dependencies — what depends on what? Assign to layers — foundation → platform → service → feature. Sort by risk — high risk first within layer. Check capacity — can teams deliver this? That's your sequenced roadmap.
Sequence by dependency, foundation, risk, and capacity — not by politics or preference.
Try it yourself — The sequencing test
Take three initiatives. What order should they be in?
| Initiative | Dependencies | Risk | Capacity needed | Sequenced order |
|---|---|---|---|---|
If your order doesn't put dependencies first, it's not defensible. It's political.
4. Dependency mapping — The prerequisite to any credible roadmap
Roadmaps without dependency mapping are fiction. If initiative B depends on initiative A, but B is scheduled before A, the roadmap will fail — and the failure will be discovered only when B cannot proceed.
Dependency mapping reveals what must happen before what.
flowchart TD
A["A: Platform\nFoundation"] --> B["B: API Gateway\nIntegration"]
A --> C["C: Event Broker\nIntegration"]
B --> D["D: Service 1\nBusiness"]
C --> E["E: Service 2\nBusiness"]
D --> F["F: Feature 1\nCustomer"]
E --> F
Dependency types: Technical — B cannot work without A. Service cannot deploy without platform. Data — B needs data that A produces. Analytics needs events from services. Skill — B needs skills that A develops. Teams need platform training first. Organisational — B needs decisions that A makes. Standards must be defined before services follow them.
The dependency register tracks each initiative, what it depends on, the dependency type, whether it's blocking, and the risk if delayed.
Critical path analysis finds the longest chain of dependencies. Any delay on this path delays the entire roadmap.
Map dependencies before sequencing — without dependency mapping, the roadmap is fiction.
Try it yourself — The dependency register
List your initiatives and their dependencies:
| Initiative | Depends on | Type | Blocking? | Risk if delayed |
|---|---|---|---|---|
| e.g. API Gateway | Platform infrastructure | Technical | Yes — blocks 5 services | High |
If you have more than two "blocking" dependencies, your roadmap has a critical path. Protect it.
5. Capacity and risk — Why most roadmaps are optimistic and how to build in reality
Most roadmaps are optimistic — they assume teams can deliver more than they actually can, that nothing goes wrong, and that all assumptions hold. Reality is messier. Realistic roadmaps build in capacity constraints and risk buffers.
Capacity and risk must be honest inputs to the roadmap.
flowchart TD
PLAN["📋 Planned Roadmap"] --> CAPACITY{"Enough\ncapacity?"}
CAPACITY -->|"No"| TRIM["✂️ Trim\nRemove or defer\nwhat cannot be delivered"]
CAPACITY -->|"Yes"| RISK_CHECK{"Risk\nassessed?"}
RISK_CHECK -->|"No"| BUFFER["🛡️ Add Buffers\nFor high-risk items"]
RISK_CHECK -->|"Yes"| REALISTIC["✅ Realistic Roadmap\nHonest about capacity\nHonest about risk"]
TRIM --> REALISTIC
BUFFER --> REALISTIC
The capacity check: Team availability — how many engineers are available? Account for holidays, attrition, BAU. Parallel work — how many initiatives can run simultaneously? Cognitive load — can teams absorb more change? Dependencies — are teams blocked waiting for others?
The risk buffer: Low risk — well-understood, done before. 10% buffer. Medium risk — some uncertainty. 25% buffer. High risk — new technology, complex integration. 50% buffer.
Available capacity = (Team size × availability %) - BAU load - support load. If each initiative needs 2 FTE for one quarter and you have 5 FTE available, you can deliver 2-3 initiatives per quarter. Don't plan 6.
Most roadmaps are optimistic — build in capacity constraints and risk buffers or accept failure.
Try it yourself — The capacity check
What's your real delivery capacity?
| Factor | Your number |
|---|---|
| Team size × availability % | |
| BAU load | |
| Support load | |
| Available for transformation | |
| Maximum parallel initiatives |
If your roadmap has more initiatives than your capacity, it's not a roadmap. It's a fantasy.
6. Communicating the roadmap — To leadership, to teams, and to external stakeholders
A roadmap that nobody sees doesn't influence decisions. Different audiences need different versions — leadership needs the strategic view, teams need the delivery view, external stakeholders need the capability view.
The roadmap is communicated in three versions:
flowchart TD
ROAD["🗺️ Roadmap"] --> LEAD["👔 Leadership\nStrategic view\nOutcomes and investment\nQuarterly milestones"]
ROAD --> TEAMS["👩💻 Teams\nDelivery view\nWhat we are building\nWhen and what depends on what"]
ROAD --> EXTERNAL_R["🌐 External\nCapability view\nWhat capabilities are coming\nWhen will they be available"]
The communication formats:
| Audience | Format | Content | Frequency |
|---|---|---|---|
| Board / CEO | 1-page visual | Outcomes, investment, milestones | Quarterly |
| CTO / CPO | 1-page detail | Initiatives, dependencies, risks | Monthly |
| Engineering teams | Wiki / tool | What, when, dependencies, owners | Continuous |
| External stakeholders | Capability timeline | What capabilities when | Quarterly |
Communicate the roadmap in three versions — strategic for leadership, delivery for teams, capability for external.
Try it yourself — The audience test
Who has seen your roadmap in the last quarter?
| Audience | Have they seen it? | In what format? |
|---|---|---|
| Board / CEO | ||
| Engineering teams | ||
| External stakeholders |
If any audience hasn't seen it, your roadmap isn't influencing decisions. Fix the communication first.
7. Maintaining the roadmap — Keeping it current as assumptions change
Roadmaps are written once and then become stale — because the world changes, assumptions fail, and new information emerges. A stale roadmap is worse than no roadmap because it creates false confidence.
Roadmap maintenance is a continuous discipline.
flowchart TD
ROADMAP_M["🗺️ Roadmap"] --> REVIEW_M["📊 Quarterly Review\nWhat changed?\nWhat is on track?\nWhat needs adjusting?"]
REVIEW_M --> UPDATE["🔄 Update\nAdjust sequence\nReassess capacity\nUpdate risks"]
UPDATE --> COMMUNICATE_M["📢 Communicate\nShare changes\nwith all audiences"]
COMMUNICATE_M --> ROADMAP_M
The maintenance cadence: Monthly — initiative progress: are we on track? Quarterly — full roadmap review: sequence, capacity, risks, assumptions. Event-triggered — major changes: new strategy, key departure, vendor change, regulatory shift.
What triggers a roadmap update: Initiative delay — downstream dependencies: what is blocked? Strategy change — target state: is the destination still right? Team change — capacity: can we still deliver what we planned? Technology change — technology choices: are they still valid? Risk materialisation — buffers: do we have enough?
Every quarter, ask: what did we plan vs what actually happened? Where were we optimistic? Where were we pessimistic? What dependencies did we miss? What risks materialised? What should we do differently next quarter?
Roadmaps are living documents — review quarterly, update continuously, communicate changes.
Try it yourself — The health check
How healthy is your roadmap right now?
| Dimension | Your status |
|---|---|
| Currency — updated within last quarter? | |
| Accuracy — initiatives on track? | |
| Confidence — teams believe the roadmap? | |
| Visibility — all audiences informed? |
Any unhealthy dimension means your roadmap needs attention. Start with the worst one.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
CURRENT_R["📍 Current State"] --> TARGET_R["🎯 Target State\nDriven by strategy"]
TARGET_R --> TRANS["🔄 Design Transition States\nEach coherent and operable"]
TRANS --> SEQUENCE_R["🔗 Sequence\nDependencies · Foundations\nRisk · Capacity"]
SEQUENCE_R --> COMM_R["📣 Communicate\nLeadership · Teams\nExternal"]
COMM_R --> MAINTAIN["🔄 Maintain\nReview quarterly\nUpdate continuously"]
MAINTAIN -->|"Feedback"| TRANS
The foundation:
Roadmaps are sequenced transitions, not project lists. Each transition state must be coherent and operable — the organisation lives there while it transforms. Dependencies must be mapped before sequencing can be trusted. Without dependency mapping, the roadmap is fiction. Dependencies determine what comes first. Most roadmaps are optimistic — build in capacity constraints and risk buffers. Honest roadmaps are more credible than ambitious ones that fail. Sequence by dependency. Design transition states. Keep the organisation running. Maintain the roadmap quarterly.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Transformation roadmap | Sequenced transitions, not project lists | Design each transition state |
| Transition states | Coherent, operable, enabling | The organisation lives here |
| Sequencing | Dependency, foundation, risk, capacity | Five principles, not politics |
| Dependency mapping | Prerequisite to credible roadmaps | Map before sequencing |
| Capacity and risk | Most roadmaps are optimistic | Build in buffers |
| Communication | Three versions | Leadership: strategic. Teams: delivery. External: capability |
| Maintenance | Living documents | Review quarterly, update continuously |
How to know if this landed
You'll know this has landed when someone stops treating roadmaps as Gantt charts and starts treating them as sequenced transitions. Has a defined target state driven by business strategy. Transition states are designed — each coherent and operable. Dependencies are mapped before sequencing. Sequencing follows dependency, foundation, risk, and capacity principles. Risk buffers are built into the plan — realistic, not optimistic. Roadmap is communicated to leadership, teams, and external stakeholders. And roadmap is reviewed quarterly and updated when assumptions change.
What changes when the mental model clicks
I've run this session with teams where the "roadmap" was a list of 30 projects with target dates — no dependencies, no transition states, no capacity check. The gap at the start is usually not about understanding roadmaps — it's about connecting current state honestly to target state through designed transitions.
What changes after this session:
Teams stop treating roadmaps as project lists and start treating them as sequenced transitions. The dependency mapping exercise — "what must happen before what?" — is always the moment things click. People stop treating roadmaps as set-in-stone and start treating them as living documents. Their results get better. They stop planning 30 initiatives for teams that can deliver 8 when the real problem was that nobody checked capacity.
The transition state design exercise tends to immediately change how teams think about their transformation. They start designing each transition as a coherent, operable architecture. Their credibility goes up. They stop presenting aspirational targets when the real problem was that they hadn't designed the path to get there.
Book a Workshop
Ready to build a transformation roadmap that is credible, sequenced, and maintained?
or
1.5-day workshop includes current state documentation — honest assessment of where you are, target state definition — driven by business strategy, not technology trends, transition state design — 2-4 intermediate architectures, each coherent and operable, dependency mapping — identify what must happen before what, sequencing exercise — apply the five principles to your real initiatives, capacity and risk assessment — honest inputs to a realistic roadmap, communication plan — create the right version for each audience, and roadmap template + transition state design guide + sequencing logic + dependency overlay.