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: the 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 |
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.
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.
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.