Most IT roadmaps end up in a drawer. Rarely because they are wrong: because there is no way to decide on them.
The classic failing: the inventory
The document lists what exists, sets out findings, lines up recommendations. All of it is accurate. But nothing is costed, nothing is ranked, and the business owner is left with twenty projects and no idea which to start with or what each one commits them to.
A document that does not enable a decision produces the same result as no document at all.
Three scenarios, not one
- Basic — what addresses the immediate risk: whatever, if it fails, stops the business.
- Intermediate — what brings the system up to the business as it is today, not as it was five years ago.
- Premium — what prepares for the growth being promised: volume, new sites, new lines of business.
Presenting three costed scenarios moves the conversation. You are no longer asking “should we do something”, a question to which a prudent owner always answers “later”. You are asking how far to go, and for how much.
A business owner does not decide between recommendations. They decide between amounts and their consequences.
Prioritising without arbitrariness
The order of the projects cannot rest on the instinct of whoever wrote the document. A scoring grid across three criteria makes it arguable — and so defensible:
- criticality: what happens if this fails
- functional coverage: how far it meets the actual need
- status: obsolescence, support, dependency on a person or a supplier
The point of the grid is not to produce an automatic ranking. It is to force every difference to be justified, and to let the owner challenge a score rather than swallow a conclusion.
The document is written for the board
If the roadmap can only be read by an IT person, no one will decide on it — it will be delegated to the very person whose remit it assesses. The document has to be intelligible to whoever signs off the budget, which means translating every project into a business consequence rather than a technical specification.