Resource Leveling

Definition

Resource Leveling is a scheduling technique that adjusts the start and finish dates of activities to keep resource demand within available capacity. The unlevelled schedule shows when work could happen if resources were unlimited; the levelled schedule shows when it will happen given the resources you actually have. The two often differ significantly, and the gap is the difference between optimistic planning and operational reality.

Closely related is resource smoothing, which adjusts activity timing within available float so as to flatten resource peaks without extending the project's end date. Leveling resolves over-allocations even if the end date moves; smoothing is the gentler variant that preserves the deadline.

History

Resource-constrained scheduling emerged alongside CPM in the late 1950s, but the algorithms (priority rules, branch-and-bound, genetic methods) were computationally demanding until desktop tools could run them efficiently in the 1990s. Today every serious scheduling tool — Primavera P6, Microsoft Project, Asta Powerproject, Spider, OnePager — implements resource leveling natively, although the practical use of the feature varies enormously by industry maturity.

Principles

• Resource availability is the binding constraint. Logic and durations are necessary but not sufficient; a network that ignores resources is a fantasy.
• Level within float first; extend duration only as last resort. Smoothing preserves the deadline; leveling moves it.
• Identify scarce resources explicitly. Tower cranes, niche specialists, qualified welders, senior software architects — these resources warrant explicit modelling. Generic labour can usually be aggregated.
• Priority rules drive outcomes. Which activity gets the resource when two demand it simultaneously — total float, late finish, criticality, contractual milestone — must be set deliberately.
• Re-level after every material change. A schedule that hasn't been re-levelled in three months is almost certainly mis-loaded.

Real-World Construction Example

On a high-rise residential project, the original schedule assumed three tower cranes operating concurrently. Site logistics and tie-back constraints actually allowed only two. The unlevelled schedule completed in 26 months; the resource-levelled schedule (with crane capacity as the binding constraint) completed in 31 months. The contractor's original bid had been based on the unlevelled view. The five-month gap, identified after award, was a USD 12 million exposure on indirect costs alone. The lessons-learned outcome was simple: resource-load and level the schedule before bid submission, not after award. The next project's tender schedule reflected genuine site constraints from the start and won on time, not on optimism.

Real-World IT / Agile Example

An enterprise platform team had four scrum squads and a backlog requiring six squads' worth of capacity. The product roadmap, drawn at face value, promised everything in two quarters. Resource leveling — in agile, called capacity planning — revealed the truth: at four squads, the same backlog needed three and a half quarters. The team negotiated either a six-month delay or a sixth squad. The result wasn't slower than the original plan; the original plan had always been impossible. The leveling exercise translated optimism into honesty.

Project Controls Perspective

Controls teams audit resource loading for three failure patterns: unmodelled scarcity (a critical-skill resource is implicit, not explicit, in the schedule); flat resource histograms that hide leveling (the schedule has been smoothed visually but not algorithmically, and over-allocations remain); and resource-dependent paths that are not critical paths (a path can be schedule-driving because of resource constraints even when CPM logic says it is not). The third pattern is the most subtle and most often missed. Mature controls add a resource criticality overlay to the standard critical-path view.

Common Mistakes

• Building schedules without resource loading, then adding it after the dates are committed.
• Treating leveling as an aesthetic exercise (flatten the histogram) rather than a constraint-resolution one.
• Using generic resource pools when scarce specialist resources are the actual constraint.
• Letting the leveling algorithm slip the critical path silently — the tool's default behaviour, often not what the planner intended.
• Not re-leveling after scope or productivity changes.
• Confusing leveling (resolves over-allocation, may move dates) with smoothing (preserves dates, within float only).
• Forgetting to level across sub-contractors who share constrained resources (lift crane, lay-down area).

Expert Tips

• Model only the scarce resources explicitly. Generic labour can aggregate; tower cranes, qualified welders, senior architects must be named.
• Run leveling and smoothing as separate passes. Smooth first within float; level second if over-allocations remain.
• Set priority rules deliberately and document them. The default rule is rarely the right one for your project.
• Inspect the resource-driven critical path alongside the logic-driven critical path. They often differ on busy projects.
• Re-level monthly and after every major scope change. A levelled schedule that hasn't been refreshed is fiction.

Key Takeaways

• Resource leveling resolves over-allocations; smoothing flattens demand within float.
• The unlevelled schedule shows when work could happen; the levelled schedule shows when it will.
• Level scarce resources explicitly; aggregate generic ones.
• Priority rules drive outcomes — set them deliberately.
• Resource-driven critical paths are real and often differ from logic-driven ones.

Related Concepts

Resource Leveling interlocks with CPM, Float Management, Baseline Schedule, Network Diagrams, and Cost Control. Resource-loading and leveling examples are at PMMilestone.org.