Tag: Capacity Planning

There are two modes of capacity management. In the reactive mode, you learn about overload when something breaks — a deadline slips, a team member burns out, a customer escalates. You scramble, reprioritise, and get back on track. Then the same thing happens next quarter.

In the predictive mode, you know about overload before it becomes a problem. You see it in the data, you surface it in planning, and you make deliberate decisions about what to take on and what to defer. The emergencies still happen — but they’re rarer, and the organisation is more resilient when they do.

The distance between these two modes isn’t technology or headcount. It’s culture — specifically, the habits, cadences, and psychological safety required for teams to tell leadership the truth about their capacity.

Why Reactive Mode Persists

Organisations stay reactive because being honest about capacity feels unsafe. If a team says “we can’t take that on,” they risk being seen as underperforming or resistant. If a project manager says “this won’t fit in the quarter,” they risk being told to find a way.

So instead, teams accept commitments they can’t honour. Plans get agreed that everyone privately knows are unrealistic. And then, when things slip, it’s treated as execution failure rather than planning failure.

The Cultural Shift Required

Predictive capacity planning requires a cultural contract: leadership will not penalise teams for honest capacity assessments. That sounds obvious, but in practice it means COOs and leadership teams need to visibly reward people for surfacing capacity concerns, not quietly penalise them for not finding a way.

It also means building the cadences that make transparency normal. A monthly capacity review where overloads are surfaced and addressed is a structural mechanism for honesty. Teams that know leadership will act on the data are much more likely to surface it accurately.

The Tooling Corollary

Culture alone isn’t enough. You also need tooling that makes capacity data easy to see and easy to update. If the capacity planning process requires three hours of manual data entry in a spreadsheet, teams will only do it quarterly — which is not frequent enough. If it’s embedded in the project and resource management system, it can be maintained in real time.

The best capacity planning cultures are ones where the data is always current, always visible, and always connected to the decisions being made.

Building the Cadence

Start with a quarterly planning cycle that uses scenarios. Add a monthly check-in where teams update their utilisation and flag emerging overloads. Add a weekly signal — even just a simple red/amber/green flag per team — so early warnings surface before they become crises.

Over two to three quarters, this cadence builds the habit. Teams start thinking about capacity proactively. Leaders start using capacity data in their decision-making. The language shifts from “we’ll manage” to “here’s what we can commit to and here’s what we can’t.”

That shift is the difference between reactive and predictive — and it’s worth every ounce of effort it takes to build.

Chronic overload rarely announces itself. It accumulates quietly — in small deadline slips, in the team member who stops asking questions, in the bug that gets logged but never prioritised. By the time it’s visible at the leadership level, it’s usually been embedded in the team’s culture for months.

Here are five signals — and the data points that surface them.

1. Deadlines Consistently Slip by 20–30%

A project that was going to take 8 weeks takes 10–11. Another that was going to take 4 weeks takes 5–6. The slippage percentage is relatively consistent — which is a clue. It’s not project-specific risk. It’s systemic under-resourcing.

The data: Compare planned vs actual delivery dates across your project portfolio over the last two quarters. If the average slippage is 20–30% and it’s consistent across teams, that’s a capacity signal, not a project management one.

2. Your Best People Are On the Most Projects

Senior talent gets pulled towards the hardest problems. That’s natural. But senior talent also gets pulled toward every problem because they’re trusted, available, and hard to say no to. The result is your top performers spread across five to eight projects simultaneously, delivering at fractional quality on all of them.

The data: Map your top performers against current project allocations. If any individual appears on more than three concurrent initiatives, you have a concentration risk.

3. “Quick Tasks” Are Taking Weeks

When a team is at capacity, even small requests take disproportionately long. A two-hour fix takes three days because there’s no slack in the system to absorb even minor work without queuing. This is called queueing delay, and it’s a classic capacity saturation symptom.

The data: Track cycle time for small or low-complexity issues. If “small” tasks are sitting in backlogs for five or more days before anyone touches them, the team’s queue is saturated.

