We use cookies to enhance your browsing experience, serve personalised ads or content, and analyse our traffic. By clicking "Accept All", you consent to our use of cookies.
Preferences
Strictly Necessary
These cookies are essential for the website to function and cannot be switched off.
Functional
Enable enhanced functionality and personalisation, such as videos and live chats.
Analytics
Help us understand how visitors interact with the site by collecting anonymous information.
Marketing
Used to deliver advertisements more relevant to you and your interests.
The Enterprise Guide to Resource and Capacity Planning
Resource and capacity planning compares current and proposed work with the people, teams, skills, and time available to deliver it. This guide explains how enterprise organizations calculate capacity, forecast demand, allocate resources, and plan across waterfall, agile, and hybrid portfolios.
Resource and capacity planning is the process of comparing current and proposed work with the people, teams, skills, and time available to deliver it. Capacity planning determines how much work the organization can credibly take on. Resource planning determines how approved work will be staffed.
Together, they connect portfolio decisions with the people and teams responsible for delivery.
The terminology varies between organizations. A PMO may use resource planning to describe named assignments. A product organization may plan against the capacity of stable teams. Finance may use workforce capacity planning to model FTE cost and future headcount.
Term
Definition
Resource management
The management of people, roles, skills, calendars, costs, and assignments across current work.
Resource planning
The assignment of people, roles, or teams to approved work.
Capacity planning
The assessment of whether available people, teams, and skills can meet current and proposed demand over a defined period.
Resource allocation
The capacity committed to an initiative, project, product, or run activity.
Resource forecasting
The estimate of the roles, skills, teams, and external capacity that future work will require.
Resource management maintains the availability, roles, skills, rates, calendars, and assignments that planning depends on. Capacity planning uses that information to test whether the current and proposed portfolio fits the resources available.
A headcount total is not a capacity plan. The organization also needs to know when people are available, which skills they hold, what work has already been committed, and how delivery is organized.
Resource planning vs capacity planning
Resource planning assigns people or teams to approved work. Capacity planning tests whether enough suitable capacity exists to take on that work.
The two disciplines are closely related, but they operate at different levels and across different planning horizons.
Dimension
Resource planning
Capacity planning
Primary question
Who or which team will deliver the work?
Does enough suitable capacity exist to take on the work?
Typical horizon
Near term to medium term
Medium term to long term
Typical detail
Named people, roles, skills, teams, and assignments
Demand, available capacity, constraints, scenarios, and planning periods
Main users
Resource managers, delivery leaders, and project managers
PMO, EPMO, finance, technology leadership, and portfolio owners
Main decisions
Assignment, workload, backfill, and scheduling
Approval, sequencing, prioritization, hiring, contracting, and stopping work
Main output
A staffed delivery plan
A portfolio that fits the capacity available
The distinction matters because a staffed initiative may still create a problem elsewhere in the portfolio. It may consume a scarce skill required by a higher-priority commitment. It may also rely on capacity that another function has already allocated.
Current and proposed work
ProjectsInitiativesProductsRun activity
Capacity planning
Does the work fit the available teams, people, and skills?
Portfolio decisions
ApproveChange timingChange scopeAdd capacityPause
Resource planning
Assign people, roles, or teams to the approved work.
Capacity planning tests whether the portfolio fits the capacity available. Resource planning then assigns that capacity to approved work.
Capacity planning at portfolio level
Capacity planning tests whether the organization can deliver the work it has approved or is considering. A business case can show that an investment is affordable without proving that the required people, teams, and skills will be available when the work needs them.
This becomes a portfolio question because the same capacity serves competing demands. A data engineering team may support a regulatory program, a customer platform, run activity, and several smaller changes. Approving each item separately can produce more work than the team can deliver.
Capacity information should therefore sit alongside value, cost, risk, and dependencies in steerco, MBR, and investment committee reviews. Leadership needs to see where planned work exceeds available capacity, which team or skill is affected, and what decision is required.
Capacity planning also changes how RAG is interpreted. An initiative may report green against its own plan while relying on shared capacity that has already been committed elsewhere. The portfolio view should expose that conflict before it affects a milestone.
What work should capacity plans include?
A capacity plan should include work already in delivery, approved work that has not started, proposed work, and the run commitments that consume the same people and teams.
The plan should also distinguish between work that is confirmed and work that is still being assessed. An approved regulatory initiative should not carry the same level of certainty as an early idea with no agreed scope.
Run activity. Service management, maintenance, incidents, controls, and recurring operations. Reserve capacity before assigning change work.
In-flight work. Approved initiatives, projects, products, and programs already consuming capacity. Treat as committed unless governance changes the plan.
Approved work not started. Funded work waiting for a start date, dependency, or suitable capacity. Confirm timing and resource assumptions before delivery commits.
Proposed work. Business cases, epics, initiatives, and requests under assessment. Use an estimate that reflects the maturity of the proposal.
Regulatory or mandatory work. Work with legal, risk, audit, or policy deadlines. Record the deadline and consequence of delay.
Unplanned work. Production incidents, urgent remediation, and emerging obligations. Hold a visible allowance or accept the effect on planned delivery.
Each item needs enough information to support the decision. This usually includes the owner, expected outcome, delivery window, estimated effort, required skills, dependencies, and the level of confidence in the estimate.
Early-stage demand does not need the detail of an approved delivery plan. Requiring named resources and precise dates too early creates work without improving the investment decision.
How do you calculate available capacity?
Available capacity is the capacity left after fixed commitments, known absence, non-delivery responsibilities, and an allowance for unplanned work have been removed from gross capacity. Contracted hours, FTE totals, and supplier headcount do not show this on their own.
A practical calculation starts with gross capacity for the planning period and deducts each category consistently.
Available capacity = gross capacity − fixed commitments − known absence − non-delivery activity − planning allowance
For example, a technology function may have 20 FTE of gross capacity for a quarter. If 8 FTE are reserved for run activity, 2 FTE cover known absence and non-delivery responsibilities, and 2 FTE are held as a planning allowance, 8 FTE remain available for planned change. The figures illustrate the calculation rather than a recommended allocation.
The formula is a control, not a universal accounting rule. Each input needs a consistent definition. The planning unit should also match the decision. Hours may suit a named-resource schedule. FTE may suit a functional forecast. Throughput may suit a stable team.
Capacity input
Credible treatment
Common error
Vacancies
Record separately until a start date and suitable skill profile are credible
Counting approved roles as immediately available
Contractors
Include the contracted period, skills, rate, and notice terms
Treating external capacity as permanent or interchangeable
Part-time staff
Use contracted availability by period
Counting each person as one FTE
Run commitments
Reserve before assigning change work
Treating operational work as residual effort
Leave and training
Apply known calendar impacts at the level used for planning
Ignoring predictable absence in a named-resource plan
Shared specialists
Record all portfolio commitments against the same role or skill pool
Allocating the same specialist through separate plans
Stable teams
Use team capacity where the team owns assignment
Rebuilding the team as a collection of interchangeable individuals
Planning every person or team to full theoretical capacity produces a plan with no allowance for incidents, estimate error, handoffs, or priority changes. The allowance should remain visible. Hiding it inside estimates makes the plan harder to review.
What level should capacity be planned at?
Capacity should be planned at the level required by the decision. Depending on the horizon and the work, that may mean an individual, role, skill, team, function, value stream, or supplier.
A project manager may need to know which architect starts next month. A steerco deciding whether to approve several initiatives may only need to know that architecture demand exceeds available capacity for the next two quarters.
Planning level
Best used for
Main limitation
Individual
Near-term assignment, specialist scheduling, time recording, and project cost attribution
Becomes volatile and expensive to maintain at enterprise scale
Role
Early estimation, workforce planning, and project staffing profiles
Can hide differences in experience and domain knowledge
Skill
Scarce capability forecasting, hiring, supplier decisions, and cross-functional constraints
Depends on a controlled and current skills taxonomy
Team
Product, platform, value stream, and stable-team planning
Requires stable team boundaries and a credible measure of capacity
Function or value stream
Portfolio scenarios, investment planning, and senior governance
May not expose the specific role or skill causing the constraint
Supplier
External capacity, contract planning, and sourcing decisions
Contracted volume may not equal suitable or immediately available capacity
A portfolio may use several levels at once. Early demand can sit at role or skill level before approved project work moves to named assignments. Product work can remain at team level. The portfolio view should reconcile those models without forcing every function into the same degree of detail.
Individual vs team-based capacity planning
Individual planning assigns named people to work. Team-based planning treats an established team as the unit of capacity and sequences work into the capacity that team has available.
Neither model is universally better. Individual planning is appropriate where a project needs specific people, where specialist availability determines the schedule, or where cost and time must be recorded against named assignments. Team-based planning is appropriate where a stable team owns a product, platform, service, or value stream.
Dimension
Individual planning
Team-based planning
Unit of capacity
Named person
Stable team
Typical use
Projects, specialist work, and near-term scheduling
Products, platforms, value streams, and continuing change
Main planning input
Availability, role, skill, calendar, and assignment
Team capacity, backlog priority, throughput, and dependencies
Main strength
Detailed assignment and cost control
Stable ownership and lower planning maintenance
Main risk
False precision and fragmented allocation
Hidden differences in individual skills or availability
Individual planning becomes less reliable as the horizon extends. A named assignment for near-term work may be useful. Detailed percentage allocations far into the planning horizon become less credible as priorities, people, and delivery plans change.
Team-based planning also needs discipline. The team needs a clear boundary, a known cost, and an agreed way to measure available capacity. Shared specialists and cross-team dependencies still need explicit treatment.
The practical approach is to use the lowest level of detail required by the decision. Capacity can remain at team, role, or skill level until a named assignment becomes necessary.
Waterfall capacity planning usually defines the work first, then assigns people or roles to delivery phases. Agile capacity planning usually starts with an established team, then sequences prioritized work into the capacity that team has available.
Waterfall and agile are not exact synonyms for project-based and team-based delivery, but the distinction reflects how capacity is commonly planned in enterprise portfolios.
Dimension
Waterfall capacity planning
Agile capacity planning
Starting point
Defined scope, schedule, and project phases
Stable team and prioritized backlog
Primary unit
Individual, role, or skill
Team
Planning logic
Assign people to planned work
Assign work to available team capacity
Typical horizon
Project phases, months, and quarters
Sprint, PI, quarter, and roadmap horizon
Main control
Staffed schedule against milestones and cost
Backlog priority against capacity, throughput, and dependencies
Main risk
Contested specialists, handoffs, and over-detailed long-range allocations
Unclear priorities, overloaded backlogs, and hidden cross-team dependencies
Waterfall capacity planning remains appropriate where delivery has a defined scope, end date, cost baseline, and temporary team. It provides the detail needed to plan roles by phase and assign named specialists where the schedule depends on them. Project capacity planning tests whether the roles, skills, and named resources required by a project will be available in each delivery phase.
Agile capacity planning fits products, platforms, and value streams where a stable team owns a continuing area of work. The planning question is not which person will spend a fixed percentage on each item. It is which work should enter the team's available capacity, in what order, and with which dependencies resolved.
Waterfall / project-based
Defined project
Required roles and skills
People assigned by phase
Project schedule and cost
Agile / stable-team
Durable team with known capacity
Prioritized backlog
Work sequenced into the team
Throughput and delivered outcomes
Waterfall planning assigns people to defined work. Agile planning sequences prioritized work into the capacity of an established team.
How does hybrid capacity planning work?
Hybrid capacity planning keeps the planning methods used by projects and stable teams distinct, then brings their timing, cost, dependencies, and capacity requirements into one portfolio view.
A hybrid portfolio may contain traditional projects, agile teams, product funding, regulatory programs, and shared enterprise functions. It does not require every team to use the same planning method.
Project-based work may plan through roles, named resources, phases, and project dates. Stable teams may plan through team availability, backlog priority, throughput, and product or value stream funding. Both should feed a common portfolio view without being reduced to the same resource grid.
Shared specialists need particular attention. Architecture, cyber, risk, data, and change specialists may support both projects and stable teams. Their commitments should be visible across the portfolio, even where the underlying delivery teams use different planning methods.
Partial assignment may be necessary for scarce roles. It should not become the default for every member of a stable team. Repeatedly dividing team members across several projects weakens team capacity, increases handoffs, and makes the plan harder to maintain.
A hybrid portfolio also needs consistent financial treatment at the point of investment. A project may use role rates and project codes. A product team may operate as a fixed cost. Leadership still needs a coherent view of what the portfolio costs and whether the required capacity is available.
Portfolio commitments
Strategic initiativesRegulatory workTechnology changeProducts and platformsRun commitments
Project-based planning
Roles and individualsProject phasesNamed allocationsProject cost
Stable-team planning
Durable teamsProduct or platform backlogsTeam-level capacityTeam funding
One portfolio view
TimingCostDependenciesConstrained teams or skillsPriority
Hybrid portfolios keep project and team-based planning distinct while bringing both into one portfolio view.
How do you forecast future resource demand?
Resource forecasting estimates the roles, skills, teams, and external capacity that future work will require in each planning period. Headcount provides a starting point, but it does not show whether the portfolio has the right people at the right time.
A function may have available headcount while lacking the enterprise architects, cyber specialists, data engineers, or change leads required by the approved plan. The forecast should therefore distinguish current capacity from the capacity expected after hiring, attrition, internal transfer, leave, and contract end dates.
Current capacity. Which roles, skills, teams, locations, and contract types are available now?
Expected changes. Which hires, departures, transfers, leave periods, and contract end dates will change availability?
Future demand. Which in-flight, approved, and proposed commitments require capacity in each period?
Estimate confidence. Which assumptions are confirmed, probable, or still provisional?
Required decision. Does the portfolio need to hire, source externally, reskill, change timing, or change priority?
Skills-based planning requires a controlled taxonomy. A long list of self-declared skills will not support a portfolio decision. The taxonomy should distinguish the capabilities that materially affect staffing, hiring, sourcing, or timing.
Workforce capacity planning and portfolio capacity planning should share assumptions but serve different horizons. Workforce planning considers longer-term headcount, skills, organization design, location, succession, and cost. Portfolio planning considers whether current and proposed work fits the capacity available within the investment and delivery horizon.
How do you balance demand and capacity?
When planned work exceeds available capacity, the choices are to change scope, change the sequence, move people or teams, add capacity, or stop lower-priority work.
Change the sequence. Protects scope but changes timing and may move expected value.
Reduce scope. Protects timing or capacity but changes the approved outcome.
Reassign a team or specialist. Protects one commitment by reducing capacity elsewhere.
Hire additional people. Requires recruitment lead time, onboarding, and approved cost.
Add supplier capacity. Changes run-rate, contract exposure, and knowledge retention.
Change the delivery model. May change team structure, governance, estimates, and financial treatment.
Pause or stop lower-priority work. Releases capacity and requires an explicit investment decision.
Accept the constraint. Makes the later date, higher risk, or reduced confidence part of the approved plan.
Scenario planning allows leadership to compare these choices before changing the plan. The current approved portfolio provides the reference case. Alternatives can test a delayed initiative, added supplier capacity, a tighter funding limit, or a different sequence of work.
Each scenario needs visible assumptions. A result without the underlying rates, dates, demand estimates, and capacity rules cannot be reviewed or repeated.
Prioritization and capacity planning belong in the same decision. Ranking initiatives without testing capacity produces an ordered list, not a deliverable portfolio. Capacity planning without prioritization may preserve work that no longer warrants the people or teams it consumes.
Capacity planning and financial planning
Capacity planning connects to finance by linking people, teams, and supplier capacity to the cost of the work they support. Budget and capacity remain separate constraints: an initiative can have approved funding and still lack the people or skills required to deliver it.
Capacity assumptions should connect to FTE rates, supplier rates, cost centers, project codes, product funding, capex and opex treatment, and forecast run-rate. The level of detail should match the financial decision being made.
This matters during business-case review. A plan that assumes immediate access to scarce specialists may understate cost or overstate timing confidence. A plan based on average role rates may hide the contractor premium required to meet the proposed date.
Project and product models may account for cost differently. A project may capitalize eligible effort against a defined scope. A stable product team may operate as a fixed cost across a continuing backlog. The portfolio still needs to reconcile both models when leadership reviews total investment and available capacity.
The PMO and finance function should use common rates, planning periods, and effective dates. Actual cost and effort should feed back into the forecast at the level used for governance.
How often should capacity plans be reviewed?
Capacity plans should be reviewed whenever a material change affects the work or the capacity available to deliver it. Strategic decisions may sit in annual or quarterly planning, while delivery changes, vacancies, or revised initiative dates may require monthly review.
Annual planning
Inputs. Portfolio ambition, operating plan, workforce outlook, and major supplier commitments.
Decisions. Broad capacity envelope, strategic hiring, and major sequencing choices.
Quarterly or PI planning
Inputs. Approved work, team capacity, dependencies, and current forecasts.
Decisions. Initiative sequence, team commitments, supplier changes, and recruitment priorities.
Monthly MBR or portfolio review
Inputs. RAG, milestones, run-rate, actual effort, vacancies, and material changes.
Decisions. Reforecasting, intervention, reallocation, escalation, and stop recommendations.
Current delivery updates
Inputs. Jira, Azure DevOps, schedules, timesheets, and service data.
Decisions. Progress, throughput, emerging constraints, and evidence for the next governance review.
Current delivery data does not replace governance. It reduces the delay between a change in delivery and its appearance in the portfolio view. Decisions to move funding, reassign capacity, or change an approved commitment still belong to the accountable forum.
The PMO should define materiality thresholds. A movement within an agreed tolerance may remain with the delivery owner. A change that affects a regulatory date, business-case outcome, supplier commitment, or major milestone should return to steerco.
Common resource and capacity planning challenges
The most common capacity planning challenges come from inconsistent assumptions, incomplete demand, duplicated commitments, and excessive planning detail. The problem is rarely the absence of a formula.
Common challenge
What it causes
Better approach
Run activity sits outside the plan
Change capacity is overstated
Reserve run capacity before allocating initiatives
Vacancies count as current capacity
Work is planned against people who have not started
Separate approved roles, recruited roles, and productive capacity
Early ideas are treated as firm commitments
Future demand appears more certain than it is
Record the maturity and confidence of each estimate
Shared specialists are planned separately by each initiative
The same capacity is committed several times
Maintain one portfolio view of shared roles and skills
Individual detail extends too far into the future
The plan requires constant maintenance without improving decisions
Plan at role, skill, or team level until named assignment matters
Stable teams are divided across several percentage plans
Team commitments become less reliable
Plan the team as a unit and limit partial assignment
Finance and delivery use different rates or dates
Cost and capacity forecasts describe different plans
Govern common assumptions and effective dates
Skills data is too broad or out of date
Available headcount is mistaken for suitable capacity
Maintain a skills taxonomy tied to real staffing decisions
The plan updates only before steerco
Governance becomes a reconciliation exercise
Bring current delivery, workforce, and financial information into the portfolio view
No forum owns the required decision
An acknowledged constraint remains unresolved
Assign the decision to a named forum and accountable owner
The level of control should match the importance of the decision. A portfolio does not need daily named-resource accuracy for work two years away. It does need a credible view of whether scarce skills, supplier limits, or fixed team capacity make the current plan undeliverable.
How portfolio management software should support capacity planning
Enterprise capacity planning works best as a capability of the portfolio management platform, not a standalone tool. It needs to connect demand, available capacity, planning levels, financial assumptions, delivery information, scenarios, permissions, and governance reporting in the place the portfolio is already governed.
Spreadsheets can establish an initial model, but they become difficult to govern when demand, availability, rates, delivery status, and scenarios change across several portfolios and systems. Standalone resource management tools center on people, skills, calendars, assignments, timesheets, and utilization. Capacity planning at portfolio level needs the longer-horizon demand, constraints, and scenarios that sit alongside funding, delivery, and governance in a portfolio management platform, delivered as a resource and capacity planning capability rather than a separate system.
Demand hierarchy. Connect ideas, initiatives, projects, products, programs, and run activity without reducing them to one work type.
Multiple planning levels. Plan by individual, role, skill, team, function, value stream, and supplier where each level is required.
Multiple delivery models. Support project allocations and stable-team capacity within the same portfolio.
Time-phased planning. Show demand and available capacity by sprint, PI, month, quarter, year, or another governed period.
Scenario planning. Compare different sequences, staffing choices, supplier options, and funding constraints before approval.
Skills and role management. Maintain a controlled taxonomy, availability, rates, and organizational ownership.
Financial connection. Connect capacity to rates, budgets, forecasts, actuals, capex and opex treatment, and run-rate.
Delivery-system connection. Bring current information from Jira, Azure DevOps, schedules, service systems, and other team-of-record tools.
Workforce and supplier data. Reflect headcount, vacancies, start dates, contract dates, absence, location, and external capacity.
Forecast and actual comparison. Compare planned effort and cost with actual delivery information at the agreed level.
Permissions and audit. Control who can change demand, capacity, rates, allocations, scenarios, and approved plans.
Governance reporting. Present constraints, assumptions, decisions, and actions in the format used by MBR, steerco, and investment committee forums.
Software should reduce reconciliation and preserve decision history. It should not force the organization into a planning level or delivery model that does not match how work is funded and delivered.
Resource and capacity planning FAQs
What is resource capacity planning?
Resource capacity planning determines how much work available people, teams, and skills can credibly deliver over a defined period. In enterprise portfolios, the calculation usually needs to show capacity by role, skill, team, function, or supplier rather than rely on a single headcount total.
What is project capacity planning?
Project capacity planning tests whether a project or project portfolio has enough people, roles, skills, and external capacity in each planning period. It also exposes conflicts between projects and shows where timing, scope, or staffing must change.
What is demand and capacity planning?
Demand and capacity planning compares the work an organization expects to deliver with the capacity available to perform it. A credible plan distinguishes committed work from less-certain proposals and shows which people, teams, or skills are constrained.
What is workforce capacity planning?
Workforce capacity planning forecasts the headcount, skills, locations, contract types, and cost required by the operating plan. It usually works across a longer horizon than project or portfolio allocation decisions.
What is the difference between allocation and utilization?
Allocation records the capacity assigned to work. Utilization records how capacity was used during a past or current period. A person or team can be fully allocated and still record lower utilization when work is blocked or delayed.
What should portfolio management software include for capacity planning?
For capacity planning, portfolio management software should cover time-phased demand and availability, planning by person, role, skill, and team, scenario modeling, financial rates, several delivery models, delivery-system connections, permissions, and an audit trail for approved changes.
Connect portfolio commitments to the capacity required for delivery
Portfolio leaders get a real-time view of capacity by team, skill, and individual. Plan delivery against the people you actually have, surface gaps before they bite, and stop the conversations where commitments outrun the capacity to deliver them.
InsightsEnterprise Portfolio Management Trends: 2026 So FarAI dominated the conversation around enterprise portfolio management in the first half of 2026. But beneath the agentic fanfare, self-driving portfolios, synthetic PMOs, copilot-everything and the apparently imminent extinction of…
AIFrom Plausible Risk Logs to Portfolio Assurance. What we learned building AI risk review for SPM teamsSPM teams don't need another way to fill a risk log. They need a better way to decide which risks deserve attention. What we learned building AI risk review.
AIAgentic Project Management: How AI agents are changing portfolio delivery without removing human accountabilityMost AI in portfolio management is still reactive: it answers when asked. Agentic Project Management is what acting on its own looks like, and what that shift means for cost per benefit dollar.
AIAI for the PMO: 8 Use Cases Transforming Portfolio ManagementAs portfolios scale, the PMO's administrative load expands with them. Eight use cases where AI shifts capacity from maintaining visibility to interpreting it.
knowledgeArchitecting Jira for large organizationsJira's flexibility is also its risk. At scale, it tips into chaos without deliberate structure. How to architect Jira for consistency and data quality without crushing agility.
