IT roadmaps become wish lists because they list initiatives without capacity. Showing what the team can actually deliver alongside what has been requested is what turns the roadmap into a prioritisation conversation.
Lead with the business outcome. 'Migrate to cloud' is an activity. 'Reduce recovery time for finance systems from two days to four hours' is an outcome someone will fund. Write the outcome first and the initiative second.
Model capacity honestly. Subtract run-the-business work before counting available project capacity. Most IT teams have far less discretionary capacity than the roadmap assumes, which is why roadmaps slip.
Publish what you are not doing. A list of deferred items with reasons prevents the same requests arriving repeatedly and makes the trade-offs visible. It is often the most useful page in the document.
Here's a preview. Unlock the free download to get all 4 sections (3 more below).
| Initiative | Business outcome | Horizon | Effort (person-days) | Depends on | Owner | Status | Confidence |
|---|---|---|---|---|---|---|---|
| Identity provider migration | Single sign-on for all staff; faster onboarding and offboarding | H1 2027 | 45 | - | Infrastructure | Committed | High |
| Cloud migration wave 2 | Reduce finance system recovery time from 2 days to 4 hours | H1 2027 | 90 | Identity migration | Platform | Committed | Medium |
More free templates IT teams use alongside this one.
An IT budget presented as a list of line items invites line-by-line cuts. Split into run, grow, and transform, it becomes a conversation about what the business is choosing to fund, which is a far better conversation to be in.
Projects fail on scope, and scope fails on what was never written down. The most valuable section of a charter is the out-of-scope list, because that is what gets argued about in month three.
IT dashboards drift toward metrics that are easy to collect rather than ones that change decisions. The test for every metric here is simple: if it moved, would anyone do anything differently?
Initiatives expressed as business outcomes, the horizon each sits in, effort estimates, dependencies between initiatives, owners, confidence levels, a capacity model showing what is actually deliverable, and an explicit list of what is not being done.
Most commonly because run-the-business work was not subtracted before counting project capacity. Incidents, requests, and maintenance consume the majority of most IT teams' time, leaving far less discretionary capacity than roadmaps assume.
Twelve to eighteen months with decreasing confidence, plus a directional view beyond that. Committing to specific dates more than a year out tends to produce either padding or missed commitments, and both damage credibility.
