Resource planning in project management compares time-phased demand for skills and roles with realistic available capacity, then makes trade-offs visible. It is not a promise that every person's future hours can be predicted precisely.
Start with constrained roles, separate committed work from scenarios, and show uncertainty. A simpler model that supports priority decisions is more useful than a detailed schedule nobody maintains.
Define the decision before the model
Decide whether the organisation needs to accept new work, sequence projects, protect a specialist bottleneck, balance teams or forecast hiring and supplier demand. Each decision requires a different horizon and precision.
Do not collect detailed estimates simply because software can display them. Ask what action changes when demand exceeds capacity.
Build capacity from usable time
Begin with working time, then subtract leave, support, administration, training and realistic operational commitments. Apply availability by period and role. A nominal 40-hour week is not 40 project hours.
Keep skill and location constraints where they affect assignment. Avoid reducing people to interchangeable units when certification, domain knowledge or continuity matters.
Express demand at the right level
Near-term committed work may need named assignments and weekly estimates. Later work can use role ranges, confidence and earliest/latest periods. Match detail to decision distance.
Separate approved baseline, likely pipeline and option scenarios. Combining them produces an alarming utilisation number that nobody can interpret.
Work a simple example
| Week | Analyst capacity | Committed demand | Likely demand | Decision |
|---|---|---|---|---|
| 1 | 120 h | 100 h | 20 h | accept with no contingency |
| 2 | 104 h | 112 h | 24 h | move scope or secure cover |
| 3 | 112 h | 88 h | 40 h | reserve capacity pending decision |
| 4 | 120 h | 96 h | 16 h | retain buffer |
The model does not decide automatically. It exposes the week-two conflict early enough for an accountable trade-off.
Model uncertainty honestly
Use ranges or confidence for estimates and start dates. Test an optimistic, expected and constrained scenario. Keep contingency visible rather than distributing it invisibly across every task.
Review forecast accuracy by horizon. If four-month allocations change weekly, use that horizon for directional capacity, not personal commitments.
Identify the real constraint
Overall capacity can look healthy while one architect, reviewer, environment or external approval blocks several projects. Segment demand by the resource that changes the decision.
Protect bottlenecks from excessive context switching. Finishing fewer streams may create more throughput than allocating every hour across many projects.
Connect priority to allocation
Resource planning becomes political when priority rules are implicit. Define who can commit capacity, which work is mandatory, how value and urgency are compared, and how displaced work is communicated.
Do not allow a project to appear staffed merely because tentative names were entered. Distinguish requested, reserved and confirmed allocation.
Keep individual use responsible
Use capacity planning to protect sustainable workload and deliver commitments, not to monitor every minute. Discuss skills, development, concentration and leave with appropriate privacy.
Utilisation near 100 percent leaves no room for incidents, learning or estimation error. Set buffers according to variability and service responsibilities.
Review through an operating cadence
Teams can review near-term assignments weekly and portfolio capacity monthly or when material demand changes. Resolve exceptions, update assumptions and retain the decision.
Useful measures include demand beyond confirmed capacity, allocation changes after commitment, bottleneck queue, forecast error and work delayed by resource conflict.
Run a portfolio trade-off scenario
Suppose three projects require the same analyst during week two and only 104 usable hours exist. Project A has a regulatory date, Project B protects a customer commitment, and Project C offers optional improvement. The model should show demand by role and period, but governance decides whether to delay scope, add approved capacity or accept risk.
Record the option, affected milestones, cost, confidence and decision owner. Then update the baseline so teams do not continue working to a superseded promise. This decision record is the practical output of resource planning.
Connect plans without creating double entry
Define where project demand originates and where capacity, leave and actual feedback are maintained. Test how changes flow and how failed synchronisation is detected. If managers must update the same allocation in several systems, the apparent portfolio view will age quickly.
Choose the minimum integration needed for the decision. A monthly role forecast may not require task-level synchronisation; a daily service bottleneck may. Reconcile totals and sample named assignments after every material interface change.
Recognise planning anti-patterns
- assigning names to work that has not been approved;
- using one utilisation target for every role;
- treating estimates as commitments without confidence;
- optimising each person while projects wait between specialists;
- hiding operational support and leave outside capacity;
- changing priorities without updating displaced commitments.
Each anti-pattern makes the chart appear more complete while weakening the decision it is supposed to support.
Choose software after the method works
Test calendars, roles, skills, scenarios, requested versus confirmed allocation, actual feedback and integration with project demand. Verify who maintains each input and how stale data is signalled.
A resource-planning product adds value when it shortens and improves trade-off decisions. It fails when precision hides uncertain demand or when managers continue making commitments outside the model.