4. Quality Issues Are Increasing

Overloaded teams cut corners — not because they’re careless, but because they’re trying to meet commitments with insufficient time. Code review gets abbreviated. Testing gets compressed. Documentation gets skipped. The downstream effect is bugs in production, customer complaints, and rework cycles that consume the next quarter’s capacity.

The data: Track defect rates, bug-to-feature ratios, and rework cycles quarter-over-quarter. Rising defect rates alongside rising workload is a near-certain capacity saturation signal.

5. Attrition Is Climbing

When people are chronically overloaded, the first exit is internal disengagement — quiet quitting. The second exit is actual departure. High-performing people leave first because they have options and they recognise the structural problem. What gets left behind is a team that’s smaller, less experienced, and even more overloaded.

The data: Track voluntary attrition by team and correlate it with utilisation rates. Teams with sustained utilisation above 90% almost always show elevated attrition within two to three quarters.

What to Do

Naming the problem is step one. Step two is bringing the data to a leadership conversation. Step three is making a structural decision — not a motivational one. Telling overloaded teams to “prioritise better” or “work smarter” is not a solution. Reducing their committed workload is.

Every COO has heard it. “We’re at capacity.” “The team is stretched.” “We can’t take on anything else.” And yet somehow, when a new priority lands — a board request, a sales commitment, a product emergency — the team finds a way to absorb it anyway. They work nights. They skip the lower-priority sprint items. They cut corners no one will notice until six months later.

The result is a slow, invisible erosion: burnout, attrition, quality debt, and a culture where “we’ll manage” becomes the default answer even when it really shouldn’t be.

The 120% capacity problem is one of the most universal and most damaging patterns in modern operations — and it almost always comes down to one thing: the way teams plan capacity doesn’t reflect how work actually flows through the organisation.

Why Planning at 100% Is Already Wrong

When you assign someone to a project at “100% capacity,” you’re assuming all of their working hours are available for that project. But that’s not how people work. Meetings, 1:1s, hiring interviews, ad hoc requests, Slack messages, context-switching — these consume 20–40% of most knowledge workers’ time before they’ve written a single line of code or processed a single task.

Experienced operations leaders know to plan at 70–80% utilisation. But most teams are still capacity-planned at 100%, which means every project they’re assigned to is already under-resourced before it begins.

The Visibility Problem

The second issue is aggregation. A COO typically sees project status at the portfolio level — RAG (Red/Amber/Green) status, milestone dates, budget consumed. What they don’t see is the person-level reality underneath: that three of your senior engineers are each allocated to five concurrent projects, or that your only UX designer is a single point of failure across six product initiatives.

Without visibility into team-level capacity, all you can do is respond to fires rather than prevent them.

The Allocation-Without-Timeline Problem

Many organisations track who is allocated to what, but not for how long. Knowing that Sarah is “on the platform migration” tells you very little. Is that 20% for two weeks? 80% for six months? The absence of time-bounded allocation is what causes the compounding effect — more work gets committed to the team because it looks like there’s slack that doesn’t exist.

What Good Capacity Planning Looks Like

Effective capacity planning requires three things working in concert:

1. Baseline capacity, not theoretical capacity. Know how many available hours per person per quarter exist after meetings, leave, and overhead — not just raw working days.

2. Time-bounded allocation. Every person’s allocation to every project should have a start and end date and a percentage. “Sarah: Platform migration, 60%, Q3 2025” is a capacity plan. “Sarah: Platform migration” is a hope.

3. Demand vs supply visibility. You need to see, at the quarter level, whether the total demand being placed on each team is greater than or less than their available supply. If it’s greater, something gives — and it’s better if you’re the one deciding what, not gravity.

The Compounding Effect of Chronic Overload

Teams that operate at 120% for a quarter can recover. Teams that operate at 120% for three years cannot. The long-term effects are well documented: increased attrition, reduced quality, slower velocity over time as technical and process debt accumulates. The people who leave first are always your best ones — they have options.

