19.4 Resource Smoothing and Resource Levelling

Outcome 21d is a single line — know the differences between resource smoothing and resource levelling — and it is one of the most reliably examined distinctions on the whole paper. Get the two directions the right way round and the marks follow; reverse them and every scenario answer built on them fails.

Resource smoothing vs resource levelling (high-yield distinction)

Both techniques address uneven or excessive resource demand. The critical differences are what may change and whether the project end date is protected.

Comparison table

UK spelling on the PMQ: expect levelling (double l). The concept matches "resource leveling" in some international texts.

Resource smoothing — deeper view

Resource smoothing reschedules work to reduce peaks while staying inside existing float so the imposed or baselined end date does not move. Non-critical activities may start later (or be paced differently) where total float allows. Critical activities are not delayed solely to smooth, because that would push the end date.

Use smoothing when:

• The deadline is fixed (contractual end date, regulatory date, market window)
• Histogram peaks are caused largely by discretionary parallel work on paths that have float
• Availability is roughly adequate in total but poorly timed
• You want more stable utilisation (cost, morale, plant hire efficiency) without renegotiating time

Limits of smoothing: if overallocation sits on the critical path, or total demand in a period still exceeds supply after all float is used, smoothing cannot solve the problem alone. You then need more resource, overtime, method change, scope cut, or levelling that accepts date movement.

Resource levelling — deeper view

Resource levelling prioritises resource feasibility. Activities are delayed, stretched, or re-sequenced so that demand does not exceed availability. If that requires delaying critical work, the project end date moves (unless compensated by other approved changes such as adding resources — which is a capacity decision, not pure levelling).

Use levelling when:

• Named resources or plant are hard-constrained and cannot be exceeded
• Smoothing within float is insufficient
• A realistic plan is more valuable than an optimistic date nobody can staff
• Sponsors will accept a later date (or must be shown the true trade-off)

After levelling: re-check critical path, cost (delay costs, extended hire), risk, and benefits timing. Levelling is a re-planning act that may need governance approval if baselines change.

Side-by-side worked numbers (conceptual)

A specialist is available 5 days/week. Week 10 demand is 8 days across Activity A (critical, 5 days) and Activity B (3 days float available on B’s path).

• Smoothing: move or pace Activity B within its float so week 10 demand becomes 5 days; end date unchanged if B still finishes inside float.
• If Activity B had no float and both must use the specialist, smoothing fails. Levelling delays B (or part of A if re-planned), and the end date may slip unless another specialist is added.

Other responses often used with smoothing/levelling

Smoothing and levelling are schedule-logic responses. Exam scenarios may also require capacity responses. Distinguish them clearly:

Do not call "hire two more testers" smoothing. Hiring is a resource acquisition decision. Smoothing and levelling rearrange when existing constrained resources do work (levelling may also stretch durations).

Scenarios for the distinction

Scenario B — smoothing succeeds

A software project must hit a fixed regulatory submission date. The test environment is overloaded in week 14 because three non-critical documentation and training-prep tasks were planned in parallel with critical test execution. The project manager smooths: shifts documentation tasks into weeks 12–13 and 15 where float exists, keeps critical testing in week 14, and holds the submission date. Histogram peaks fall; end date unchanged.

Scenario C — levelling required

The same project discovers the only performance tester is required full time on the critical test path and on a critical defect-fix path in the same week, with zero float on both. Smoothing cannot move either without breaking the end date logic. Options: level (accept slip on one path and thus likely the end date), add a second performance tester (cost), or descope performance scenarios (quality/risk). Presenting only "we will smooth" would be incorrect because no float remains.

Scenario D — iterative capacity levelling

An agile programme’s roadmap promised three features in Release 2, but the single data-migration specialist is already fully allocated to Release 1 hypercare. The release train levels feature capacity: one feature moves to Release 3 (date of that feature slips), rather than pretending all three can be staffed. Iteration smoothing inside a sprint (reordering backlog items within sprint capacity) is the short-horizon cousin of the same idea — still limited by true capacity.

Scenario E — plant resource

A site has one mobile crane. Two lifts were scheduled the same morning. Smoothing moves the non-critical lift to the afternoon if the day still finishes inside float for that activity’s path. If both lifts sit on the critical path for a possession window that ends at noon, levelling (or adding a second crane) is required; wishful double-booking is not a plan.

Choosing the technique in exam answers

Use this decision pattern:

1. State the overallocation (which resource, which period).
2. Check float on the overloaded activities and whether the end date is fixed.
3. If peaks can be moved within float and the end date must hold → resource smoothing.
4. If demand still exceeds supply or critical work is overloaded → resource levelling and/or extra capacity / scope / method change; declare end-date impact.
5. Link to governance: baseline changes, sponsor options, cost and benefits effects.
6. Mention life cycle: linear full-network histograms vs iterative capacity and rolling-wave allocation.

Memory contrast (one line each)

• Smoothing: "Use the slack; keep the deadline."
• Levelling: "Fit the people/plant; the deadline may move."

Integrated control reminders

Resource allocation sits inside the integrated project management plan:

• Schedule feasibility depends on resource-loaded reality, not logic alone.
• Cost baselines change if overtime, extra hire, or delay costs appear.
• Risk rises when utilisation is permanently near 100% (no contingency capacity).
• RACI Responsible parties must match the allocation — a Responsible person at 150% is a fiction.
• Reviews and assurance should test whether reported status assumes unavailable resources.

Mastering the smoothing vs levelling distinction, and applying it in linear and iterative contexts, is high-yield for APM PMQ resource management questions and long-response scenarios.