We build roadmaps as ordered sets of independent modules, each with a stated outcome and a stated cost, so that delivery can change the order without breaking the plan and each investment can be judged on what it returned.
The plan that is right until the first month
A roadmap drawn as one long sequence encodes a great many assumptions about the future, and the first delivered piece tests some of them. When an assumption fails, a monolithic plan has no way to absorb the lesson except by being redrawn, and a plan that is constantly redrawn is not a plan.
Modules with outcomes
We decompose the transformation into modules that can be delivered and valued separately. Each names the capability it improves, in the same capability map the alignment work produced, the outcome by which it will be judged, and its dependencies on other modules. The roadmap is the dependency order of the modules, and it can be re-sequenced whenever delivery learns something, because the modules themselves do not change.
Investment that can be checked
Each module carries its expected return in terms that can be measured after delivery. We plan the sequence so that early modules fund the confidence for later ones, and we record the expectation so that the outcome can be compared with it honestly. A module that did not return what was expected is a finding about the plan, made visible rather than absorbed.
Change managed as part of the work
A transformation that changes systems without changing how people work has changed nothing. Each module therefore includes the organisational change it needs, planned and resourced with the technical delivery, so that your teams are ready for the capability on the day it arrives.
