19.3 Categorising and Allocating Resources
Key Takeaways
- Resources are categorised as replenishable, such as people and equipment that become available again, or consumable, such as materials and funding that are used up.
- Linear schedules allocate resources to a defined activity network, so the question is whether the right resource is free when the activity needs it.
- Iterative schedules allocate a stable team capacity to a changing backlog, so the question is what the fixed capacity should work on next.
- Resource histograms plot demand over time against available supply, making overallocation visible before it becomes a delivery failure.
- Overallocation is a planning signal, not a personal performance issue — the plan is asking for more than the resource can supply.
Outcome 21c asks you to understand how resources are categorised and allocated to both linear and iterative life cycle schedules. The comparison is the examinable part: linear schedules allocate resources to a defined activity network, while iterative schedules allocate a stable team capacity to a changing backlog. Those are genuinely different planning problems.
From identification to allocation
Once resource need, availability, OBS, and RACI are understood, the project must allocate resources to scheduled activities and keep that allocation feasible over time. This section covers how resources are categorised and allocated in linear and iterative life cycle schedules, and the examinable distinction between resource smoothing and resource levelling (LO21c–d).
Weak answers use "smoothing" and "levelling" as synonyms. Strong answers state what is allowed to change, the effect on the end date and float, and when each technique is appropriate.
Categorising resources for allocation
Before loading a schedule, classify resources so the right constraints are applied.
| Category lens | Examples | Why categorise |
|---|---|---|
| Type | People, equipment, materials, facilities | Different booking and lead-time behaviours |
| Skill / grade | Senior designer vs junior draughtsperson | Prevent false fungibility |
| Internal vs external | Employees vs contractors vs supplier plant | Different acquisition routes and notice periods |
| Dedicated vs shared | Full-time project team vs BAU experts on call | Shared resources create multi-project conflict |
| Critical / scarce vs plentiful | Named specialist, unique test cell vs general admin support | Focus control on bottleneck resources |
| Consumable vs reusable | Materials used up vs equipment reused | Materials need replenishment; plant needs utilisation management |
| Cost behaviour | Fixed period cost vs variable day rate | Allocation choices affect budget profile |
Bottleneck resources deserve explicit calendars and early conflict resolution. Allocating plentiful admin support in fine detail while ignoring a single certified tester is reverse prioritisation.
Allocating resources to the schedule
Resource allocation assigns named or pooled resources to activities with quantities and time periods (for example 1.0 FTE test analyst in weeks 12–14; crawler crane 40 hours in week 9; training room booked 3 days).
Allocation steps (practical)
- Confirm activity list, durations, and logic (from schedule management).
- Attach resource demands to activities (skills, plant, materials, rooms).
- Apply calendars (working time, holidays, maintenance, BAU blackouts).
- Check aggregate demand vs supply by period.
- Resolve conflicts (smooth, level, add capacity, re-sequence, change scope).
- Baseline only when the resource-loaded plan is credible.
- Monitor actual use and re-allocate as forecasts change.
Allocation is not a one-off spreadsheet exercise. It is continuous control: actual progress, sick leave, supplier delays, and scope change all move the resource picture.
Allocation in linear life cycle schedules
In a linear (predictive/waterfall-style) life cycle, much of the scope and network is defined earlier. Resource allocation typically:
- Loads a fuller baseline schedule with resource demands across phases
- Seeks a stable profile for major packages before major delivery commitment
- Highlights peaks near design freezes, test phases, and cutover
- Integrates procurement lead times for materials and hired equipment on the same timeline
- Uses stage/gate reviews to confirm resource commitments for the next phase
| Linear allocation focus | Example |
|---|---|
| Early long-lead resources | Book specialist plant or scarce consultants months ahead |
| Phase-based peaks | Design team ramps then hands to construction/build team |
| Critical path resource risk | Ensure critical activities are not staffed by overallocated people |
| BAU windows | Align training and cutover with operational calendars |
Risk in linear plans: optimistic parallel activities that double-book the same people create a beautiful Gantt that cannot be staffed. Resource checking before baseline approval is part of integrated planning.
Allocation in iterative life cycle schedules
In iterative (and many agile or hybrid) approaches, detailed work is planned in timeboxes (sprints, increments) while a higher-level roadmap remains. Resource allocation typically:
- Fixes a stable team capacity (velocity-style throughput) for the near term
- Allocates people to backlog items selected for the iteration, not a 18-month task-level resource histogram for every story
- Re-plans allocation each iteration based on learning and remaining backlog
- Still manages shared specialists, environments, and BAU capacity as constraints across increments
- Maintains a release/roadmap resource view for scarce roles and external dependencies
| Iterative allocation focus | Example |
|---|---|
| Capacity-based planning | Team of 6 with known capacity chooses sprint scope that fits |
| Rolling wave detail | Next 2–4 weeks resource-loaded in detail; later increments lighter |
| Cross-team dependencies | Shared security reviewer booked across squads |
| Environment facilities | Test environments reserved per increment |
Important: iterative delivery does not remove resource management. It changes granularity and timing of detailed allocation. Roadmap-level resource risks (one performance tester for five squads) still need smoothing, levelling, or capacity decisions.
Hybrid note
Many projects combine linear stage structure with iterative build inside stages. Allocate stage-gate resources (assurance, procurement, training) on the linear backbone, and iteration capacity on the delivery teams.
Scenario A — linear vs iterative allocation failure modes
Linear failure: A construction fit-out baselines three parallel trade packages without checking that the same commissioning engineer is assigned 120% in week 22. Fix: re-sequence, extend duration, or add capacity before baseline.
Iterative failure: Five squads plan sprint demos the same week and all require the single UX researcher for validation. Fix: stagger sprint goals, increase UX capacity, or thin validation scope — capacity is the constraint, not story-point arithmetic alone.
Resource histograms and overallocation
A resource histogram (or load chart) shows demand per period for a resource or pool. Overallocation occurs when demand exceeds availability in a period.
| Signal | Meaning |
|---|---|
| Peak above availability line | Infeasible load without action |
| Sustained high utilisation | Fatigue, quality, and leave risk |
| Troughs next to peaks | Opportunity to shift work using float |
| Multiple projects on one person | Portfolio-level conflict beyond one PM’s chart |
When overallocation appears, two classic schedule techniques are smoothing and levelling. They are related but not the same.
How does resource allocation typically differ between linear and iterative life cycle schedules?