Resource leveling and resource smoothing are the two techniques a scheduler reaches for when someone is booked past what they can actually deliver. They sound similar and get confused constantly, including on the PMP exam, but they behave in opposite ways. Leveling is willing to move the finish date to respect the limits of your people. Smoothing refuses to move the finish date and rebalances the work inside the slack it already has. Knowing which one you are doing, and why, is the difference between a plan that holds and a plan that quietly slips.
Key takeaways
- Resource leveling is resource-constrained: it adjusts the schedule to fix over-allocation and can push out the end date and change the critical path.
- Resource smoothing is time-constrained: it rebalances work only within available float, so the end date and critical path stay fixed.
- Because smoothing is limited to float, it cannot always resolve every over-allocation; leveling always can, but at the cost of time.
- Use leveling when resources are the hard limit; use smoothing when the deadline is the hard limit and there is enough float to absorb the shuffle.
- In practice you often level first to get a feasible plan, then smooth the remaining bumps within the new float.
What is resource leveling?
Resource leveling is a scheduling technique that resolves over-allocation by adjusting the start and finish dates of tasks so that demand for a resource never exceeds its availability. It is used when resource availability is the binding constraint. If your only database engineer is needed full time on two tasks that overlap, leveling delays one of them until the engineer is free, even if that delay moves the project's end date. The schedule bends to fit the people.
Because leveling can delay tasks that sit on the critical path, it can extend the total duration and even create a new critical path. That is not a failure of the technique; it is the honest result of admitting you do not have enough of a resource to do everything at once. Leveling gives you a plan you can actually staff, which is worth more than a plan that looks fast on paper and falls apart in week three.
What is resource smoothing?
Resource smoothing is a scheduling technique that rebalances workload without changing the project end date. It is time-constrained: the finish date is fixed, and smoothing only moves tasks within their available float (the slack a non-critical task has before it would delay the project). Smoothing evens out the peaks and troughs of a resource's workload so nobody swings from idle to 150 percent booked, but it never touches the critical path and never pushes out the deadline.
The catch is that smoothing can only do as much as the float allows. If a resource is over-allocated on critical-path tasks, or the non-critical tasks have no slack left, smoothing runs out of room and the over-allocation remains. That is the core trade-off: smoothing protects the date but cannot guarantee the conflict is fully resolved.
Resource leveling vs resource smoothing key differences
The cleanest way to hold the two apart is to ask what is allowed to move. Leveling lets the date move to respect the resource. Smoothing holds the date and works within float.
| Dimension | Resource leveling | Resource smoothing |
|---|---|---|
| Primary constraint | Resource availability | Time (fixed end date) |
| Can the end date move? | Yes, it can extend | No, it stays fixed |
| Uses float only? | No, it can delay any task | Yes, only within available float |
| Effect on critical path | Can change or extend it | Leaves it unchanged |
| Resolves all over-allocation? | Yes, given enough time | Not always, limited by float |
| Also known as | Resource-constrained scheduling | Time-constrained scheduling |
| Use when | People are the hard limit | The deadline is the hard limit |
Swipe to see more →
Both techniques are part of the wider job of resource allocation in project management, which is where named people first get assigned to funded work and where the over-allocations they resolve are created in the first place. The tool that makes those over-allocations visible in the first place is the resource histogram: bars above the capacity line are exactly what leveling and smoothing exist to flatten.
A worked example
Say a designer is assigned to two tasks that both run in week 3, each needing 4 days of their time. That is 8 days of demand in a 5-day week: a clear over-allocation.
With smoothing, you check whether either task has float. If Task B is non-critical and has 3 days of slack, you slide it later within that slack so the designer does Task A in week 3 and Task B in week 4. The project end date does not move because you stayed inside Task B's float. The peak is gone and the deadline holds.
With leveling, suppose both tasks are on the critical path and neither has float. Smoothing has nowhere to go. Leveling delays Task B until the designer finishes Task A, which pushes Task B (and everything depending on it) later and moves the project end date out by several days. You accept a later finish because there is genuinely not enough designer to do both at once.
The example shows the rule in one picture: if float exists, smoothing may be enough; if it does not, only leveling resolves the conflict, and it costs time.
When to use resource leveling vs smoothing
Pick the technique that matches which thing is actually fixed. If the deadline is immovable (a regulatory date, a contracted launch) and you have float to play with, smooth first and preserve the date. If the resource is the immovable fact (one specialist, a hiring freeze) and the work simply cannot compress, level and let the date reflect reality rather than hiding the problem.
On real portfolios the two are not either-or. A common sequence is to level the schedule until it is feasible given your people, then smooth the remaining workload bumps within the new float so the team's week-to-week load is even. Deciding which projects even get the scarce resource in the first place is a portfolio question, settled when you prioritize the portfolio and confirmed against supply through resource and capacity planning. If you want a single artifact to see these conflicts before they force a leveling decision, build a capacity planning template that shows demand against availability by person.
How much float do you actually have?
Smoothing lives or dies on float, and most teams measure the wrong kind. Total float is how long a task can slip before the project end date moves. Free float is how long it can slip before the very next task is delayed. Smoothing that moves a task by its total float will often resolve the histogram on paper while quietly pushing the task behind it into trouble.
The reason is that total float is shared along a chain, not owned by one task. If four tasks run in sequence and the chain carries ten days of total float, that is ten days for the whole chain, not ten days each. Spend it on the first task and the other three now have none. Teams smooth against total float task by task, watch the peaks flatten, and then discover in March that the float they planned against in January was spent three times over.
| Measure | What it tells you | Who can spend it | Use it for |
|---|---|---|---|
| Total float | Delay available before the project finish moves | Shared across everything on the chain | Judging how much risk the whole path carries |
| Free float | Delay available before the next task starts late | The task itself, without asking anyone | Deciding what smoothing can safely move |
| Zero float | The task is on the critical path | Nobody | Smoothing cannot touch it; only leveling can |
| Negative float | The plan already misses a fixed date | Nobody | Stop rebalancing and re-plan; the date is gone |
Swipe to see more →
Use free float as the working limit for smoothing and treat total float as a portfolio-level risk measure. If you only record one of the two, record free float, because it is the number that answers the question smoothing actually asks: can I move this without breaking something behind it?
Which task does the tool delay first?
When a scheduler levels a plan, it has to choose which of the competing tasks gets pushed, and that choice is governed by a priority rule you may never have set. The same over-allocation and the same data will produce different end dates under different rules. If you never chose one, you accepted your tool's default, and defaults vary between products.
| Priority rule | What it delays first | What it optimizes | The risk it creates |
|---|---|---|---|
| Least total float first | Protects tight chains, pushes slack ones | The end date | Low-float work is served first every time, so flexible work is repeatedly deferred |
| Lowest project priority first | Work on lower-ranked projects | Portfolio intent | Only honest if the priority ranking is current and trusted |
| Longest duration first | Short tasks get pushed | Throughput of big items | Small tasks accumulate delay nobody notices until they block a handover |
| Earliest start date first | Whatever was scheduled later | Nothing in particular | Arbitrary; a common default and rarely the right answer |
| Manual priority field | Exactly what you tell it | Explicit judgment | Only as good as the discipline behind the field |
Swipe to see more →
Set the rule deliberately and write down which one you used. A leveled schedule is not a fact about your project; it is the output of an algorithm plus a policy. When two managers produce two different plans from the same data, the argument is almost always about the rule rather than the numbers, and it cannot be settled until someone says out loud which one they applied.
Leveling one project quietly breaks the others
Leveling inside a single project assumes the resource belongs to that project. Shared specialists rarely do. When you delay a task to fix an over-allocation, you have moved that person's committed time into a later period, and every other project counting on them in that period now has a conflict it does not know about yet.
This is the most common way a portfolio drifts out of alignment without any single project reporting a problem. Each project levels locally, each one produces a feasible plan, and every plan is feasible only if the others do not exist. The conflicts surface weeks later as a series of unrelated-looking delays, and because they arrive separately, nobody connects them to the leveling decision that caused them.
The fix is to level against a shared view of the resource rather than a project-local one. That means the person's availability is drawn from every commitment they hold, which is the job of resource and capacity planning across the portfolio rather than of any one schedule. Where a specialist is genuinely contested, the decision is not a scheduling decision at all: it is a question of which project has the stronger claim, settled when you prioritize the portfolio, not by whichever manager levels first.
Four things teams do instead of leveling
Leveling costs time, and admitting that is unpopular, so the over-allocation usually gets handled some other way first. All four alternatives are legitimate in the right circumstance and all four are routinely used to avoid a conversation about the date.
| The move | Why it looks attractive | What actually happens |
|---|---|---|
| Absorb it with overtime | Costs nothing on the plan and needs no approval | Works for a week or two; past that, quality drops and the hours stop being real |
| Split the task across periods | Flattens the bar without moving any dates | Adds restart cost each time, and the total effort grows rather than moving |
| Add another person | Turns a schedule problem into a budget problem | Ramp-up consumes the specialist you were trying to relieve, so the plan gets worse before it gets better |
| Assume part-time scales | The arithmetic is tidy | Two half assignments deliver less than one whole one; switching cost lands on both projects |
Swipe to see more →
The third one is worth pausing on, because it is the reflex response and it inverts under a bottleneck. Adding a person to relieve an overloaded specialist requires that specialist to explain the work, review the output, and correct it. For the first few weeks the new person is a net draw on exactly the resource that was already the constraint. If the peak you are trying to flatten is inside that window, adding people makes it taller.
How to prove a leveled plan is real
A leveled schedule is easy to produce and easy to believe. Five checks separate a plan that has been genuinely resolved from one where the tool moved the bars and nobody looked.
- Rebuild the histogram. Every bar should now sit under the capacity line. If any still exceed it, leveling did not finish, it stopped.
- Re-identify the critical path. Leveling can create a new one. Managing the old path after leveling is a common and expensive mistake.
- Recalculate float. The float you had before leveling is not the float you have now, and any smoothing you plan next depends on the new numbers.
- Check the capacity line was honest. A plan leveled against 40 hours a week is not leveled. See the realistic capacity figures on the resource histogram.
- Have the resource owner confirm it. The person or line manager who actually controls that time should agree the new dates before they go into a baseline.
The last check is the one most often skipped and the one that most often invalidates the plan. A schedule can be arithmetically perfect and still assume time that somebody else has already promised elsewhere.
Frequently asked questions
What is the difference between resource leveling and resource smoothing?
Resource leveling can change the project end date, while resource smoothing keeps it fixed. Leveling is resource-constrained: it adjusts the schedule (delaying tasks, even on the critical path) to remove over-allocation, so the finish date can move out. Smoothing is time-constrained: it rebalances workload only within available float, so the end date and critical path stay unchanged. In short, leveling protects your people and lets time flex; smoothing protects the deadline and works within slack.
Does resource leveling change the project end date?
Yes, resource leveling can extend the project end date. Because it delays tasks to keep resource demand within availability, and those delays can land on critical-path tasks, the total duration can grow and a new critical path can emerge. That extension is the deliberate trade-off: leveling gives you a schedule you can actually staff rather than one that only works if people are available beyond their real capacity.
Can resource smoothing resolve all over-allocations?
No. Resource smoothing only moves tasks within their available float, so it can smooth workload peaks but cannot resolve an over-allocation when there is no slack left or when the conflict sits on the critical path. In those cases smoothing runs out of room and some over-allocation remains. If the conflict must be fully resolved and the deadline cannot hold, you have to level instead.
Do you level before or after smoothing?
When a project needs both, the usual order is to level first, then smooth. Leveling produces a feasible schedule given your real resource limits, which may move the end date. Smoothing then evens out the remaining workload bumps within the float that the new schedule provides, without moving the date again. Doing it in the other order tends to waste effort, because leveling would undo the smoothing.
Which technique does the PMP exam expect for a fixed deadline?
For a fixed, non-negotiable deadline, the PMP framing points to resource smoothing, because smoothing keeps the end date fixed and adjusts work only within float. Resource leveling is the answer when resource availability is the constraint and the completion date can move. The exam tests whether you can spot which one is fixed in the scenario: the date (smoothing) or the resource (leveling).
Does resource leveling affect the critical path?
It can. Because leveling is free to delay any task, including tasks on the critical path, it can lengthen the current critical path or shift the critical path to a different chain of tasks. Resource smoothing, by contrast, never touches the critical path because it only moves non-critical tasks within their float. This is one of the clearest tells for which technique is in play.