Roadmaps fail when they start with technology
Technology choices matter, but they should follow the operating decisions: business outcome, use-case priority, data dependency, control requirements, ownership and change capacity.
Otherwise the roadmap becomes a procurement sequence rather than an adoption sequence.
Wave 1 — prove value where readiness is strongest
Select a small portfolio where business value is meaningful, foundations are sufficiently strong, ownership is clear and risk is manageable. Wave 1 should establish confidence and reusable practices, not merely generate pilots.
Wave 2 — unlock higher-value constrained use cases
Use Wave 1 to resolve dependencies, improve data, strengthen governance and build operating capability. Wave 2 can then address initiatives that were valuable but not initially ready.
Wave 3 — scale and transform
Later waves may include cross-functional, higher-autonomy or more structurally disruptive use cases. These should benefit from the governance, architecture and learning created earlier.
Include foundation work in the roadmap
Data remediation, operating-role design, security controls, model-monitoring standards, process redesign and user capability are roadmap items. Treating them as background work makes sequencing unrealistic.
Create a Do-Not-Start list
Executives need explicit restraint. Document use cases that should not begin because value is weak, dependencies are unresolved, risk is disproportionate or ownership is unclear.
A Do-Not-Start list protects capital and leadership attention.
Govern the roadmap independently
Reassess readiness and value as evidence changes. The organisation should be able to stop, defer or reorder initiatives without being trapped by implementation commitments.