Most businesses do not have an IT roadmap. The ones that do usually have a forty-page document nobody reads. Here is the one-page version we use with every CIO and CTO as a service client: what goes on it, a template you can copy, and how to keep it alive.
Ask most mid-sized businesses for their IT roadmap and you get one of three things: a blank look, a project plan for the current ERP project, or a document a consultancy wrote two years ago that has not been opened since. None of them is a roadmap. A roadmap is a single page that says where the business's technology is now, where it needs to be in three years, and what happens in between, in a form the board can read in five minutes and argue about in ten.
This is the one we use. It is deliberately a page. If it needs a second page, something on it is a project plan, not a roadmap, and belongs elsewhere.
Six blocks, top to bottom.
Where the business is going, in the business's own words: turnover, headcount, sites, markets, anything it is planning to buy or sell. The roadmap exists to serve this, so it goes first. If the board cannot agree these two lines, stop; that is the real problem.
The implications. "Multi-company consolidation without spreadsheets." "A warehouse that can ship 3,000 lines a day." "Customers can see their order status without phoning." "We pass a buyer's technology due diligence." These are the goals of the roadmap, and everything below has to trace to one of them.
The current estate, one line each: system, what it does, version, who supports it, contract end, and a traffic light. Red is "replacing", amber is "fixing or upgrading", green is "keeping". Most businesses have eight to fifteen lines. If you have forty, that is a finding.
Twelve quarters across, workstreams down: ERP, infrastructure and security, data and reporting, integrations, people and skills, and one for "the business" (go-lives, acquisitions, new sites, peak seasons) so that technology work is visibly planned around the business and not on top of it. Each item is a bar with a name and a rough cost. Year one is firm, year two is likely, year three is direction.
Run cost this year (licences, support, infrastructure), change cost this year (projects), and the same two for next year. Boards are entitled to the total, and the roadmap is where it is explained.
The things that would stop the roadmap: the key person, the unsupported system, the untested backup, the partner's capacity, the contract that is about to renew badly. Each with an owner and a date by which it is dealt with.
Copy this into a document, landscape, and fill it in. It is laid out as a table here because that is what fits a blog post; in practice it is a page with the timeline as a Gantt-style grid in the middle.
| IT roadmap: [Business name], [date], owner: [name] | |
|---|---|
| The business in three years | [Turnover, headcount, sites, markets, planned acquisitions or exit] |
| What has to be true | 1. [ ] 2. [ ] 3. [ ] 4. [ ] |
| Where we are now | [System] · [purpose] · [version] · [supported by] · [contract end] · [red / amber / green] [repeat per system] |
| Timeline (Q1 this year to Q4 in three years) | ERP: [e.g. Q2 health check → Q3–Q4 implement → Q1 go-live → twice-yearly release reviews] Infrastructure and security: [e.g. MFA everywhere Q1, backup restore test Q2, server retirement Q4] Data and reporting: [e.g. Power BI board pack Q3, data warehouse year 2] Integrations: [e.g. web shop Q4, EDI year 2] People and skills: [e.g. super users named Q2, system champion role Q1 year 2] The business: [peak season, new site, acquisition, audit] |
| Money | Run this year £[ ] · Change this year £[ ] · Run next year £[ ] · Change next year £[ ] |
| Five risks | 1. [risk] · [owner] · [by when] 2. … 5. |
A roadmap that is not updated is a historical document within six months. The rhythm that works:
Three things. It stops technology decisions being made by accident, because every proposal has to be placed on the page or argued off it. It gives the board a total and a direction without a forty-page read. And it is the first document a buyer, an investor or a bank will ask for when they do due diligence, and having it ready, current and honest is worth a great deal at that moment.
Building the first one takes about two days with the MD, the FD and whoever runs the systems. It is the first thing we do on every CIO and CTO as a service engagement, and if you would like help with yours, get in touch.
