Resource levelling and schedule quality: what happens to your critical path
Every structural check in common use — the DCMA 14 included — assesses a network as if labour, plant and supervision were infinite. They are not, and the moment you introduce the constraint that they are not, two things happen that most planners have never had explained to them: the critical path can move to a place the logic does not explain, and total float stops meaning what it meant an hour earlier.
Three different things, one careless word
"Resourced" is used to mean at least three distinct states, and conversations go wrong immediately when the parties mean different ones.
- Resource-loaded — activities carry resource or cost assignments. That is a data condition. It says nothing about feasibility; it means somebody typed quantities in.
- Resource-levelled — the schedule has been recalculated so that demand never exceeds availability. This is resource-limited scheduling, and the honest question it answers is: with the resources we have, when does the work finish? The end date is the output, and it usually moves.
- Resource-smoothed — demand has been flattened within the existing float so that peaks and troughs are reduced without moving the end date. This is time-limited scheduling. The APM's framing is the clearest in circulation: levelling gives priority to the resource constraint, smoothing gives priority to the time constraint.
The distinction is not academic. If a client asks for a "levelled programme" and receives a smoothed one, they have been given a plan that still assumes the peak is deliverable. If they ask for smoothing and receive levelling, the completion date has moved and nobody has said so.
Why structural checks are silent here
The DCMA 14-point assessment has a resources check, and it is worth understanding precisely how thin it is: it asks whether incomplete activities carry a resource or cost value. It cannot tell you whether the resource exists, whether the same eight-person crew is committed to five concurrent activities in week 34, or whether the peak demand is three times anything the contractor has ever mobilised.
The GAO Schedule Assessment Guide takes resources considerably more seriously. Assigning resources to all activities is its third best practice, sitting under the comprehensive characteristic, and the purpose is explicitly feasibility — a schedule that assumes resources the programme will not have is not a schedule. This is one of the three gaps that no file-level structural test can close, and it is the largest of them.
PMI's Practice Standard for Scheduling treats resources as a first-class component of the schedule model for the same reason. The model is not just activities and logic; the resource dimension is part of what makes it a model of anything.
What levelling actually does — and the part nobody mentions
Here is the mechanism, because everything awkward follows from it.
When the scheduling engine levels, it identifies periods where demand for a resource exceeds its availability, and it delays activities until the conflict clears. It chooses which activity to delay using leveling priorities — total float first in most default configurations, then whatever tiebreakers are configured.
It does not add a relationship. The delay is the product of a calculation performed at schedule time; it is not stored in the network as logic. Open the levelled file, look at activity B, and its predecessors are exactly what they were before. Its dates have moved and there is nothing in the logic that explains why.
The float problem
This is the consequence that catches experienced people out.
Total float is a CPM quantity. It is computed from the logic — the difference between the late and early dates that the forward and backward passes produce. Levelling delays activities after that computation, without changing the logic that produced it. So you can finish with an activity that has been pushed four weeks by resource contention and still reports positive total float, because the network still believes it could start earlier. It could — if the crew were free, which it is not.
The practical effects are worth stating plainly:
- Float overstates flexibility. An activity showing 15 days of float may have none at all in practice, because the resource is committed elsewhere for those 15 days.
- The driving path may not be the resource-driving path. The chain that actually determines the finish date can be a chain of resource contention rather than a chain of logic — the insight that the critical chain literature was built on. Your CPM critical path will not show it.
- Delay analysis gets harder. If a levelled schedule is the baseline, an impacted-as-planned or time-impact exercise has to decide whether to re-level after inserting the delay event, and the two answers differ. This is not a settled question and it needs stating in the method, not discovering in cross-examination.
If float is already the number people misread most often — and it is — levelling takes the misunderstanding and makes it structural.
Levelling delays activities without adding logic, so total float survives untouched and quietly stops describing flexibility that exists.
The settings that change the answer
P6's Level Resources dialog carries several options that materially change what you get, and a submitted levelled programme should state which were used.
| Option | What it does | Why it matters |
|---|---|---|
| Preserve scheduled early and late dates | Holds the early and late date fields, forward-levelling only | Lets you see the effect of levelling against the unlevelled dates instead of overwriting them — the single most useful setting for a reviewer |
| Level resources only within activity total float | Restricts delay to available float | This is smoothing in all but name. The end date will not move — and the over-allocation may not be resolved |
| Leveling priorities | Decides which activity gets delayed when two compete | Different priority orders produce different completion dates from identical inputs. Priorities are an assumption, and should be declared |
| Consider assignments in other projects | Levels across a portfolio, not one file | Where shared crews and specialist plant actually live. Levelling a single project on a shared resource is close to meaningless |
| Max percent to over-allocate | Permits a defined breach of availability | A legitimate modelling of overtime — but it must be stated, because it is a cost commitment in disguise |
And, as with the scheduling options for progressed activities, the deeper governance point is the same: a submission that does not record its settings is not reproducible, and a result nobody can reproduce is not evidence.
Reviewing a resource-loaded schedule someone else built
Seven checks, in the order we run them. The first three take a minute and disqualify most files.
- Coverage. What proportion of non-LOE activities carry no resource assignment at all? On genuinely resource-loaded programmes it should be small and explicable. A file where 60% of activities are unresourced is cost-loaded, not resource-loaded.
- Is the dictionary real? Do the resources have availability limits set, or are they at default? Without limits, levelling has nothing to level against and the histogram has no ceiling to breach. This is astonishingly common.
- Duration type. Are durations driving units, or units driving durations? A fixed-duration-and-units activity behaves completely differently from fixed-units-per-time when progress is recorded, and a schedule that mixes them without intent will produce resource curves that nobody can explain.
- Peak versus plausible. Compare the peak of each key resource against what the contractor has actually mobilised on comparable work. This is a judgement, not a calculation, and it is where experience earns its keep.
- Curve shape. A credible histogram ramps, plateaus and demobilises. Vertical walls, single-period spikes, and a demand curve that stops dead at practical completion are all signs of resources spread mechanically rather than planned.
- Was it levelled? Re-run the schedule unlevelled on a copy and compare early dates. If nothing moves, it was not levelled — whatever the narrative says.
- Reconciliation. Do the resource curves reconcile with the cost S-curve and, if EVM is in use, with the performance measurement baseline? Two curves derived from the same plan that do not agree mean one of them was built separately, and neither can be trusted.
Levelling is one of three answers, and usually the worst one
When demand exceeds availability there are exactly three responses, and the software offers only one of them.
Add resource. Mobilise more, work longer hours, subcontract the peak. This has a cost, and modelling it honestly turns a schedule problem into a commercial decision — which is where it belongs.
Re-sequence. Change the plan so the peak does not arise: work areas in a different order, shift a package earlier into a trough, split a work front. This is the answer good planners reach for first, and it is the only one of the three that can improve the outcome rather than trading between axes.
Accept the delay. Level, and report the later date. Legitimate, often correct, and the only one that requires no thought — which is why it is the one most often taken.
A programme that has been levelled without any evidence that the first two were considered is not a plan; it is an acceptance of the first arithmetic the software offered. When we review a levelled submission the question we ask is not "is this levelled correctly?" but "what was tried before levelling?" — and the schedule basis document should answer it. That is precisely what a basis document is for.
What to report
Four sentences, and they are not about levelling algorithms:
- Whether the programme is loaded, levelled or smoothed — and whether the end date was an input or an output.
- The peak demand for each critical resource, against a stated availability, with the over-allocated periods identified.
- Whether total float can be relied on, and if not, which paths are resource-driven rather than logic-driven.
- What was tried before levelling, and what the alternatives would have cost.
None of that requires sophisticated tooling. All of it requires someone to have asked whether the plan can be executed by the people who will be executing it — which remains, after everything, the question that the whole apparatus of schedule quality exists to make answerable.
Sources & further reading
- Association for Project Management — Resource smoothing vs resource levelling, and the APM guide Planning, Scheduling, Monitoring and Control: The Practical Project Management of Time, Cost and Risk (Planning, Monitoring and Control SIG). The clearest published statement of the resource-limited versus time-limited distinction used throughout this article. apm.org.uk
- U.S. Government Accountability Office — Schedule Assessment Guide (GAO-16-89G), best practice 3, "Assigning resources to all activities". The requirement that resources be assigned so that feasibility can be assessed, under the comprehensive characteristic. gao.gov/products/gao-16-89g · our summary: the GAO ten best practices
- Project Management Institute — Practice Standard for Scheduling, Third Edition. Treats resources as a component of the schedule model rather than an optional overlay; aligned to the PMBOK Guide Seventh Edition. pmi.org
- Oracle — Primavera P6 Professional User Guide, "Leveling resources". The authoritative description of the levelling options discussed above, including preserving scheduled early and late dates and levelling within activity total float. docs.oracle.com — Leveling resources
- Ron Winter, PSP — Reviewing Resource Leveled Schedules Using P6. A practitioner treatment of the review problem this article describes: why levelling delay is invisible in the logic and what to look at instead. ronwinterconsulting.com
Key takeaways
- Loaded, levelled and smoothed are three different states. Levelling is resource-limited — the date is an output. Smoothing is time-limited — the date is an input.
- The DCMA resources check tests presence, never feasibility. GAO best practice 3 is the standard that actually asks whether the plan can be executed.
- Levelling delays activities without adding logic, so total float survives the process unchanged and quietly stops describing real flexibility.
- The chain that drives the finish date on a levelled programme may be a chain of resource contention, not logic — and no CPM view will show it.
- Levelling settings — preserved dates, levelling within float, priorities, cross-project assignments — change the answer and belong in the submission.
- Levelling is the third-best response to over-allocation. Ask what was tried before it, and expect the schedule basis document to say.
On your own schedule: see the resource histogram, heatmap and demand curve — alongside the structural score, parsed in your browser with nothing uploaded.
See the demand curve behind the bars
Resource histograms, period heatmaps and S-curves generated straight from the file, next to the quality score and the driving path — so feasibility and structure are read together instead of separately.