Resource leveling: when to move dates and when not to
Resource leveling is what you do when the plan says two tasks run at the same time and the same person is on both. You fix it by moving dates, and the part that matters is this: leveling is allowed to push your end date out. That is not a side effect, it is the definition. If your end date cannot move, the technique you want is resource smoothing, which only shuffles tasks inside slack they already have.
Most explanations of resource leveling skip straight to software features and never say that plainly, which is why people run a leveling function, watch their deadline jump two weeks, and assume something broke. Nothing broke. The plan was always two weeks long, and the overlapping bars were hiding it.
What resource leveling actually does to your plan
Resource leveling resolves over-allocation by changing when tasks happen. Over-allocation means someone is assigned more work in a period than they have time to do, and it is almost always invisible on a timeline until you look for it, because a Gantt chart draws what you told it, not what is possible.
Here is the shape of it. Say the design review needs four days and the content handoff needs four days. Both are scheduled for the week of 14 September. Both are assigned to Maria. Maria has five working days that week.
The plan says that week works. It does not. Eight days of work do not fit into five, and no amount of looking at the chart changes that. You have exactly three legal moves:
- Move one task later so the two stop overlapping. This is leveling.
- Split one task so part of it happens later. This is also leveling, and it is more expensive than it looks.
- Give one task to somebody else. This is reassignment, and it is only leveling in the loosest sense.
What you cannot do is leave it. An over-allocated plan is not an aggressive plan, it is a wrong one. The dates downstream of Maria's week are already based on work finishing when it cannot finish, so every date after it is fiction, and the fiction compounds quietly until somebody misses something visible.
This is also why over-allocation is worth hunting for deliberately rather than waiting to notice. On a small plan you can see it by reading down the assignee column week by week. Past about thirty tasks you need to sort or filter by person, because the overlap that hurts is rarely the one you happen to be looking at. A spreadsheet is perfectly good at this part, which is worth saying plainly: a column per week and a sum of assigned days will find your peaks. It is the fixing rather than the finding where a spreadsheet starts costing more than it saves.
Resource leveling vs resource smoothing
These get used interchangeably and they are not the same technique. The distinction comes from the standard project management vocabulary, and unlike a lot of that vocabulary it earns its keep, because the two methods answer different questions and have different costs.
| Resource leveling | Resource smoothing | |
|---|---|---|
| What it changes | Start and finish dates of over-allocated tasks, wherever they need to go | Start dates only, and only within float the task already has |
| Can the end date move? | Yes. This is expected | No. That is the constraint it works under |
| Can the critical path change? | Yes, and it often does | No |
| What it costs you | Time | Float, which is your margin for the next surprise |
| Use it when | The overload is bigger than the slack available to absorb it | There is enough slack to flatten the peak without pushing anything past its late finish |
The practical reading: smoothing is what you try first, and leveling is what you do when smoothing cannot solve it. Smoothing looks free because the deadline does not move, but it is not free. It spends float, and float is the only thing standing between a normal week and a missed deadline. A plan that has been smoothed until every task sits at its late finish is a plan where the next delay, of any size, moves the end date.
That trade is worth making consciously rather than by default. If you flatten a resource peak by spending three days of slack on a task that had four, you have bought a calmer September at the price of having almost no room in October.
How to level resources, in the order that costs least
The order matters more than any individual technique, because the cheap fixes stop being available once you have used an expensive one. Work down this list and stop at the first thing that solves it.
- Find the overload precisely. Not "Maria is busy", but "Maria has eight days of work in a five day week beginning 14 September". You cannot choose between fixes until you know the size of the gap, and the gap is usually smaller than it feels.
- Check the float on each conflicting task. If either task has slack, you may not have a real problem. A task with six days of float and a four day overlap can simply start later, and nothing downstream notices.
- Smooth within float. Move the task with the most slack, not the one that is easiest to drag. Moving the wrong one burns float you will want later.
- Level by moving dates. When float runs out, something has to move past its late finish, and the end date goes with it. Move the task whose delay costs least downstream, which is not always the shorter one.
- Split a task, but only if the work genuinely divides. Two days now and two days in a fortnight is fine for reviewing a document and terrible for writing one. Splitting has a real cost in getting back up to speed, and it is routinely underestimated because the plan shows four days either way.
- Reassign or add people, last. This is the fix everyone reaches for first and it is the one most likely to backfire on a running project. Fred Brooks made the point about software in 1975 and it generalises: adding people to late work often makes it later, because somebody has to explain the work, and the person doing the explaining is the person who was already the bottleneck.
One habit makes all of this easier: link the tasks that actually depend on each other before you start leveling. If moving a task drags its successors with it automatically, you can try three arrangements in a minute and see the real end date for each. If the dates are typed by hand, every experiment is a manual rebuild and you will stop after the first one that looks acceptable, which is rarely the best one. Linking tasks so dates follow each other is the difference between leveling and guessing.
Why the same person keeps ending up over-allocated
Leveling is a fix. It is worth a few minutes on the cause, because the same overload usually comes back next month otherwise.
- Assuming full availability. Nobody gives a project five days a week. Meetings, support, interruptions and holiday are real, and a planning assumption somewhere between 60 and 80 percent of nominal hours is far closer to what happens. A plan built on 100 percent availability is over-allocated on the day it is written, everywhere, invisibly.
- Assigning a person instead of an amount. "Maria owns the review" says nothing about whether it is a half day or a week. Overloads are made of hours, so they cannot be seen in a plan that only records names.
- Drawing tasks in parallel because they can be, not because they must be. Two tasks with no dependency between them get drawn side by side by default, which quietly asserts that someone will do both at once.
- Non-project work that never appears anywhere. The recurring client call and the support rota consume the same days as project tasks and usually appear in no plan at all.
The cheapest of these to fix is the availability assumption, and it fixes the most. Planning at four days a week per person rather than five absorbs a surprising share of small overloads before anyone has to level anything.
When leveling is the wrong answer
Three situations where reaching for leveling wastes an afternoon.
When the deadline is genuinely fixed. If the date is a conference, a contract or a regulatory filing, leveling is not available to you, because the one thing it does is move the end date. What is available is smoothing, and then cutting scope. Levelling a plan against an immovable date produces a chart that says you will finish late, which you already knew.
When the overload is one person for one day. A four hour overlap does not need a technique. It needs somebody to stay slightly later or start slightly earlier, and formalising it into a schedule change costs more attention than the problem does.
When every week is overloaded. This is the important one. If leveling keeps pushing work into a next week that is also full, you do not have a scheduling problem. You have more work than people, and moving dates only redistributes an impossibility. The honest outputs there are a later date, less scope, or more people, decided deliberately. A plan that has been levelled into a twelve month tail is a way of not making that decision.
It is also worth knowing that leveling can quietly change which chain of tasks controls your finish date. Once resource constraints move things, the longest path through the plan may run through tasks that were never on the original critical path. This is the observation behind critical chain scheduling, which treats resource contention as a first class constraint rather than something you clean up afterwards. Whether or not you adopt that method, the practical lesson holds: recheck the critical path after leveling, because the list of tasks worth watching has probably changed.
Common questions about resource leveling
- Does resource leveling always delay the project?
- No. It delays the project only when the over-allocation is larger than the float available to absorb it. If the conflicting tasks have enough slack, leveling moves them inside that slack and the end date holds, which is the case usually called resource smoothing. The delay appears when a task has to move past its late finish, and at that point the delay was already implied by the plan rather than caused by the leveling.
- What is the difference between resource leveling and critical chain scheduling?
- Resource leveling is a fix applied to a finished schedule: you build the plan, find the over-allocations, and move dates until they are gone. Critical chain scheduling builds resource contention into the method from the start, removes padding from individual tasks and pools it into buffers at the end of chains. Leveling is a technique you can use on any plan. Critical chain is a way of planning that you either adopt or do not.
- Can you level resources in a spreadsheet?
- You can find the over-allocation in a spreadsheet, and that is most of the value. A column per week and a sum of assigned days per person will show you the peaks. What a spreadsheet will not do is move the downstream dates when you resolve one, so every arrangement you try is a manual rebuild and you will try fewer of them.
- How much availability should I assume per person?
- Between 60 and 80 percent of nominal hours is a reasonable planning range for most teams, and four days a week is an easy version to apply. The number matters less than applying it at all: planning at full availability guarantees over-allocation everywhere, because it assumes a working week with no meetings, no interruptions and no non-project work in it.
Where to start
Open the plan and read down it one person at a time, one week at a time, until you find the first week where somebody is assigned more days than the week contains. That is your real first problem, and it is usually earlier than the place you were worried about.
Then work the list: check float, smooth if there is slack, level if there is not, and leave adding people until you have established that the other four options genuinely do not work.
Breeze
Timen
