Capacity Planning vs Resource Planning: What’s the Difference?

How do the two questions differ in practice?

capacity planning vs resource planning is a key topic in modern project management and teamwork. They differ in horizon, unit, owner and decision. The confusion starts because both produce a spreadsheet that looks like a resourcing plan.

A useful test: if the answer would change because a specific person resigned, you are looking at resource planning. If the answer would change because the total number of designers fell by three, you are looking at capacity planning.

What actually counts as capacity?

Capacity is not headcount. It is the amount of work an organisation can genuinely complete in a period, after the losses that always occur.

Operations management draws a useful distinction. Design capacity is the theoretical maximum — everyone available, everything working. Effective capacity is what remains after quality problems, delays, rework and setup. The gap between the two is usually larger than managers expect, and it is the number that makes capacity forecasts wrong.

The standard calculation is:

Capacity = (people or machines) × (shifts or available hours) × utilisation × efficiency

Capacity planning covers three asset categories, not just people: people (enough trained staff), technology (systems, licences, compute) and infrastructure (facilities, equipment). A team of twelve consultants with one working meeting room and a shared licence for the design tool has a capacity constraint that will never appear in an hours forecast.

Worked example: annual billable capacity

A consultancy has 12 consultants, each contracted for 40 hours a week across 46 working weeks a year. The firm targets 75% billable utilisation to leave room for sales support, internal work and leave.

• Gross available hours = 12 × 40 × 46 = 22,080 hours
• Billable capacity = 22,080 × 0.75 = 16,560 hours

The pipeline for the year contains nine projects at an average of 2,200 hours each:

• Demand = 9 × 2,200 = 19,800 hours
• Gap = 19,800 − 16,560 = 3,240 hours short

One consultant delivers 40 × 46 × 0.75 = 1,380 billable hours a year. So the shortfall is 3,240 ÷ 1,380 = 2.35 full-time equivalents.

That single calculation changes the conversation. The question is no longer “can we staff this?” but “do we hire 2.35 people, raise utilisation to 90%, decline one project, or subcontract 3,240 hours?” Each option has a different risk, and all four are now visible.

Note what the 75% assumption did. At 90% utilisation, capacity rises to 19,872 hours and the gap vanishes — on paper. In reality, 90% utilisation on knowledge work produces queues, delays and burnout, which is the subject of a later section.

What does resource planning actually produce?

Resource planning turns capacity into a dated assignment schedule. Its output is not a number of hours but a set of commitments: this person, this task, these dates, this allocation percentage.

A working resource plan answers five questions for every week in the horizon:

1. Which named person is on which task?
2. At what allocation — 100%, 50%, two days a week?
3. Is the task on the critical path?
4. What does that person’s total allocation add up to, including support and internal work?
5. Where does anyone exceed 100%?

Question five is where resource planning earns its keep. Overallocation is invisible in aggregate numbers and obvious in a named allocation grid.

Worked example: one architect, two projects

An architect is needed by two projects in the same four-week window. Project A requires 60% of her time in weeks 14–17. Project B requires 50% in the same weeks.

• Combined demand = 60% + 50% = 110%
• Overallocation = 10%, or roughly 16 hours across four 40-hour weeks

Two standard techniques resolve it, and they are not interchangeable.

Resource levelling adjusts start and finish dates to fit resource limits. If the work is on Project B’s critical path, levelling can push B’s finish date. In this case, delaying B’s architecture tasks by one week absorbs the conflict but moves B’s completion from week 30 to week 33.

Resource smoothing keeps the finish date fixed and moves work within available float. It works only where float exists. If B has four days of float, smoothing resolves the conflict without touching the end date. If it has none, smoothing cannot help and the choice becomes levelling or finding another architect.

The distinction matters because teams often promise “we’ll smooth it” when there is no float to smooth with. The result is an unchanged schedule and an unchanged overload.

Where do the two plans break apart?

Four disconnects account for most failures.

Different cadences. Capacity is reviewed quarterly; resource plans are rebuilt weekly. By the time the weekly plan is honest, the quarterly assumption behind it is two months stale.

Different owners with different incentives. Sales is measured on bookings, delivery on margin, finance on cash. Capacity planning is the only place those three meet, and it is usually nobody’s primary job.

Hiring lag versus project lead time. Recruiting a specialist commonly takes two to four months; a project commitment is often made in two weeks. Any capacity gap discovered at project kickoff is therefore already unfixable by hiring, which means the realistic options are subcontracting or declining.

Utilisation targets that assume no variability. A plan built at 95% utilisation has no room for sick leave, rework, or the two-week onboarding of a new joiner. The plan is arithmetically valid and operationally impossible.

> Important note: if your capacity plan and your resource plan are produced by different teams in different tools and reconciled by email, you do not have two plans. You have two opinions.

Why is 100% utilisation a bad capacity target?

Because queues grow non-linearly as utilisation approaches the limit. A standard queueing approximation puts waiting time in proportion to utilisation divided by one minus utilisation.

The interpretation is straightforward: at 80% utilisation, work waits about four times as long, relative to its service time, as it would in an idle system. At 95%, it waits about nineteen times as long.

This is why teams that “improve” utilisation from 80% to 95% often report worse delivery performance. They did not add capacity; they removed the buffer that absorbed variability. The output of a system with no slack is not more output, it is more delay.

