Resource leveling and resource smoothing

Every schedule assumes the people doing the work are available exactly when the plan says they are needed. That assumption breaks constantly. You can build a plan with realistic durations and honest dependencies and still end up with the same engineer, welder, or graphic designer booked on two tasks at once, or five tasks in a single week that would take her three weeks working alone. That mismatch between demand and capacity is called over-allocation, and fixing it is the job of two related but distinct techniques: resource leveling and resource smoothing.

The two get used almost interchangeably, and plenty of software blurs them into a single "level resources" button. But they trade off different things, and knowing which one you are actually doing — and which one a tool just did to your schedule — matters the first time a deadline quietly moves and nobody can explain why.

What over-allocation actually looks like

A schedule really has two layers stacked on top of each other: the task network — what needs doing, in what order — and the resource assignments — who or what is actually doing it. The critical path method only looks at the first layer. It assumes unlimited people, machines, and rooms, and cares only about which chain of tasks is longest. Real projects do not have unlimited anything, and the moment you lay real people over that clean logical schedule, the second layer can break rules the first layer never checked.

Over-allocation is what that break looks like: a resource assigned more work in a given period than it has hours to deliver it. A few shapes it commonly takes:

• One person booked on two tasks that both run Tuesday through Thursday, full time on each — 200% of a week, on paper.
• A single meeting room double-booked for two workshops running at once.
• A specialist needed on-site by three different tasks in the same week, when only one visit is scheduled.
• A four-person paint crew assigned to six rooms that were each scoped for one painter working alone.

None of this shows up if you only look at bars and dependency arrows. The chart can look perfectly clean — sensible durations, logical links — and still be fiction, because nobody checked whether the people behind the bars can actually be in two places at once. Catching that is the whole point of leveling and smoothing.

Leveling and smoothing solve different problems

Both start from the same diagnosis — someone is over-committed — and both fix it by moving work around in time rather than by adding people. Where they part ways is what each is willing to give up to get there.

Resource leveling resolves over-allocation completely, and it is willing to move the project's finish date, and even its critical path, to do it. It delays tasks — using their float first, then pushing past it if that is not enough — until nobody is double-booked, however long that takes. Leveling treats "nobody is over-allocated" as the fixed requirement and the end date as the variable.

Resource smoothing flips that priority. It only shifts tasks inside float they already have, so the finish date and critical path never move. The cost is that smoothing is not guaranteed to solve the whole problem: if there is not enough spare float lying around to absorb a conflict, some over-allocation is simply left in place, because smoothing has decided the deadline is the part that cannot give.

	Resource leveling	Resource smoothing
What is fixed	Full resolution of over-allocation	The project finish date
What can move	The finish date, and possibly the critical path	How much over-allocation gets resolved
Uses float beyond what is available?	Yes, if needed	Never — stays inside existing float
Guarantees no over-allocation?	Yes	No
Typical use	A hard capacity limit — one welder, one machine	A fixed deadline that cannot move

Put plainly: leveling asks "how late do we have to push this to make it feasible?" Smoothing asks "how much of this can we absorb without being late at all?" Neither is more correct. They answer different questions, and which one you need depends on which constraint is actually the harder one in your situation — the calendar, or the headcount.

A small worked example

Take a two-person studio building a client's website. Maria is the only designer on the team, and two tasks both need her, full time, for three days each:

• Homepage design — 3 days, early start day 0, early finish day 3. It sits on the critical path: zero float.
• Email template design — 3 days, early start day 0, early finish day 3, with float that depends on what happens next.

Scheduled at face value, Maria is booked on both from day 0 to day 3 — 200% allocated. That is over-allocation in miniature — precisely what a dependencies-only plan will miss.

Suppose email template design has five days of float — nothing needs it finished until day 8. Smoothing solves this for free: slide it to start right after homepage design finishes, on day 3, so it now runs days 3 to 6. That spends three of its five days of float and leaves two spare; the task still finishes comfortably before day 8, and the project's overall finish date never moves. This is smoothing working exactly as designed — it found slack that already existed and spent it to make the plan real.

Now change one fact: suppose email template design has only one day of float, because a fixed client review sits on day 4 and needs the template ready. Smoothing can shift the task by at most one day — to start on day 1 — and that still leaves it overlapping homepage design for two of its three days. Smoothing has done everything the rules allow, and Maria is still double-booked. Leveling steps in where smoothing stops: it pushes email template design back to day 3 regardless of its float, so it now finishes on day 6 — two days past its late-finish date of day 4. Whatever was waiting on that template finishing by day 4 now slips too, and if that chain reaches the project's own finish milestone, the whole project lands two days later than planned. That is leveling's cost, made concrete: it guaranteed zero over-allocation, and it spent two days of calendar time to buy it.

Techniques for leveling and smoothing in practice

