Skip to content

Resource Plan

At a glance

  • Purpose: Show who is available, when, at what level, and where the demand exceeds the supply — before the schedule assumes resources that do not exist.
  • Use it when: When estimating effort and again when levelling the schedule. It is the input to resource conflict resolution, not an output of it.
  • Owner: The project manager with the resource managers or team leads who actually release people.
  • Related: Module 10 · Lab 13 · Lab 21
  • Spreadsheet version: csv/resource-plan.csv

How to use this template

  1. List skills, not names, in the demand rows. "Backend developer" survives staff changes; "Sarah" does not.
  2. Convert availability to person-days per period, and apply the availability factor honesty demands — a person is not 100% available to your project.
  3. Compare demand against capacity per skill and per period. Aggregating across the project hides the two weeks where everything collides.
  4. Resolve over-allocation in this order: resequence using float, then substitute skills, then reduce scope, then negotiate more capacity. Crashing is last because it costs most.
  5. Record every over-allocation you did not resolve. An unresolved conflict is a risk with a known trigger, and it belongs in the risk register.

Field descriptions

Column What goes in it Watch out for
Skill / role The capability required Named individuals
Person Who currently fills it (optional) Treating this column as fixed
Availability factor The proportion of paid time actually available Assuming 100%
Capacity (person-days) Headcount × working days × availability factor Using calendar days
Demand (person-days) From the estimates, per period Estimates with no stated basis or range
Balance Capacity − demand Balancing total capacity against total demand only
Action Resequence / substitute / reduce scope / negotiate Marking over-allocation "under review" indefinitely
Owner and date Who resolves it, by when Actions with no date

Blank template

# Resource Plan — [Project name]

| | |
| --- | --- |
| **Version** | [1.0] |
| **Period covered** | [Week 1 to week 16] |
| **Working pattern** | [5 days per week, minus 2 public holidays] |
| **Availability factor** | [e.g. 0.8 — the remaining 20% covers leave, support, meetings] |

## 1. Capacity

| Skill / role | People | Person-days available | Notes |
| --- | --- | --- | --- |
| [Skill] | [n] | [n] | [Ramp-up, part-time, shared with support] |
| **Total** | | | |

## 2. Demand by period

| Skill / role | W1–2 | W3–4 | W5–6 | W7–8 | W9–10 | W11–12 | W13–14 | W15–16 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [Skill] | [n] | | | | | | | |

## 3. Balance and actions

| Skill / role | Period | Capacity | Demand | Balance | Action | Owner | By when |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [Skill] | [W5–6] | [n] | [n] | [−n] | [Resequence using float] | [Role] | [Date] |

## 4. Unresolved conflicts

| Skill / role | Period | Shortfall | Why it is unresolved | Risk it creates | Risk register ref |
| --- | --- | --- | --- | --- | --- |

## 5. Assumptions

[Availability factors used, shared-resource agreements, onboarding lead time for anyone not yet
available, and what happens if a named person leaves.]

Worked example

From Lab 21, on the hospital appointment portal — invented figures for teaching. Four people over a six-week period, 5-day weeks, availability factor 0.8:

Skill / role Capacity over 6 weeks Demand Balance Action
Backend developer 2 × 30 × 0.8 = 48 pd 42 pd +6 pd None
Frontend developer 1 × 30 × 0.8 = 24 pd 30 pd −6 pd Resequence: move two non-critical screens after the security review
Tester 1 × 30 × 0.8 = 24 pd 30 pd −6 pd Substitute: developer runs the automated regression suite; tester reviews results
DBA (shared, 0.2 available) 0.2 × 30 = 6 pd 9 pd −3 pd Negotiate: book the DBA's time in the design week only

Two things this table shows that a total-capacity check would not:

  • Totals can balance while every period fails. Total demand here is 111 person-days against 102 available — a 9-day shortfall overall. But the frontend and DBA shortfalls land in the same two weeks, so the project is 11 days short exactly when it matters and has 6 idle backend days it cannot use. That is the difference between a capacity problem and a scheduling problem.
  • The DBA is shared at 20%. That number is an agreement with another manager, not a fact about the person. If it changes, the design week slips, and the design week is on the critical path.

Common mistakes

  • Assuming 100% availability. A 0.8 factor is realistic; 1.0 is a planning error that surfaces as unexplained slippage.
  • Balancing only totals. This is the single most common resource-planning mistake and the one Lab 21 is built around.
  • Planning by name. "Only Ahmed can do this" is a risk, not a plan, unless it is written down as one.
  • Ignoring ramp-up. A new joiner contributes nothing in week one and little in week two.
  • Treating a shared resource as yours. The 20% you were promised is the first thing released when the other project has an incident.
  • Resolving conflicts by optimism. Spreadsheets do not level resources; someone has to resequence work, and that decision belongs in the plan.