Most roadmaps are a list of things somebody wants. A useful one starts from what is happening anyway, adds what you chose, and stops at five streams.
A technology roadmap is supposed to answer one question for the people who fund it: what are we going to do, in what order, and why that order.
Most of them do not, because they are built the wrong way round. Somebody collects ideas, groups them into themes, spreads them across four quarters, and presents a document that is really a wish list with a timeline drawn on it. It does not survive its first contact with a budget conversation, because nothing on it is forced.
Start with what is happening anyway
The foundation of a credible roadmap is the set of things that will happen whether or not anyone decides anything.
Four sources, all of which produce dates rather than opinions:
Contracts expiring, with their notice periods. A renewal is a decision point whether you treat it as one or not.
Hardware reaching the end of its cycle. From your asset data. If a third of the fleet is due, that is a stream.
Software leaving vendor support. These dates are published years ahead and are the most forecastable items in technology.
Compliance deadlines. A client questionnaire due at renewal, an audit date, a regulatory change with a commencement date.
Put those on the page first. For most organisations they account for half to two thirds of the capacity available in a year, which is itself a useful finding, because it reframes the conversation from "what shall we do" to "what else can we fit".
Then add what you chose
Only from two places, and both should predate the roadmap.
The risk register. Items the business agreed to reduce. These arrive with their justification already made, which is why the register is worth maintaining even when it feels like paperwork.
One thing people keep asking for. Every organisation has an operational irritation that generates complaints and never gets prioritised because it is not urgent. Fixing one per year buys more goodwill than anything else on the page, and goodwill is what gets the rest of it approved.
Five streams, maximum
The limit is not arbitrary. A mid-sized organisation can run perhaps two significant changes concurrently without degrading support, because the same people do both. A roadmap with nine streams is a roadmap where several things will silently not happen, and nobody will say which.
Choosing five means saying no to things. Write the no down: a short "considered and deferred" list with the reason. It is the most credible page in the document, because it demonstrates that what remains has been filtered.
What each stream needs
Four fields. Any more and the page stops being a page.
A name that states the outcome, not the technology. "Recovery: measure and fix Tier 1" rather than "Implement Veeam".
A quarter. Not a date. Dates on a twelve-month plan are false precision and they make the document look wrong by February.
An owner, who is a person in your organisation, not a supplier.
The reason, in one clause: the contract, the risk, the deadline. This is the field that survives the budget meeting.
Horizons, briefly
A single twelve-month page is right for most organisations this size. If you need to show further out, use three bands rather than three detailed years:
This year, with the five streams and owners.
Next year, as three or four named intentions with no detail, because detail at that distance is invented.
Beyond, as a short paragraph of direction. Anything more specific will be wrong.
The common error is presenting year three with the same granularity as year one, which makes the whole document less believable rather than more thorough.
Reviewing it without rewriting it
Quarterly, as part of the review that should already be happening. Twenty minutes: what completed, what slipped and why, what changed in the business, does the next quarter still look right.
Change the roadmap when something real changes. An acquisition, a significant incident, a client requirement, a vendor announcement. Do not change it because a new product looks interesting, and do not quietly add streams without removing any, which is how a five-stream plan becomes a nine-stream plan by August.
Presenting it
The one page, and underneath it two things the audience will ask for: the cost per stream, and the consequence of deferring each one by a year.
The second is the one that gets decisions made. "Device refresh deferred" means nothing to a board. "Device refresh deferred means a third of the fleet is out of warranty, support costs rise, and we replace two thirds of the estate in one year instead of a third each year" is a decision.
If you have never written one
Take an afternoon. List the contracts with renewal dates. List the hardware and software with end dates. Take the top three items from your risk register, or write a register if you do not have one. Pick the one thing staff complain about most.
That is already a roadmap, built from facts, and it is better than most twenty-page strategies because every line on it can be traced to something that is true.
