A technology roadmap that survives a budget round
Most roadmaps are a wish list with dates attached. The ones that get funded explain what each item prevents or enables, and what happens if it slips a year.
A roadmap gets built, presented, agreed, and then the budget round arrives and it is cut to the two cheapest items. Everyone concludes the business does not take technology seriously.
Usually the roadmap was the problem. It described technology in terms of technology, and asked people who allocate capital to take the importance on trust.
Why they get cut
Everything is a priority, so nothing is. Twenty items, all necessary. The person holding the budget has no basis to choose, so they choose on price.
The consequence of not doing it is unstated. “Upgrade the core switches” invites the question of what happens if we do not, and if the answer is not written down somebody will assume it is nothing.
It reads as maintenance, and maintenance loses to growth. Every organisation funds the new thing over the boring thing when they are presented as alternatives. Framing matters because the boring thing is often what makes the new thing possible.
There is no sequence, only a list. If item four depends on item two, and that is not visible, item four gets funded and fails.
What a fundable roadmap looks like
Three horizons, not a flat list. What must happen this year, what is next, and what is being deliberately deferred. That last column is the one that makes the document honest, and it prevents the deferred item resurfacing as a surprise.
Each item with a consequence, in business terms. Not “implement conditional access” but “prevents an account takeover from a stolen password, which is currently the most likely way we lose money”. Not “replace the switches” but “the current pair are out of support, and a failure during season is a full-day stop we cannot repair from stock”.
Each item with a dependency and a sequence. Identity before the tool that relies on it. Documentation before the migration. This is what stops the roadmap being reordered into something that cannot work.
Cost with a shape. Capital against operating, one-off against ongoing, and where a cost is avoided rather than incurred. Insurance premium movement and reduced downtime are legitimate returns and should be stated as such.
What we are choosing not to do. Written down, agreed, and revisited. An accepted risk is governance. An unmentioned one is a problem waiting for an incident to reveal it.
The test
Hand the roadmap to somebody who does not work in technology and ask them to explain why item three matters and what happens if it waits.
If they can, it is a roadmap. If they cannot, it is a list of tasks and it will be cut on price, and that will not be because the business does not care.
Where independence matters
A roadmap written by the party who would deliver all of it is worth reading sceptically, and we say that as a party who would like to deliver some of it.
Our advisory work is priced separately from delivery for exactly this reason, and where a recommendation touches something we sell we declare it and you decide who implements. A roadmap should also contain items that cost nothing but a decision, and items you could give to somebody else. If it does not, it is a sales document with dates on it.
The point of the exercise is that the business can defend its technology spending without needing us in the room. If it cannot, the roadmap has not done its job.