SOMA

Glossary

Resource Levelling vs Resource Smoothing

Resource levelling adjusts the schedule to stay within resource limits, potentially extending the project; resource smoothing adjusts resource use without extending the project end date.

Maintained by Adam O’NeillDirector, QRA SpecialistLast reviewed

Quick comparison — resource levelling vs resource smoothing.

Resource levellingResource smoothing
Binding constraintResource availability (you can't exceed the resource ceiling)Project end date (completion date is fixed)
Effect on end dateCan extend the schedule — activities are delayed until resource is availableEnd date preserved — over-allocations are accepted or smoothed within float
Effect on critical pathCan change the critical path — float-bearing activities may become critical after delayCritical path preserved — only non-critical activities are moved within their float
When to useReal, hard resource limits (e.g. 4 concrete gangs, 1 specialist welder, 2 tower cranes)Contractual / committed completion date with no flex; over-allocation is acceptable or can be hired
RiskFloat erosion → near-critical paths may become critical; commercial implications under NEC4Peaks that can't be smoothed remain — work overload, missed dates, or last-minute hire
Tool supportNative in P6, MS Project, Asta. Auto-leveller produces algorithmically correct but often awkward sequences — manual review essentialSame tools support smoothing modes; algorithms similar limitations
Reporting impactRe-baseline often required after levelling; EVMS resetBaseline preserved; EVMS unaffected

Both resource levelling and resource smoothing are techniques for resolving resource conflicts in a schedule — situations where more resources are needed in a period than are available. The difference is the constraint. Resource levelling treats resource availability as the binding constraint: if you only have four concrete gangs, the schedule is extended until all concrete activities can be scheduled within that limit. The end date moves. Resource smoothing treats the end date as the binding constraint: resources are redistributed within the available float of non-critical activities to reduce peaks, but the project completion date does not change. If there is not enough float to eliminate all peaks, some over-allocation will remain.

In practice, resource levelling is the more common operation because most real projects have genuine resource constraints that cannot be ignored. However, levelled schedules can look very different from the unlevelled version: activities that had float before levelling may now be critical because their start dates have been delayed to wait for resources. This has important implications for EVM, float reporting, and commercial risk — particularly on NEC contracts where the Accepted Programme and the compensation event mechanism depend on understanding the critical path.

Resource smoothing is the right approach when the end date is fixed and contractually binding. In this scenario, the planner identifies activities with float, redistributes their resource demand to periods of lower overall loading, and accepts that any peak that cannot be smoothed will require either acceptance of the over-allocation or a commercial decision to hire additional resource. The practical limitation of both techniques is that scheduling tools often perform levelling and smoothing with algorithms that produce technically correct but practically odd results — splitting activities, creating awkward resource profiles, or resequencing work in ways that do not reflect how the team would actually manage it. Manual judgement is nearly always required alongside any automated levelling run.

Used in practice

Need this on a live programme?

SOMA delivers this on live UK programmes — and trains teams in it. Where it fits:

Frequently asked

What is the difference between resource levelling and resource smoothing?
Resource levelling treats resource availability as the binding constraint and extends the project end date if needed to stay within those limits — schedule logic gets reworked around the resource ceiling. Resource smoothing treats the end date as fixed and only redistributes resources within the available float on non-critical activities, accepting any over-allocation that can't be smoothed. Levelling moves the end date; smoothing protects the end date.
When should I use resource levelling vs resource smoothing?
Use resource levelling when resource limits are real and binding — you genuinely cannot exceed them (e.g. only four concrete gangs available, only one specialist welder). Accept that the end date may move. Use resource smoothing when the end date is contractually fixed and the priority is to flatten resource peaks within float without slipping completion. Smoothing is suitable when peaks are caused by scheduling clustering rather than absolute resource scarcity.
Does resource smoothing change the critical path?
Not directly — smoothing only moves activities within their existing float, so the critical path is preserved. But it does consume float on non-critical activities, which makes them more vulnerable to subsequent delays. After smoothing, run a fresh DCMA-style schedule health check; activities that previously had healthy float may now be near-critical.
Why do levelled schedules look so different from the unlevelled version?
Resource levelling moves activities until they fit within available resource — which can delay activities that previously had float, making them critical. The shape of the critical path can change entirely after levelling. This has implications for EVM, float reporting, and NEC compensation event analysis. Always compare the unlevelled and levelled versions side-by-side, and document why each levelling decision was made.

Putting these techniques into practice?

SOMA provides independent project controls consultancy for UK programmes. We can help you apply QRA, EVM, schedule risk analysis, and more.