How much can your team actually deliver next year?
Most roadmaps state what will be delivered. Very few state what could be. The gap between those is where next year's overruns come from.
Updated September 2026
- Capacity is what is left after run, support, leave and the work already committed. It is always smaller than headcount.
- The business side has a capacity limit too, and it is usually the binding one.
- A plan that exceeds capacity does not fail visibly. Everything just takes longer than it said.
- Having the number changes the conversation from 'why is this late' to 'which of these three'.
A roadmap without a capacity number is a list of intentions. It will be approved, because nothing in it looks unreasonable, and it will then be delivered late in a way nobody can attribute to a single cause.
Start from headcount and subtract
The available number is what remains after everything that is not project work:
- Run and support. Incidents, requests, patching, the things that happen whether or not anything new is built. In most organizations this is the majority of the technology team’s time.
- Leave, training and statutory time. Predictable, and routinely left out of plans.
- Work already committed. Projects in flight that cross into next year.
- Unplanned demand. There will be some. Reserving nothing for it guarantees that it comes out of the plan.
What is left is the capacity. It is usually a fraction of the headcount, and the first time it is calculated people assume the arithmetic is wrong.
Then find the business-side limit
The constraint is often not IT. It is the business subject-matter experts who have to define requirements, test, and change how they work — and they have day jobs.
Three projects can run in parallel in IT and still fail, because they all need the same four people in finance. That limit belongs in the plan, and it is the one most often discovered in month five.
Account for change absorption
Beyond the people building it, there is a limit to how much change an organization can take. A business unit can absorb one significant system change at a time, not three. Exceeding that produces adoption failures rather than delivery failures, which are harder to see and slower to fix.
What to do with the number
Publish it alongside the roadmap. Two columns: what is being asked for, and what fits. The conversation that follows is the one worth having, and it is a very different conversation from the one that happens in June when a date moves.
Where the ask exceeds capacity — which it will — the choices are the ordinary ones: reduce the scope, extend the timeline, add people, or stop something else. All four are legitimate. What is not legitimate is approving the plan and hoping.
Why this is worth the effort
A capacity number turns delivery from a performance question into a planning one. When a leader can see that eleven things were asked for and six fit, the discussion becomes which six — a business decision, made by the business, in advance.
The practice behind it.
Building next year's roadmap?
We will put a capacity number against it, and tell you which items will not fit before you commit to them.