Most documents called an IT roadmap are a list of purchases with years next to them. They get written once, presented once, and quietly ignored, because they answer the question of what somebody wants rather than what the organization should do next.
A roadmap earns its name when it can survive being questioned by a CFO.
What has to be in it
What you currently have, honestly
Systems, versions, support status, ownership and annual cost. Including the things nobody wants to write down: the server everyone is afraid to restart, the application one person understands, the contract that renews automatically. A roadmap built on an optimistic inventory is fiction.
Sequence, not just contents
Order matters more than the list. Some things cannot happen until others do. Automating a process before fixing it scales the mess. Building analytics on data nobody trusts produces confident wrong answers. The roadmap should make dependencies explicit.
Effort and impact per item
Rough is fine. Absent is not. Without both, every item looks equally urgent and prioritisation becomes politics.
The cost of not doing it
This is the one usually missing, and it is what turns a wish list into a decision document. What happens if this waits a year? Sometimes nothing, and that item should move down. Sometimes support ends, or an auditor asks a question you cannot answer, and that changes the conversation entirely.
Who owns each item
A named person, not a department. Items owned by everyone are owned by nobody.
The test: hand it to your CFO. If they can tell what to fund first and why, it is a roadmap. If they ask what any of it means, it is a wish list.
What does not belong
Technology nobody has connected to an outcome
If an item cannot be traced to a business result, a risk being reduced or a cost being removed, it is on the roadmap because someone read an article.
Five-year specifics
Year one should be specific. Year two directional. Beyond that, themes only. Anyone presenting a precisely costed year-four plan is describing a forecast they cannot have.
Vendor names, mostly
The roadmap should say what capability is needed and when. Which product delivers it is a later decision, made closer to the time, with current information. Roadmaps that name products tend to have been written by whoever sells them.
How often it should change
Reviewed quarterly, revised when the business changes. A roadmap that has not moved in a year is not stable, it is abandoned. A roadmap rewritten monthly is not a plan, it is a reaction.
The point is not to predict correctly. It is to make the next decision an informed one, and to make the reasoning visible to everyone who has to live with it.
Need a roadmap your board will actually accept?