Resource Levelling
Last reviewed 9 September 20262,268 words10 min read
What P6's levelling button does, why you almost never press it on a contract programme, and the one way it is useful
🟩 In one line: Levelling delays activities until resources fit under a limit, with no logic, no record and no repeatability — so it never goes into a contractual update; run it in a Reflection to find the clashes, then fix them with SOFT-RES logic or zoning that a reviewer can read.
👤 Who this is for: Junior planners who found Tools → Level Resources; mid-level planners asked to "level the programme". Prerequisites: Resource-loading-and-histograms, Hard-logic-vs-soft-logic, P6-reflections-and-what-if.
First, let's be honest about why this page exists
Every few months a junior planner levels a live project, the completion date moves eleven weeks, half the constraints show as violated, and nobody can explain to the Engineer why activity 4,310 now starts in March. The levelled dates are not stored as logic; press F9 with levelling off and they vanish. Press it with levelling on and a different order of priorities gives a different answer.
Levelling has one honest use: as a diagnostic that tells you where the histogram breaks. The fix goes into the schedule as relationships, not as levelled dates.
🟨 The standard — what "good" looks like
| Source | What it says (paraphrased) | Use it for |
|---|---|---|
| PMI Practice Standard for Scheduling, 3rd ed. | Resource levelling extends dates to resolve over-allocation; resource smoothing works within float; both change the schedule and must be documented (check against your copy) | Vocabulary: levelling vs smoothing |
| GAO Schedule Assessment Guide, Best Practice 5 | Resource profile achievable; over-allocation resolved by sequencing or added resources, and the method documented | Why the resolution must be visible |
| DCMA 14-Point, items 1, 5 | Logic complete; hard constraints minimal — a levelled schedule with no logic explaining its dates fails the intent | Reviewer's view |
| AACE RP 38R-06 | Any levelling: resources limited, priority rules, and result recorded in the SBM | If you ever do submit one |
| NEC3 / NEC4 Cl 31.2 | Programme shows order, timing and resources for each operation | Order must be explicit — logic, not a levelling algorithm |
| Hub convention | Scheduling options: Level resources during scheduling unticked; levelling in Reflections only; clashes resolved as SOFT-RES relationships with Comments; recovery ramp check by histogram | Your defaults |
🟢 Rule: the schedule's dates come from logic and calendars only; if a resource limit changes the order of work, write that order into the logic and label it SOFT-RES.
How it actually works
What levelling does. Tools → Level Resources (check against your P6 version). For each levelled resource, P6 compares units/time demanded against Max Units/Time (or a Max Units limit set in the dialogue) and, in priority order, pushes activities later until the demand fits. Options that matter:
| Option | What it does | Use |
|---|---|---|
| Consider assignments in other projects with priority ≥ | Multi-project levelling | Off on a single project |
| Preserve scheduled early and late dates | Keeps the CPM early/late dates and stores levelled dates separately | On — always |
| Recalculate assignment costs after levelling | Cost follows levelled dates | On if cost loaded |
| Level all resources / selected resources | Which resources have limits | Selected — only the 3–6 genuinely constrained trades or cranes |
| Level resources only within activity Total Float | Smoothing: never delays the completion date; leaves the clash unresolved if float is insufficient | On for diagnostic |
| Preserve minimum float / max % over-allocation | Tolerances | 0 float, 0–10 % over-allocation |
| Leveling priorities | Tie-breaker order (e.g. Total Float ascending, then Early Start, then a Priority code) | State them; write them in the SBM |
| Log to file | Levelling log | On; archive |
Why it stays out of contractual updates.
| Problem | Consequence |
|---|---|
| No logic created | The reviewer cannot see why an activity moved; DCMA logic checks pass while the dates are inexplicable |
| Not repeatable | Change one priority tie-breaker and the dates change; two planners get two programmes |
| Float destroyed | Levelled dates make total float meaningless; float-ownership arguments collapse |
| Constraints violated silently | Levelling pushes past Finish On or Before dates and reports it in the log nobody reads |
| Recovery hides | If levelling is on, adding a crew changes dates through the algorithm, not through a documented lever |
| Baseline comparison impossible | Schedule Comparison against an un-levelled baseline shows thousands of date changes with no cause |
The one honest use — diagnostic in a Reflection.
| Step | Action |
|---|---|
| 1 | Reflection of the current schedule, named "Levelling check — Reflection of UpdNN DD" |
| 2 | Set Max Units on the 3–6 constrained resources (from the subcontractor's confirmed manpower, camp, crane hook-hours) |
| 3 | Level, selected resources, within Total Float first; read the log for activities that could not be resolved — those are the real clashes |
| 4 | Level again without the float restriction; note how far completion moves — that is the size of the resource problem |
| 5 | For each clash: decide the order (zone A before zone B; core wall rebar before slab rebar) and add an SS+lag or FS relationship labelled SOFT-RES in Comments with the resource named; or add resources and change the crew in the RD formula; or accept the date |
| 6 | Turn levelling off, reschedule with logic only, re-read the histogram; iterate until the peak fits |
| 7 | Schedule Comparison of the logic-only result against the source; changes listed as planner edits in the change table |
| 8 | Delete the Reflection; archive the levelling log, comparison and a one-line note in the SBM resource basis |
If the specification demands a levelled submission. Some client specs say "resource-levelled programme". Read it with the Engineer: almost always they mean a programme whose histogram is achievable, which logic delivers. If they truly mean levelled dates, submit both — the logic-driven programme as the programme, plus a levelled scenario named as such, with limits and priority rules in the SBM — and record that dates, float and delay analysis are read from the logic-driven one.
🟥 Where people go wrong
- Levelling the live project. Dates move without explanation, constraints are breached, and the last accepted update cannot be reproduced. Reflections only.
- "Level resources during scheduling" ticked. Every F9 re-levels, so no two reschedules agree and the settings screenshot in the SBM is contradicted. Untick; it is on the scheduling-options checklist for this reason.
- Levelling all resources. Two hundred resources with default Max Units of 8 h/d each produce a programme three years long. Only the genuinely constrained few, with real limits.
- Trusting levelled dates as a forecast. Levelled completion is one algorithm's answer to one priority order. The forecast is the logic-driven longest path, re-sequenced by hand where the diagnostic showed clashes.
- Fixing clashes with constraints. Start On on the second zone to keep the crew sequence. It hides the reason. An SS+lag SOFT-RES relationship says the same thing and can be read and tested.
- Not reading the levelling log. It lists the activities that could not be levelled within float and the constraints violated — the only useful output — and it goes unopened.
⚖️ When you're challenged
"The spec says resource-levelled. Why isn't the programme levelled?" It is resource-feasible: every trade sits under its confirmed manpower on the histogram, and the sequence that achieves that is written in the logic as labelled resource links you can trace. A programme with levelled dates and no logic can't be reviewed or analysed for delay, which is why I've submitted the levelled scenario alongside as a check, not as the programme.
"Just press level and tell me the real date." Levelling gives one date for one set of priorities; change the tie-breaker and it gives another. I've run it in a copy — it says the steel-fixers are the problem in March and the answer is about three weeks. I've put that sequence into the logic so the date is the same tomorrow and next month.
"Why did you add forty relationships this month?" They're resource links from the levelling check — steel-fixer and blockwork crew order across Levels 12–16, each labelled SOFT-RES with the trade named in the comment. Net effect on completion is zero; the change table lists them and the comparison report is attached.
📄 Related pages
- Resource Loading and Histograms — the histogram levelling reads and the peak/ramp/sawtooth checks
- Hard Logic vs Soft Logic — SOFT-RES classification and Comments
- Scheduling options — why "level during scheduling" is unticked
- P6 Reflections and What-If — where the diagnostic runs
- Site Logistics in the Schedule — crane hook-hours as the levelled resource
- Building a Recovery Plan — ramp check before issue; levers in order
✏️ Worked example — Ajman mid-rise, month 7 levelling check
Constrained resources: LAB-STF (Max 40), LAB-BLK (Max 90), EQ-TC1 (Max 8 hook-h/d). Reflection of Upd07.
| Run | Setting | Completion movement | Unresolved (log) |
|---|---|---|---|
| A | Within Total Float only | 0 d | 9 activities: STF L09–L11 rebar over by 12–18 for 3 weeks; TC1 over by 2.4 h/d in weeks 31–33 |
| B | Unrestricted | +16 working days | — |
Resolution in logic:
| Clash | Fix | Type | Comment text |
|---|---|---|---|
| L09 core rebar ‖ L09 slab rebar Zone A | STR-L09-COR-030 → STR-L09-SLB-REB-A SS+3 | SOFT-RES | "STF crew 40 shared; core first per MS rev 3" |
| L10 / L11 same | Same pattern, two links each | SOFT-RES | Same |
| TC1 weeks 31–33 | Blockwork material lifts moved to hoist H1 from L06 up; BLK activities re-assigned to hoist resource | Method | "Hoist H1 commissioned wk 30 (IF-018)" |
Logic-only reschedule: completion movement +4 working days (vs +16 levelled); STF peak 40; TC1 7.6 hook-h/d. Comparison report: 7 relationships added, 0 constraints, 4 days on the contractual milestone, tagged restraint — resource. Reflection deleted; log and comparison archived; SBM §7 note: "Levelling check month 7: STF and TC1 limits applied; resolved by 6 SOFT-RES links and hoist re-assignment; +4 d."
📖 References
- PMI, Practice Standard for Scheduling, 3rd ed. (check against your copy)
- GAO, Schedule Assessment Guide, GAO-16-89G, Best Practice 5
- DCMA 14-Point Schedule Assessment, items 1 and 5
- AACE International RP 38R-06, Documenting the Schedule Basis
- NEC3 / NEC4 ECC, Cl 31.2 (check the edition in your contract)
- Oracle Primavera P6 Professional User Guide — Level Resources; Leveling priorities; Scheduling options (check against your P6 version)
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about resource levelling. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.
Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.
Add your experience