• Spend float first, always. Before anything else, check whether either conflicting task has slack to give. This is smoothing's entire method, it costs nothing, and most real conflicts are solved by it alone.
• Apply a priority rule once float runs out. When two tasks tie for the same resource and neither has enough float, someone has to go first. Common rules: the task with less float wins ("minimum slack first"), the shorter task wins because it frees the resource faster, or the more important task wins on business priority. Scheduling software runs exactly this kind of heuristic.
• Split the task. Pause one task partway through, let the resource handle the more urgent one, then resume. This works well when a task tolerates interruption without much rework cost — design and writing usually do; pouring concrete does not.
• Substitute or add a resource. Bring in a second designer, cross-train someone already on the team, or hire a contractor for the overflow. This is not technically leveling or smoothing at all — it removes the constraint instead of scheduling around it — but it is very often the cheapest real fix, especially when the conflict keeps recurring.
• Stretch instead of delay. Split a person's time across both tasks in parallel at half capacity each, rather than delaying one entirely. Each task takes longer to finish, but neither sits idle. This trades duration for concurrency and suits work that tolerates partial attention.
• Renegotiate scope, budget, or the date. When neither leveling nor smoothing can make the plan, the calendar, and the headcount all true at once, something outside the schedule has to move: cut scope, add budget for another person, or accept a later date. That is not a scheduling failure — it is the schedule honestly reporting that the three do not fit together yet.

How this changes the critical path and float

Classic critical path calculations — the forward and backward pass described in the critical path method explained — assume resources are unlimited. That is exactly the blind spot leveling and smoothing exist to correct: the pass tells you the shortest a project could take if people were interchangeable and infinite; leveling tells you what actually happens once they are not.

Leveling spends float, and that matters beyond the moment it happens. A task that shows five days of slack today can be down to zero tomorrow — not because the dependency network changed, but because leveling used the slack to resolve a resourcing conflict. Any prioritising you were doing off the old float numbers, the kind covered in slack and float explained, is now stale. The discipline is to re-run the critical path calculation after every leveling pass, not only after a delay actually gets reported.

Leveling can also move the critical path itself. If it delays a task past its own float, that task — and whatever follows it — can become the new longest chain in the project, distinct from whichever chain was critical before anyone thought about who was actually available. Some practitioners call this a resource-critical path, to separate it from the pure logical critical path that classic scheduling finds on the task network alone. A related methodology, critical chain project management, takes this further: instead of computing the logical critical path first and patching in resource conflicts afterward, it builds resource constraints into the schedule from the very start and protects the resulting chain with time buffers rather than task-by-task float. It deserves its own treatment, but the instinct behind it is the one this article has been building toward: a schedule that ignores who is actually doing the work is only ever a first draft.

Doing it by hand versus letting a tool do it

On a project small enough to hold in your head, leveling by hand is common sense: spot the double-booking, decide who waits, done. Past a handful of shared resources it turns into a genuine assignment puzzle. Deciding which of dozens of possible delays produces the shortest possible finish date is a combinatorial problem, not an arithmetic one, and there is no shortcut that guarantees the perfect answer. This is why scheduling software does not claim to find the one optimal leveled schedule; it runs a heuristic — delay the lowest-priority or highest-float task first at each conflict, and repeat — which is fast and usually good, but not provably optimal.

The short version

Over-allocation means a resource is asked to be in two places at once. Leveling and smoothing are the two ways to make the schedule stop lying about that. Smoothing is the free option — it uses float that already exists and never touches the deadline, but it cannot promise to fix everything. Leveling is the guarantee — it always removes the over-allocation, at the cost of being willing to move the finish date, and sometimes the critical path itself, to do it. Run the float-only pass first, understand exactly what it could not absorb, and only then decide, deliberately, whether the date, the scope, or the team is what actually has to change.

Frequently asked questions

What is the difference between resource leveling and resource smoothing?

Resource leveling always removes over-allocation completely, even if that means delaying a task past its available float and pushing out the project finish date or the critical path itself. Resource smoothing only shifts tasks within float they already have, so the finish date never moves — but it may leave some over-allocation unresolved if there is not enough float to absorb it.

Does resource leveling always push back the project finish date?

Not necessarily. If the over-allocated tasks have enough float between them, leveling resolves the conflict for free and the finish date stays put, which looks identical to a successful smoothing pass. It only pushes the date out when the required delay runs past the available float, which typically happens when a critical-path task, or one very close to it, is the one that has to wait.

What actually causes over-allocation in a schedule?

Two common causes. Either two tasks were scheduled against the same named person, machine, or room without anyone checking capacity, or the plan was built purely at the task-and-dependency level, with resourcing bolted on afterward instead of considered from the start. Either way, the schedule was internally consistent about dates and silent about who was actually meant to do the work.

Can software do resource leveling automatically?

Yes — most scheduling and Gantt chart tools include an auto-level function that applies a heuristic version of the priority rules above, typically delaying whichever conflicting task has the most float or the lowest priority first. It is genuinely useful for surfacing conflicts a person would miss, but treat the result as a draft: the algorithm only knows dates and float, not which client actually cares about which task, so review what moved before trusting it.

How is resource leveling different from critical chain project management?

Resource leveling is a corrective step applied to a schedule that classic critical path analysis already built assuming unlimited resources. Critical chain project management is a different scheduling approach entirely: it factors resource constraints into the schedule from the very start and protects the resulting chain with time buffers instead of task-by-task float. Different point in the process, same underlying problem — durations without named resources behind them are a fiction.