The COO’s job is to ensure the organisation is structured and resourced to deliver the strategy. That’s impossible if the teams executing the strategy are structurally unable to succeed.

What to Do This Quarter

Start with a capacity audit. For every team, answer: what is their realistic capacity this quarter (in person-days or hours, after overhead)? What work are they currently allocated to, and what does that total? The gap between those two numbers is your capacity deficit — and naming it is the first step to addressing it.

From there, you have a choice between four responses: increase supply (hire or contract), decrease demand (deprioritise work), extend timelines, or improve throughput. Each has implications. Only one of them — continuing to absorb overload silently — has no good long-term outcome.

Quarterly capacity planning is one of the highest-leverage activities a COO can run. Done well, it aligns the entire organisation on what’s possible, surfaces resource conflicts before they become crises, and gives leadership a clear view of whether the roadmap is achievable with the people and budget available.

Done poorly, it’s a spreadsheet exercise that takes three weeks, produces a plan nobody trusts, and is obsolete by week two of the quarter.

Here’s a practical framework for running a capacity planning process that actually works.

Step 1: Establish Your Baseline Capacity

Before you can plan, you need to know what you have. For each team, calculate:

• Total working days in the quarter (accounting for public holidays)
• Leave and absence buffer (typically 5–10%)
• Overhead allocation (meetings, 1:1s, admin, recruitment — typically 20–30%)
• Net available capacity per person and per team

The output is a simple table: Team → Members → Net Available Days. This is your supply side. It rarely matches the number people assume.

Step 2: Map Your Demand

List every project, initiative, or workstream expected to run this quarter. For each one, capture:

• Which team(s) are required
• What percentage of each team’s time is needed
• Whether it’s a new commitment or a continuation from last quarter

The total demand across all projects, by team, is your demand side. When you put supply and demand side by side, the picture is almost always sobering.

Step 3: Identify Conflicts Early

Look for teams where demand exceeds supply by more than 15–20%. These are your high-risk teams — not because they can’t work hard, but because they’re being asked to commit to more than is structurally achievable. Flag them explicitly.

For each overloaded team, convene a conversation: what can be deferred, descoped, or resourced differently? This is a leadership decision, not a planning admin task — it requires authority to reprioritise.

Step 4: Run Scenarios

Before locking the plan, model at least two alternatives. What does the quarter look like if you delay Project X by six weeks? What if you bring in a contractor for the backend team? Scenario modelling at the planning stage is far cheaper than replanning mid-quarter.

Step 5: Publish and Socialise

A capacity plan that lives in one person’s spreadsheet isn’t a plan — it’s a private forecast. Publish the agreed plan, make it visible to team leads, and review it at your monthly operations cadence. As projects change, update it in real time rather than waiting for the next quarterly cycle.

Common Mistakes to Avoid

Planning to 100%. Always leave a buffer. Unplanned work will arrive — it always does.

Treating teams as fungible. “The engineering team has capacity” masks the reality that it’s the two senior engineers who are over-allocated, not the juniors.

Skipping the demand-side audit. It’s tempting to start with who’s available rather than what’s been committed. Always start with demand — it’s harder to cut than to distribute.

Doing this once a year. Annual capacity plans are useful for headcount forecasting. Quarterly plans are what actually drive execution decisions.

The Payoff

COOs who run a disciplined quarterly capacity process consistently report fewer mid-quarter surprises, better team morale, and stronger delivery predictability. The process takes time to embed — the first cycle is always the hardest — but the compounding return on operational clarity is substantial.

Capacity planning and resource planning are often used interchangeably, but they answer different questions. Understanding the distinction — and using both — is one of the markers of an operationally mature organisation.

What Is Resource Planning?

Resource planning answers the question: who is working on what? It’s about assignment and allocation. Which people, teams, or skills are attached to which projects? Resource planning gives you a map of your workforce against your project portfolio.

