Keeping roadmaps alive

A roadmap records a strategic view under particular conditions: customer needs, policy assumptions, technology performance, budgets, dependencies and organisational priorities. Those conditions change at different speeds. A milestone may remain on schedule while the reason for pursuing it has disappeared. That is why visual freshness is not the same as strategic validity. [1]

The maintenance problem is not solved by scheduling an annual workshop. Some change is continuous, some event-driven and some slow enough for periodic review. A credible approach combines cadence with triggers and distinguishes minor content updates from changes that alter the strategic narrative. [2][1]

A useful review begins with evidence, not with dragging boxes to new dates. Ask what has changed, how reliable the signal is, which assumptions or dependencies it affects, and which decisions follow. Then update the roadmap and record the reasoning. Communication closes the loop by telling owners and affected stakeholders what changed - and what did not. [1][3]

Adaptive roadmapping research shows that the distribution and quality of evidence on the canvas can reveal where additional work or triangulation is needed. Review should therefore improve confidence and coverage, not merely preserve the existing plan. [3]

Name a roadmap steward who owns the process and content owners who own specific domains. Define who can propose, approve and communicate material changes. Connect the review rhythm to portfolio, budget, product or policy cycles so roadmap choices reach real decisions. Record rationale, author and date for important changes, including decisions to defer or stop work. [2]

The people required also change over the lifecycle. Initiation needs sponsorship and process design; development needs domain expertise and facilitation; integration needs portfolio, finance and operational owners. Treating the original workshop group as the permanent governance body can leave important decision rights outside the room. [2]

Long-running implementations show the importance of adapting the method to the organisation. The LEGO Group case describes using a reference process as a baseline, then customising and deploying it through a “start small, iterate fast” philosophy. The Subsea 7 case examines how roadmapping became part of innovation practice over several years and reports lessons about sustaining it through organisational and environmental change. [4][5]

Phaal, Chaskel and colleagues go further by treating the roadmapping system itself as something that can be roadmapped: clarify why the organisation needs it, define the desired future state, assess the current system and agree how capabilities, process, data and governance must evolve. Their R2 method was developed and refined through six industrial cases. [7]

Lee, Phaal and Lee surveyed 186 R&D units in large, technology-intensive Korean firms already using technology roadmapping. In that sample, appropriate software was the strongest measured antecedent of roadmap utilisation, ahead of an effective process, organisational support and alignment with company objectives. [6]

The finding does not support a software-only interpretation. The software construct included availability, needed information and knowledge, usability for novice and advanced users, and integrity. The authors also stress participation, process, sponsorship and strategic relevance. The sample excluded organisations that had discontinued roadmapping and cannot establish that buying software causes success in every setting. [6]

Before reviewing dates and status, revisit the logic. Which external signals changed? Which assumptions are now stronger or weaker? Which dependencies moved? Where does demand exceed capacity? Which item has lost its strategic reason? What did the organisation learn, and who needs that knowledge? A living roadmap is not one that changes constantly; it is one whose continued validity can be explained. [8]