For planning purposes, the practical implication is that effective capacity should be set below theoretical capacity on purpose, and the gap should be an explicit, defended number rather than an accident.

Which plan should you build first?

Build capacity planning first if you commit to work before you know who will do it — agencies, consultancies, contract manufacturers, internal service teams. Build resource planning first if your commitments are fixed and your problem is execution inside them.

The sequence that works for most organisations:

Stage 1 — Resource planning only. You have fewer than roughly 30 delivery people and a stable pipeline. A named allocation grid per week is enough; capacity lives in the manager’s head and is usually accurate at that scale.

Stage 2 — Add role-level capacity. You have multiple teams or a sales pipeline that outpaces your ability to staff it. Add a quarterly view of demand against available hours by role, with utilisation and efficiency assumptions written down.

Stage 3 — Connect them. You have hiring, subcontracting and declining as real decisions. Capacity sets the envelope; resource planning works inside it; a monthly reconciliation checks that the envelope still holds.

Skipping to stage 3 with a ten-person team produces an impressive dashboard nobody uses. Staying at stage 1 with two hundred people produces the situation at the start of this article.

How do you connect the two plans month to month?

A monthly rhythm, four meetings, one dataset.

Weekly: the resource manager reviews the named allocation grid for the next six weeks, resolves overallocations above 100%, and flags anything that needs a decision outside their authority.

Monthly: compare actual hours booked by role against the capacity plan. If the plan assumed 75% billable utilisation and the actual is 68%, either the capacity was overstated or the demand was misclassified. Both matter.

Quarterly: re-forecast demand from the pipeline and re-forecast capacity from confirmed hires, attrition and known leave. Update the utilisation and efficiency assumptions with real data rather than last year’s target.

Annually: decide the structural question — hire, contract, or reshape the service offering — using the quarterly data rather than a budget spreadsheet.

The reconciliation step is the one that gets skipped, and it is the one that keeps the two plans honest. A one-page variance report — planned hours versus booked hours by role, with three bullet explanations — is enough.

How does tooling change the picture?

Two numbers determine whether this works: how long it takes to produce a trustworthy allocation view, and whether demand is recorded in the same place as delivery.

If the pipeline lives in a CRM, capacity in a spreadsheet, and assignments in a task board, then every monthly reconciliation is a manual join of three exports. That takes days, so it happens quarterly, so the plan is always behind.

The workable setup keeps demand, capacity and assignment in one system: a request or opportunity with estimated effort, a role-level capacity pool with availability and leave, and assignments against named people on real tasks. Then the allocation grid is a view rather than a project.

Doitify covers much of that middle ground: resource and workload management, Kanban boards with tasks and sub-tasks, owners and due dates, sprints and backlogs, Gantt and calendar views, and work and performance reports that show workload by person. Transparency note: Doitify is our product. It will not tell you how many consultants to hire — that judgement needs your utilisation history and your sales pipeline — but it does keep the assignment data current enough for the judgment to be worth making.

What are the limits and trade-offs?

Granularity has a cost. A capacity plan at role level is fast and slightly imprecise. At individual-skill level it is precise and needs constant maintenance. Choose the level that matches your hiring lead time: if you hire by role, plan by role.

Aggregate plans hide the constraint. Capacity can be healthy overall while one scarce skill — a security architect, a licensed inspector — is the real bottleneck. Always check the top three constrained roles separately.

Resource plans decay quickly. Any allocation grid more than three weeks old is a historical document. Treat it as a snapshot, not a commitment.

Forecasting demand is the weak link. Capacity arithmetic is easy; predicting which projects will actually start is not. Keep a probability weighting on the pipeline and revise it monthly, rather than treating bookings as certain.

What mistakes should you avoid?

• Confusing utilisation with capacity. Utilisation is a ratio; capacity is hours. A team can hit 100% utilisation on the wrong work.
• Planning at 100%. No slack means no absorption of variability, and variability is guaranteed.
• Ignoring non-project work. Support, sales, internal initiatives and leave consume real hours. A capacity plan that omits them is optimistic by design.
• Building the resource plan before the capacity envelope exists. Then every overallocation becomes a negotiation instead of a scheduling problem.
• Treating a signed contract as fixed demand while treating the team as flexible supply. Both sides move; model both.
• Never reconciling plan to actuals. Without it, the assumptions never improve and the same forecasting error repeats annually.

Conclusion

Capacity planning and resource planning answer different questions at different altitudes. Capacity asks whether there is enough of anything to take the work; resource planning asks who will do it and when. Confusing them produces the familiar scene of a signed contract, an overloaded team and a hiring freeze discovered in the same week.

The fix is procedural rather than technical. Write down your utilisation and efficiency assumptions. Compute capacity by role for a horizon that covers your hiring lead time. Keep assignments in a named grid that shows anyone above 100%. Reconcile planned hours against booked hours every month, and treat unexplained variance as a defect rather than a surprise.

Do that and the two plans stop contradicting each other. Capacity becomes the boundary of what you promise, resource planning becomes the mechanism for keeping the promise, and the argument moves to the question that actually matters: which work is worth the capacity you have.

If this post on capacity planning vs resource planning was helpful, you might also enjoy How to Improve Project Visibility and Best Workflow Automation Software for Project Teams.