Good resource planning surfaces things like: Sarah is allocated to three projects simultaneously; the UX team is a dependency on six initiatives; the platform team has no allocation for Q3 beyond BAU.

What Is Capacity Planning?

Capacity planning answers the question: can we deliver what we’ve committed to, given the people and time we have? It’s about supply vs demand. Even if you’ve assigned all your resources to all your projects, capacity planning tells you whether those assignments add up to a feasible plan.

A resource plan tells you everyone is assigned. A capacity plan tells you whether they’re assigned to too much.

Why You Need Both

Many organisations do one but not the other. Teams that resource-plan without capacity-planning know who is working on what but consistently miss deadlines — because they’ve committed to more than is achievable. Teams that capacity-plan without resource-planning have aggregate numbers that look fine at the portfolio level but have critical skill bottlenecks hidden underneath.

The complete picture requires both: who is on what (resource), and whether the total is feasible (capacity).

Where They Diverge

Dimension	Resource Planning	Capacity Planning
Primary question	Who is on what?	Can we deliver?
Unit of measure	People / roles	Time / availability
Time horizon	Project duration	Quarter / sprint
Key output	Allocation map	Supply vs demand gap
Who drives it	Project managers	COO / operations

Practical Integration

The best approach is to run them in sequence. Start with resource planning at the project level — assign people and teams to initiatives. Then roll up into capacity planning to validate the aggregate. If the aggregate shows overload, you go back to the resource plan and adjust.

In practice, this means your project management and capacity planning tools need to talk to each other — or live in the same system. When they don’t, you get the classic COO problem: resource plans that look complete and capacity plans that are never trusted because the data is always out of date.

Most quarterly planning processes work like this: leadership agrees a roadmap, project managers estimate effort, someone runs a spreadsheet to see if it fits, and then everyone agrees it fits even when it clearly doesn’t — because nobody wants to be the person who says the plan is unrealistic.

Scenario-based capacity reviews break this cycle. Instead of trying to fit everything in and hoping for the best, you model two or three explicit alternatives before the quarter starts and make a deliberate choice between them.

What Is a Scenario-Based Capacity Review?

A scenario-based review presents decision-makers with multiple versions of the quarter’s plan, each with different assumptions, trade-offs, and outcomes. Rather than one “the plan,” you have:

• Scenario A (Aggressive): Full roadmap, requires every team at 95%+ utilisation. High risk of slippage.
• Scenario B (Balanced): Core roadmap items delivered, two initiatives deferred. Teams at 75–80% utilisation.
• Scenario C (Conservative): Focuses on three strategic priorities only. Teams have capacity buffer for unplanned work.

Leadership chooses the scenario, not the capacity analyst. That’s the key difference.

Step 1: Build the Baseline Scenarios

Before the planning meeting, the operations team should have built at least two scenarios using the team’s actual capacity data. Each scenario should show, for each team: total available capacity, total demand in scenario, utilisation percentage, and which projects are included or excluded.

Step 2: Surface the Trade-Offs Explicitly

Each scenario should come with an explicit statement of what you gain and what you lose. Scenario A delivers more output but carries delivery risk. Scenario C carries less risk but sacrifices velocity. Leadership can only make a good decision if the trade-offs are visible.

Step 3: Account for Known Unknowns

Every quarter has unplanned work — support escalations, urgent board requests, unexpected attrition. Build a “unplanned work buffer” (typically 10–20% of total capacity) into each scenario. Scenarios that don’t include this buffer are not realistic, regardless of how clean the numbers look.

Step 4: Decide and Document

Once leadership has chosen a scenario, document which projects are in, which are out, and what the decision criteria were. This documentation is what you return to mid-quarter when someone asks “why isn’t Project X further along?”

Why This Works

Scenario-based reviews shift the conversation from “can we deliver everything?” (always answered with optimistic yes) to “which version of the quarter do we want?” (a real choice with real trade-offs). That shift is small but powerful — it creates accountability for the plan rather than ambiguity about it.