How to write a technology roadmap you can hand to any supplier

What is a technology roadmap, and what is it for?

A technology roadmap is a written, ranked and costed plan for what happens to your systems over the next twelve months. Its purpose is to convert a series of individually reasonable decisions into one chosen direction.

Twelve months is deliberate. Shorter, and it is a to-do list. Longer, and it is fiction — the systems, the prices and the business will all have moved.

The test of a roadmap is not whether it is comprehensive. It is whether, when something urgent lands in month four, you can look at the document and say confidently that the urgent thing is less important than what you already planned. Most technology overspend comes from lacking that.

What actually goes in it?

Four sections, and the fourth is the one people skip.

What to fix. The things costing money or time now, ranked, so the argument about sequence is had once instead of every month.

What to replace. Systems at the end of their useful life, with an honest view of when replacement becomes urgent rather than merely overdue. Being specific about the trigger matters more than being specific about the date.

What to leave alone. Working systems that are unfashionable are still working systems. Writing them down protects them from the next person who wants to modernise something.

What each costs. Enough for a finance director to plan against. A roadmap without numbers is a wish list, and it will lose every argument it has with a budget.

Why does 'what to leave alone' matter so much?

Because without it, every roadmap becomes a replacement programme. There is always something that could be newer, and technology people are professionally inclined to notice it.

Writing down that a system is adequate, and why, is a decision with real value: it takes an item off the table for twelve months and stops it being relitigated whenever someone new arrives with opinions.

It is also the section that tells a reader whether the roadmap is honest. A plan that recommends changing everything was probably written by someone who benefits from changing everything.

How do you cost it without a procurement exercise?

Cost the things that are knowable, and be explicit about the confidence on the rest. Licence costs and subscription changes are knowable. Migration effort is estimable within a range. Anything requiring a supplier to quote should be marked as such rather than guessed and presented as fact.

Include the cost of doing nothing where it is real: an unsupported system carries a risk cost even if it carries no invoice, and that is often the strongest argument in the document.

A range with a stated basis is more useful to a finance director than a single number with none.

How do you write one that does not lock you in?

Write it so a supplier who did not produce it can act on it. That means naming the outcome rather than the product wherever possible, and being explicit about which recommendations are genuinely constrained and which are preferences.

A roadmap that only its author can interpret is a commercial instrument, not a plan. If your consultancy's roadmap cannot be handed to a competitor, ask why.

Keep the underlying facts — the system inventory, the contract dates, the spend — in a form you own and can share. Those outlive any particular plan.

How often should it be reviewed?

Quarterly, and briefly. The review asks three questions: what actually happened, what changed in the business, and does the ranking still hold.

Most quarters the answer is that the order is broadly right and one item has moved. That is a short meeting and a worthwhile one.

A roadmap written once and filed is indistinguishable from not having one, which is the most common way this exercise fails.