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
Scenarios are worth something only if the survey underpinning them is accurate. That survey requires a map of dependencies, not a list of applications.
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.
Common questions
How do you build an IT master plan that is actually useful?
By making it lead to a decision, not an inventory. It starts from a map of dependencies, ranks the workstreams by criticality, functional coverage and status, then presents several costed scenarios the managing director can choose between.
Why present three scenarios in an IT master plan?
Because a single recommendation cannot be weighed: it is either accepted or refused. Three scenarios — basic, intermediate, premium — change the question put to the managing director: no longer “should we act?” but “how far do we go, and for how much?”.
Who is the IT master plan written for?
For the managing director who decides the budget. If only an IT specialist can read it, it gets delegated to the very person whose scope it assesses. Each workstream must therefore be expressed as a consequence for the business rather than as a technical specification.