Resource Leveling Techniques, and Why Yours Guesses

Search for resource leveling techniques and you get lists: level within float, delay non-critical tasks, split tasks, reassign resources, adjust the calendar, fast track, add people. All real things you can do. None of them is what the button in your scheduling software is actually doing when you press it, and the gap between the list and the button is why two tools level the same plan and hand you two different schedules.

Underneath, there is one technique with two moving parts, and a lot of arbitrary choice in the second part. Here is what it did to a 21-task renovation.

The one technique the lists are describing

Nearly every commercial leveller is a priority rule applied inside a scheduling scheme. Two parts:

• The scheme is the loop. A serial scheme takes the tasks one at a time in priority order and places each at the earliest day its predecessors are done and the people are free. A parallel scheme walks the calendar day by day instead, and at each day starts as many of the eligible tasks as the crew allows, breaking ties by priority.
• The rule is the ordering. Minimum total float first. Or latest finish time. Or longest duration first, shortest duration first, greatest resource demand, greatest number of successors, earliest start, or random.

That is the technique. “Level within float” and “delay non-critical tasks” are descriptions of what minimum-float-first tends to produce, not instructions the software follows. And the choice of rule is not a detail — it is the whole answer. There are well over a hundred rules in the literature, most tools use two or three, and which combination yours uses is generally not documented and not adjustable.

Which is why the same plan gets different answers

Harvey Levine ran precisely this experiment for PM Network in 1994, in a piece he called Resource Leveling and Roulette. He put one project through thirteen software products and got a spread of finish dates back — thirteen of the runs landing on one duration, nine on another, and so on. His conclusion about the ranking criteria has not aged a day: there is no way to tell in advance which one will produce the shorter or the smoother schedule, so you try them and compare. He also noted that vendors avoid genuine optimisation on purpose, because in 1994 it was too slow, and that the serial methods they used instead left resources idle in ways that added duration for no reason.

The computational half of that objection expired a long time ago. The behaviour did not. When seven packages were measured against provably optimal answers a few years later, the median schedule came back 3.6% above optimal, and every one of them got worse as the crews got tighter — worst exactly when you need it most.

What it actually did to this plan

Twenty-one tasks, three general crew, and a critical path that finishes 25 November while quietly asking for five people on its busiest day. Levelled into three crew, the finish is 2 December — five working days later, proved optimal.

Eleven tasks moved. The chart above ranks them, and the colouring is the interesting part. Driveway and landscaping each slid fourteen working days, which is more than the nine days of float either one had — possible only because the project end itself moved out five days, giving them nine plus five. Roofing had the same nine days of float and moved four. Exterior painting had fourteen days of float and moved four.

And five of the eleven — punch list, insulation, drywall, interior painting, flooring — had zero total float. They were on the critical path. They moved anyway, because the people were not free, and no amount of respecting float would have found this schedule.

This is the part that makes the “level within float” advice actively misleading if you take it as a method rather than a description. Try it by hand on a tight plan and you will run out of float long before you run out of overloaded days, conclude the schedule is impossible, and go ask for more people. The float is not where the answer is. Float measured on the network and room measured in a crew-constrained schedule are two different quantities that routinely disagree, and it is the second one that governs here.

The question techniques are supposed to answer, and mostly cannot

Nobody levels a schedule for fun. They do it because someone is about to ask whether hiring would help, and how much.

A priority-rule leveller can give you one row of that table per run, and only if you remember to change the resource sheet and press the button again. It cannot tell you the fifth person is the last one worth hiring, because it has no notion of the best achievable schedule at any level — it has a procedure and whatever the procedure produced. The distinction sounds academic until a number from it goes into a budget.

Optimisation as a technique in its own right

The alternative to picking a rule is not picking one. State the problem — task durations, precedence links, resource capacities, minimise the finish — and hand it to a constraint solver, which searches for the best schedule and, when it finishes, tells you that nothing better exists.

On this plan that takes about a sixth of a second. That is the honest headline and also the honest caveat: 21 tasks is small. Resource-constrained scheduling is NP-hard, and there are real plans where a solver will run out of time and return its best answer so far rather than a proved one. When that happens it should say so, which is a courtesy priority rules cannot extend because they never know either way. What has changed since 1994 is not that the problem got easy. It is that the range of plans where “proved optimal” is available at all now covers most of what a construction schedule or a maintenance shutdown actually looks like.

The techniques worth having on the list

Stripping out the ones that are really descriptions, four things genuinely change the answer:

• Move work in time. Levelling proper. Costs you the finish date, costs no money. This is the default and it is what the whole argument above is about.
• Add capacity. Buys days until the critical path floor, then buys nothing. Worth knowing the floor before the conversation, not after.
• Change how a task is done. Prefabrication, a different rig, a subcontractor who brings their own crew. This is the one that removes demand rather than rearranging it, and on this plan three such changes pulled eleven working days off the finish — more than hiring two extra people could.
• Split a task. Genuinely useful, genuinely disruptive on site, and frequently switched on by default in software without anyone noticing.

Everything else on the usual list is one of those four wearing a different name.

Trying it on your own plan

The free scheduler takes a task list with durations, predecessors and crew per day, plus a sheet of what you have, and returns the levelled schedule with the daily loading drawn underneath it. No rule to choose, because there is no rule — it solves.

If you want to see the effect the rest of this post is about, run your plan through it and through whatever you normally use, and compare the finishes. A difference of a few percent is the number Levine and everyone since have been describing, and on a job of any size a few percent is a fortnight. If the two agree, your plan was not tight enough for the technique to matter — which is a useful thing to have established, and takes about a minute.

Before any of it, though, draw the loading histogram. The chart under the Gantt chart is what tells you whether you have a levelling problem at all, and on this renovation it turned out four of the five resource pools were never over capacity. All this machinery, for one crew.

Things that I use, like, and am affiliated with:
Mint Mobile offers great cell phone service for $15 flat, get $15 off using the link. Get discounted phones with service activation and no contract.
I never spend money before I check Mr Rebates or Rakuten to get cashbacks, rebates, discounts, coupons or cheaper gift cards.