Resource Levelling vs Resource Smoothing
A schedule is built activity by activity, each duration sensible on its own, and then somebody adds up what it asks for in week nineteen and finds it needs four structural engineers where the organisation has two. Nothing in the plan is wrong. The demand profile simply exceeds the supply, which is the normal condition of any plan built without looking sideways.
Levelling and smoothing are the two techniques for reshaping that profile, and they are separated by one question: are you willing to move the end date? Both techniques belong to the resource work the PMBOK® Guide Eighth Edition collects at Section 2.6, and both are schedule actions taken for a resource reason, which is exactly what makes them easy to confuse with ordinary re-planning.
What each one moves
Levelling moves dates to fit the resources. Activities are delayed, extended or resequenced until demand fits within what is actually available, and the finish date moves out if it has to. The critical path frequently changes as a result, because the constraint is no longer the logic of the work; it is the availability of the people, and an activity with plenty of float can become the thing holding everything else up. Levelling is the honest technique when capacity is genuinely fixed, and the later date it produces is information, not failure.
Smoothing works inside the float and leaves the finish date alone. Activities with slack are shifted within it to take the top off the peaks, and anything on the critical path stays where it is. The result is a flatter profile and the same end date, and the cost is float, which was there to absorb problems and has now been spent on resource shaping. Smoothing reduces a peak; it cannot always remove one, and where the peak sits on the critical path it cannot touch it at all.
What the planning software cannot know
Both techniques are built into planning tools, and the automatic output is a starting point that needs reading. Three things the tool does not know decide whether its answer is usable.
Which activities can genuinely be split. Software will happily interrupt a five-day activity in the middle and resume it a fortnight later. Some work takes that well and some does not: a structural test that has to run to completion, a survey that needs the scaffold to still be standing, an inspection whose validity expires. Splitting rules have to be set deliberately, item by item, and the default is usually wrong.
Which people are actually interchangeable. A tool sees four people in a resource pool and treats them as four equal units. The project sees one person who has done this before and three who have not, and a level that depends on the wrong three being available produces a plan that is arithmetically correct and undeliverable.
Which dates are contractual. A finish date pushed out by a week is a schedule change in the tool and a liquidated damages conversation in the real project, and the tool has no way to tell the difference between a date that is merely desirable and one that carries a penalty. Any levelled output has to be read against the commitments before it is believed.
One instrumentation crew and two test articles
An aerospace programme was running structural testing on two fuselage sections in adjacent bays of the same hall. Each section needed a full instrumentation fit before test: strain gauges, wiring, calibration, about five weeks of work by a crew of six. The programme had one such crew.
The original schedule had both fits running in parallel, because each had been planned by its own test engineer against its own test date and neither had looked at the other. Twelve people were required in weeks eight to thirteen and six existed. The plan looked perfectly credible until somebody summed the demand across the two bays.
Smoothing was tried first, and it was the right thing to try. The second section's test date had about three weeks of float before it fed a wing integration milestone, so shifting the second fit later within that float removed part of the overlap. It removed two weeks of it. The remaining three weeks of double-crewing sat squarely on the critical path of the first test, and no amount of movement inside float would touch it.
The choice was then a real one, and it went to the programme board with the numbers attached. Levelling the second fit to follow the first pushed the wing integration milestone out by nineteen days. The alternative was to hire and qualify a second crew, which cost a six-figure sum and carried its own risk, because the qualification itself took eleven weeks and would not have been ready in time. The board levelled, moved the milestone, and told the customer in month four rather than month nine.
The part worth keeping is the sequence. Smoothing was attempted, it worked partially, and the residue was made visible as a decision for somebody with the authority to take it. What usually happens instead is that the double-crewed weeks stay in the plan, everybody privately knows they are undeliverable, and the date moves anyway in month nine with no options left.
Choosing, in practice
Where the date is genuinely fixed and float exists, smooth, and watch what the smoothing costs you in resilience. Where capacity is genuinely fixed and the date is negotiable, level, and present the new date early enough that somebody can decide whether to buy capacity instead. Where both are fixed, neither technique helps, and the honest move is to say so and put the choice in front of the person who owns both constraints.
The failure that sits underneath most of this is a plan that was never resource-loaded at all. Levelling and smoothing operate on a demand profile, and a schedule with no resources attached to its activities has no profile to operate on, which is why the problem surfaces as a surprise in week nineteen, when it could have been an analysis in week three.
For a PMP® candidate, the thing to carry is that both techniques reshape demand and neither creates capacity, so the question in any resource-constrained situation is which constraint the organisation is prepared to move. A response that levels without saying what happened to the date has hidden the decision rather than taken it. Situations where the schedule is sound and the people it assumes do not exist are worked through carefully in a structured PMP exam preparation course.
The diagnostic is quick. Take the busiest month in your current plan and count how many people each discipline needs in it, then compare that with how many exist. If nobody has done that arithmetic, the plan contains a peak that will be discovered by the people asked to work it, usually about a fortnight before it starts.
Interested in going further?
Both techniques are easy to define and easy to apply in the wrong order, and the cost of the wrong order is a date that moves too late for anybody to choose differently. Omega's PMP® Exam Preparation works through resource-constrained scheduling as a decision rather than a calculation.
Resource-constrained scheduling and the techniques around it are covered in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A142: The PMBOK 8 Resources Performance Domain: What It Really Covers
A144: Resource Planning in a World of Shared Teams
A147: Conflict Is Not Always a Problem
A151: Tailoring Resource Management for Agile and Hybrid Teams
A150: Motivation Is Not a One-Size-Fits-All Technique
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
