A transformation roadmap is not a list of projects with dates attached; it is a deliberately sequenced argument for how an organization moves from its current state to its target operating model (CN7.01's design) without breaking along the way. The most useful roadmaps are built on two axes at once, because collapsing either one into the other is how roadmaps quietly become wish lists. The first axis is time horizon, commonly three: Horizon 1 (roughly the first quarter or two, the initiatives you can start immediately with what you already have), Horizon 2 (the middle stretch, where the harder structural work lands once the groundwork from Horizon 1 is in place), and Horizon 3 (the final stretch, where capability and culture changes that take the longest to land finally show up in the numbers). The second axis is initiative lane, and, as the cross-link already flagged, this module generalizes exactly the three categories CN6.02 used for a 100-day PMI plan: quick wins (fast, low-risk, often symbolic moves that build momentum and buy the program credibility while harder work is planned), structural moves (the higher-risk, higher-value changes, a footprint redesign, a systems migration, a genuine process redesign, that take real time and real capital), and people & capability (skill-building, incentive redesign, and the communication rhythm that keeps belief in the program alive across many months). Plot every initiative at the intersection of a horizon and a lane, and the roadmap becomes a real artifact: not a date-ordered list, but a grid you can read for balance (a roadmap that is all Horizon-3 structural moves with no Horizon-1 quick wins is a roadmap that will lose the room's confidence before it delivers anything) and for value concentration (which cells carry how much of the total target).
Advertisement
How do you sequence a transformation roadmap?
Sequencing within that grid is decided by three distinct logics, and conflating them is the single most common roadmap error. Dependency-driven sequencing follows genuine prerequisites, you cannot migrate a new costing system before the chart of accounts it depends on is redesigned. Capacity-driven sequencing follows scarce resources, and this is the logic beginners miss entirely: two initiatives with no technical dependency between them can still be forced into sequence because they need the same specialist, the same capital committee slot, or the same plant downtime window, a constraint invisible on a Gantt chart that only draws arrows for logical prerequisites. Risk-driven sequencing deliberately front-loads the highest-uncertainty work, pilot the riskiest assumption first, while there is still time and goodwill to change course if it fails, rather than discovering in month fourteen of an eighteen-month program that the central assumption was wrong. A roadmap's critical path is the longest chain of dependent work, technical or capacity-driven, that determines the program's earliest possible finish date; anything off that chain has slack, and anything on it deserves disproportionate attention, because a delay anywhere on the critical path delays the whole program by the same amount, while a delay off it may cost nothing at all. Worked Example 1 builds exactly this: a critical path created entirely by a shared specialist, not by any technical prerequisite, and the cost of planning around it honestly versus discovering it mid-program.
How do you check that a roadmap adds up?
One discipline keeps the roadmap from becoming a slide of good intentions: every initiative on it must carry a stated value contribution, and those contributions must sum to the program's stated north-star target. A roadmap and a KPI cascade are, underneath, the same underlying model of the program viewed two different ways, the roadmap lays the same initiatives out in time; the cascade lays their value out by owner and metric. If the two do not reconcile to the same total, one of them is wrong, and finding out which is wrong before the SteerCo does is the whole point of building both.