IT capacity planning: why every team is at 120 percent

Ask any technology leader how loaded their teams are and the answer is the same: over capacity. Everyone is at 120 percent, every project is late, and new requests still arrive every week. IT capacity planning is supposed to prevent this, but in most organizations it consists of a spreadsheet nobody trusts and a hope that things will work out.

The root problem is simple. Demand is approved one request at a time, while capacity is fixed. Without a view of both, every approval looks affordable on its own.

Why capacity planning breaks down

Capacity is measured as headcount, not availability

Ten developers isn't ten developers' worth of project capacity. Subtract support, incidents, meetings, leave, onboarding and maintenance, and the real number available for new investment is often half of the headcount, or less.

Unplanned work is invisible

Production issues, urgent fixes and "quick favors" consume capacity every week but rarely appear in plans. When unplanned work runs at 30 or 40 percent, plans that assume 10 percent are fiction from day one.

Approvals ignore what's already committed

A decision forum that approves requests without seeing current commitments will always over-commit. Each project's estimate looks reasonable; the total does not.

Shared specialists become hidden bottlenecks

A team may have spare capacity on paper while the one database specialist or security reviewer every project needs is booked for months. See Cross-team dependencies.

A practical approach to IT capacity planning

1. Measure real availability

For each team, track for a few weeks how time is actually spent. Use broad buckets:

Your numbers will differ. The point is to know them. The "new investment" share is the capacity that intake decisions actually compete for.

2. Use throughput, not hours

Rather than estimating hours, use what teams actually complete. If a team finishes about four medium-sized items a quarter, that's its capacity for planning purposes. It already includes the reality of interruptions.

3. Hold a capacity line in the decision forum

Show the decision forum how much capacity is available next quarter, how much is already committed, and what each new request would consume. When the line is full, approving something new means deferring something else. That makes trade-offs explicit, which is the whole point. See Designing a project approval workflow.

4. Reserve capacity on purpose

Set aside an explicit share for unplanned work and for technical health, based on measured history, not hope. If unplanned work runs at 25 percent, plan for 25 percent. See Making technical debt visible.

5. Re-plan on a regular cadence

Capacity changes. People leave, incidents spike, priorities shift. Review the capacity picture monthly or quarterly and adjust commitments openly, rather than letting them slip quietly.

How to say no with evidence

Capacity planning is ultimately about making "no" or "not yet" defensible. Compare these two responses to an executive request:

• "We're too busy." (Heard as reluctance.)
• "Our available capacity next quarter is fully committed to these four investments, ranked by value. Yours would rank second. If you want it this quarter, we'd defer the claims automation, which is worth about $200,000 a year. Which would you prefer?" (Heard as a decision.)

The second answer requires a prioritized list with values attached. See IT portfolio prioritization.

Signs your capacity plan is working

• Forecasts are usually within 20 percent of actuals.
• The share of work started without approval is falling.
• Teams can name their top three commitments without hesitation.
• When a new urgent request is approved, something else is visibly deferred.

How Aizu helps

Aizu brings capacity into the commitment conversation rather than leaving it in a separate spreadsheet. Gate checks before commitment can confirm the accountable owner, funding and capacity, and delivery confidence views show capacity and delivery signals alongside scope, dependencies and risk. Because every request is ranked against the rest of the portfolio, deciding what to defer is a visible trade-off rather than a quiet slip. Related: Delivery forecast accuracy.