A capacity vs demand gap analysis compares the total amount of work IT is being asked to do with the total amount of work IT can actually do. The gap between those two numbers drives real portfolio decisions: which projects get approved, which get deferred, and where hiring or contracting is justified.
Most organizations have a sense that they are overwhelmed, or that projects aren't moving fast enough. A gap analysis makes that concrete. It turns a feeling into a number you can act on.
Defining capacity
Capacity is the total available working time of the IT team, expressed in FTEs or hours, after accounting for non-project work.
To calculate capacity by skill area:
- Count the available team members in each skill area: developers, architects, QA engineers, project managers, and so on
- Multiply by working hours per period (a 13-week quarter at 40 hours per week yields 520 gross hours per person)
- Subtract time for non-project work: operational support, team meetings, training, and incidents typically consume 20 to 30% of available time
A development team of 12, planning for 25% overhead, has 12 x 520 x 0.75 = 4,680 net project hours per quarter, or 9.0 net development FTEs.
The overhead assumption matters. Organizations that plan at full capacity consistently miss delivery targets because the 20 to 30% they ignored had to go somewhere. It goes to the projects, quietly.
Defining demand
Demand is the total work required by the approved and proposed project portfolio, expressed in the same units as capacity.
To calculate demand by skill area:
- Estimate the hours or FTEs required by each active project in the current period, broken out by skill type
- Do the same for projects proposed for approval
- Sum across all projects by skill area
Demand should include both project work and the operational baseline. Many IT departments capture demand only at the project level and miss the 30 to 40% of IT capacity that goes to ongoing operations: production support, routine maintenance, and the perpetual stream of small enhancements that never get logged as projects. If that operational demand isn't in the model, the capacity picture will always look better than it is.
Calculating the gap
Gap = Demand − Capacity
A positive gap means demand exceeds capacity. A negative gap means there is spare capacity. In most IT organizations running active portfolios, the gap is positive.
The total gap number is less useful than the gap broken out by skill area:
| Skill area | Capacity (FTE) | Demand (FTE) | Gap |
|---|---|---|---|
| Development | 9.0 | 13.5 | +4.5 |
| QA / Testing | 3.5 | 2.8 | -0.7 |
| Architecture | 1.5 | 3.2 | +1.7 |
| Project management | 2.0 | 2.4 | +0.4 |
In this example, QA has surplus capacity. Development and architecture are significantly constrained. Approving more projects without addressing those two areas will slow every project already in flight. Knowing this before making approval decisions changes what the governance body chooses to do.
What the gap analysis drives
A gap analysis does not make decisions. It creates the conditions for honest decisions.
When demand significantly exceeds capacity, the governance body has four choices:
Defer lower-priority projects. Use the prioritized project list to identify which initiatives can wait until capacity opens. This is the most structurally sound option and the most politically difficult.
Hire or contract to expand capacity. Justified when the gap is persistent, the work is strategic, and the cost of delay exceeds the cost of additional resources. New hires take months to reach full productivity; contractors can come up to speed faster in well-defined scopes.
Reduce scope on approved projects. When deferral is not possible, descoping can free capacity. This requires honest conversations with the business owners of those projects about what gets cut.
Accept longer timelines. Spread the demand across more quarters to fit within the available capacity. This is often the unstated default; a gap analysis makes it an explicit, documented decision rather than a gradual slip.
The fifth option, the one most organizations take without a gap analysis, is to approve everything and let project managers figure it out. That is how portfolios fill with approved projects that make no progress and whose delays are attributed to execution failures rather than structural overcommitment.
What to include in the operational baseline
Operational demand is the work IT does that never appears as a project: keeping the lights on, responding to production issues, handling the enhancement queue, and supporting end users. In most IT organizations this consumes 30 to 45% of total capacity.
If the gap analysis only measures project demand, those 30 to 45% are effectively invisible. The capacity model looks like it has room for more projects. When those projects start, they discover that the team's actual availability is far below what the model predicted.
Capture the operational baseline as a separate demand line. Treat it like a project that claims a fixed percentage of each skill area's capacity before any projects are allocated. The remaining capacity is what the portfolio can realistically consume.
How often to run a gap analysis
Quarterly is the standard cadence for most IT organizations. The inputs change enough over a quarter, projects complete, new requests arrive, people join or leave, that a gap analysis from six months ago is usually no longer reliable.
An off-cycle review is warranted when a significant new project request arrives mid-quarter, a key resource departs and their work needs to be redistributed, or a project scope change significantly increases demand. Waiting for the next quarterly cycle in those situations means making resource decisions without current information.
For the mechanics of how FTE capacity is calculated, see our article on FTE planning for IT projects. For how the gap analysis informs the approval decisions made in the governance meeting, see how to run a portfolio review meeting.
Frequently Asked Questions
What is a capacity vs demand gap analysis in IT?
A capacity vs demand gap analysis compares the total available working time of the IT team against the total work being requested by the project portfolio. The gap, expressed in FTEs or hours, reveals whether the organization is asking IT to deliver more than it can realistically accomplish and which specific skill areas are most constrained.
How do you calculate IT capacity for a gap analysis?
Count available team members by skill area, multiply by working hours per period, then subtract time for non-project work, typically 20 to 30% for meetings, operational tasks, training, and support. A team of 12 developers over a 13-week quarter generates 6,240 gross hours, or roughly 4,680 net hours after a 25% overhead deduction, equal to 9.0 net FTEs.
What decisions does a capacity vs demand gap analysis drive?
When demand exceeds capacity, the governance body must choose between deferring lower-priority projects, hiring or contracting, reducing scope on approved projects, or accepting longer timelines. Without a gap analysis, organizations typically approve everything and let delivery teams absorb the overcommitment invisibly.
How often should an IT portfolio gap analysis be run?
Most IT organizations run a formal gap analysis quarterly. An off-cycle review is warranted when a significant new project arrives, a key resource leaves, or a scope change materially affects required hours. A gap analysis based on assumptions from six months ago is usually no longer accurate enough to drive decisions.