An IT roadmap that sits in the IT department is a planning document. An IT roadmap that gets reviewed, funded, and referenced by the board is an instrument of organizational change. The difference between the two is not the quality of the technical thinking — it is the quality of the business translation. Every IT roadmap that fails to get board approval fails because it was written for a technical audience and presented to a business one.
Start With Business Problems, Not Technology Solutions
The first version of an IT roadmap should contain no technology at all. It should contain a clear description of the business problems the organization is facing, the strategic goals it is trying to achieve, and the ways in which current technology capability is enabling or constraining both. This is the conversation the board wants to have. They are not interested in which version of the ERP you are planning to upgrade to. They are interested in whether the business can scale, whether operations are exposed to risk, and whether the organization is competitive in its use of technology.
Only after this business problem framing should the roadmap introduce the technology initiatives — and each initiative should be introduced as a response to a specific business problem or opportunity, not as a technology project in its own right.
Structure Around Three Horizons
A three-year IT roadmap organized by calendar year is too granular for the first year and too uncertain for the third. I structure roadmaps around three horizons instead. Horizon One covers the next twelve months — specific projects, defined budgets, named owners, and committed timelines. Horizon Two covers months thirteen through twenty-four — planned initiatives with estimated budgets and preliminary scopes. Horizon Three covers the third year — directional investments with strategic rationale but without detailed plans, because no one can plan at that resolution three years out without wasting the effort.
Quantify the Cost of Not Acting
The roadmap items that get funded are the ones with a compelling answer to the question: what happens if we do not do this? Risk exposure, competitive disadvantage, regulatory non-compliance, and operational inefficiency all have measurable costs. Quantifying those costs — even with acknowledged uncertainty in the estimates — gives the board a basis for investment decisions that “modernizing our infrastructure” does not provide. When you can say that the current state of the finance system requires twelve days per month of manual reconciliation at a cost of three hundred thousand pounds per year in labor, the conversation about an upgrade budget becomes concrete.
Present the Tradeoffs, Not Just the Plan
Boards distrust roadmaps that present only one option. Showing two or three investment scenarios — a minimum viable program, a recommended program, and an accelerated program — with the business implications of each gives the board a real decision to make rather than an approval to grant. This approach also demonstrates that the IT function has thought carefully about priorities and constraints, which builds credibility that a single-option roadmap cannot.