Project Management guide · Cost and resources
Resource Leveling: Definition, Steps and Worked Example
Resource leveling is a scheduling technique that moves the start and finish dates of activities so that no person or resource is asked to do more work in a period than they have time for. It turns a plan that only works on paper into one that can actually be staffed, but it can push the project finish date later.
Key takeaways
- Resource leveling removes over-allocation by delaying, splitting or reassigning work.
- It can move the finish date and change the critical path; resource smoothing cannot.
- A resource histogram shows where demand exceeds capacity and where to act.
- Delay low-priority, high-float work first and protect the critical path where you can.
- Level before you baseline, and re-level when people or priorities change.
- Software can level automatically, but always review the result before you accept it.
What is resource leveling?
Resource leveling is a resource optimisation technique that adjusts a schedule's dates so that demand for each resource never exceeds the amount available. It is used when resources are fixed or scarce. Because work may have to wait for people to become free, leveling can extend the project's duration and change its critical path.
PMI's PMBOK Guide (sixth edition) describes resource leveling and resource smoothing together as resource optimisation techniques used when developing the schedule. The term is spelled "levelling" in British English; the technique is the same.
In practice, leveling answers a simple question: given the people we really have, when can this work realistically be done? It usually follows resource allocation, which assigns people to tasks, and it is one of the last steps before the schedule is approved and baselined.
Why schedules need leveling
A schedule built from task logic alone, using the critical path method, assumes unlimited resources. It will happily plan four tasks in the same week for the same engineer if the dependencies allow it. Once real names are attached, some periods need more effort than exists. That is over-allocation.
Leveling is needed when:
- The same person or skill is assigned to overlapping tasks.
- A specialist or a piece of equipment is shared with other projects.
- Someone leaves, goes on leave or is moved to higher-priority work.
- Scope grows but the team does not.
- A delay pushes two pieces of work into the same period.
Ignoring over-allocation does not make the work fit. It usually turns into missed dates, rushed quality and tired people, while the schedule still claims everything is on track. Leveling makes the trade-off visible so you can discuss it with the sponsor before it happens rather than after.
It also helps to know what you are leveling against. Use realistic availability, after leave, meetings and support work, rather than a full working week; capacity planning and full-time equivalents explain how to calculate it.
Resource leveling vs resource smoothing
This is the comparison most people search for, and a common exam question. Both techniques reshape resource demand; the difference is whether the finish date is allowed to move.
| Resource leveling | Resource smoothing | |
|---|---|---|
| Main goal | Remove over-allocation | Even out peaks and troughs in demand |
| Driven by | Resource limits | A fixed end date |
| Can the finish date move? | Yes | No |
| Can the critical path change? | Yes, often | No |
| Time it can use | Any, including beyond float | Only free and total float |
| Guaranteed to remove all over-allocation? | Yes, if dates can move far enough | No, only as far as float allows |
| Use it when | People are fixed and the date can be negotiated | The date is fixed and there is some float |
A useful way to remember it: leveling protects the people, smoothing protects the date. Many project managers try smoothing first and only level beyond float if that is not enough.
How to level resources step by step
- Build a logic-driven schedule. Enter activities, durations and predecessors and successors, then find the critical path and float.
- Assign resources and set availability. Record how much of each resource each task needs and how much is available per period (for example 2 developers, or one designer at 80%).
- Draw the resource histogram. Chart demand per day or week for each resource against a capacity line.
- Find the over-allocated periods. Note which tasks overlap in each one and how much float each has.
- Try smoothing first. Move non-critical tasks within their float and see whether that removes the peaks without changing the finish date.
- Level beyond float if needed. Delay, split or reassign the lowest-priority work, accepting a later finish only where necessary.
- Recalculate and check. Re-run the schedule, check the histogram again and identify the new critical path, which may now be driven by resources rather than logic.
- Agree the result and baseline it. Explain the trade-offs to the sponsor, agree the dates and then set the project baseline.
Which tasks should move first?
When several tasks compete for the same person, you need a rule for which one waits. Scheduling software and planners commonly use heuristics like these, in roughly this order:
- Keep critical-path tasks where they are if possible; move the tasks with the most float first.
- Respect business priority: work that is less important or less time-sensitive waits.
- Keep tasks that have already started going, to avoid stop-start inefficiency.
- Prefer moving shorter tasks, which disturb the rest of the schedule less.
- Do not interrupt work that loses efficiency when split, such as complex analysis or design.
Worked example: leveling a small software schedule
A team of 2 developers is building a small internal tool. There are five activities, and the developers are the only constrained resource.
| ID | Activity | Duration | Developers needed | Predecessors |
|---|---|---|---|---|
| A | Design database | 3 days | 1 | None |
| B | Build API | 4 days | 2 | A |
| C | Build admin screens | 3 days | 1 | A |
| D | Write test scripts | 2 days | 1 | None |
| E | Integration testing | 2 days | 1 | B, C, D |
Scheduled as early as the logic allows, A and D run on days 1–3 and 1–2, B on days 4–7, C on days 4–6 and E on days 8–9. The project finishes at the end of day 9. The critical path is A, B, E. C has 1 day of float and D has 5 days.
Before leveling
| Day | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
|---|---|---|---|---|---|---|---|---|---|
| Demand (developers) | 2 | 2 | 1 | 3 | 3 | 3 | 2 | 1 | 1 |
| Capacity | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Over-allocation | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 0 |
On days 4–6 the plan needs 3 developers because B (2 people) and C (1 person) overlap. Total effort is 18 developer-days.
Can smoothing fix it?
Smoothing may only use float. C has just 1 day of float, so the most it can move is to days 5–7, which still overlaps B on days 5, 6 and 7. Moving D does not help because D is not involved in the clash. Smoothing cannot remove the over-allocation without a third developer, so the finish date of day 9 can only be kept by adding capacity.
After leveling
Leveling delays C until B has finished. C now runs on days 8–10, and E, which needs C, moves to days 11–12.
| Day | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Demand (developers) | 2 | 2 | 1 | 2 | 2 | 2 | 2 | 1 | 1 | 1 | 1 | 1 |
| Capacity | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Over-allocation | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Demand never exceeds 2 and the total effort is still 18 developer-days, but the project now finishes on day 12, three days later. The critical path has also changed: it now runs A, B, C, E, because C is waiting for developers rather than for logic. That is a resource-driven critical path, and it is invisible in a plan that has not been leveled. From day 8 one developer is free, which is capacity you can offer to other work.
The project manager can now put clear options to the sponsor:
| Option | Finish | Cost and risk |
|---|---|---|
| Accept the leveled plan | Day 12 | No extra cost; 3 days later |
| Bring in a contract developer for days 4–6 | Day 9 | 3 contractor days plus onboarding time |
| Reduce the scope of the admin screens | Earlier than day 12 | Less delivered; agree with users |
| Ask the team to work overtime | Day 9 | Short-term only; risk to quality and morale |
Whichever option is chosen, the decision is now an informed one.
Resource leveling techniques
| Technique | How it works | Effect on finish date | Watch out for |
|---|---|---|---|
| Delay within float | Move non-critical tasks later, inside their float | None | Float is used up, so later slips hurt more |
| Delay beyond float | Move tasks later than their float allows | Moves later | New, resource-driven critical path |
| Split a task | Pause a task and resume it later | Usually small | Restart time and lost focus |
| Reassign the work | Give the task to another person with the right skills | Often none | Skill gaps; check a skills matrix |
| Change assignment units | Do the task part-time over a longer period | May move later | Longer task durations |
| Add capacity or overtime | Contractors, new hires or extra hours | None | Cost and fatigue; this is crashing |
| Reduce scope | Remove or defer lower-value work | None or earlier | Needs stakeholder agreement |
The first two are leveling in the strict sense. The others are alternatives or complements that you weigh up when delay is not acceptable. They map onto the classic project constraints: you can trade time, cost or scope, but rarely avoid trading at all.
Leveling resources across several projects
Textbook leveling works on one schedule. In most organisations, people work on several projects plus business-as-usual work, so over-allocation often only shows up when you look across projects.
- Use a shared workload or resource view that shows each person's total assignments, not just one project's.
- Agree portfolio priorities so you know which project's tasks wait when people clash.
- Level at the level of roles or skills for long-range planning, then at named people for the next few weeks.
- Re-level regularly, because a delay on one project can create an overload on another.
- Feed recurring clashes back into capacity planning, since they often mean the team is simply too small for the demand.
Our guide to managing multiple projects covers the wider habits that keep shared teams from being overloaded.
Resource leveling in project management software
Microsoft Project
Microsoft Project includes an automatic leveling feature. According to Microsoft's documentation, the Resource Leveling options include:
- Manual or automatic leveling: manual (the default) levels only when you choose Level All; automatic levels whenever a change creates an over-allocation.
- The basis for spotting over-allocation, from minute by minute to month by month.
- Leveling order: by ID only, by the standard criteria (predecessors, slack, dates, priorities and constraints) or by priority first.
- Task priority from 0 to 1,000, where 1,000 means the task is never leveled. The default is 500.
- Level only within available slack, which stops leveling from moving the finish date, in effect a smoothing setting.
- Whether leveling can split remaining work or adjust individual assignments.
- Clear Leveling, which removes the leveling delays and splits Project added.
Cloud work management tools
Most cloud tools take a more visual approach: a workload view highlights who is over- or under-allocated, and you rebalance by dragging tasks to another date or person. Wrike, our top-rated tool, provides workload charts that show who is over- or under-allocated, with effort allocation, job roles and capacity planning on higher tiers. Asana, ClickUp and monday.com also offer workload views, generally on paid plans.
Checking an automatic result
- Level a copy of the schedule first so you can compare before and after dates.
- Check that critical or contractually fixed tasks were not delayed unexpectedly.
- Look for tasks split into many fragments, which rarely work well in real life.
- Make sure resource calendars (leave, part-time hours) are correct, or the leveling will be based on the wrong capacity.
Benefits and drawbacks of resource leveling
| Benefits | Drawbacks |
|---|---|
| A schedule that can actually be staffed | The finish date may move later |
| Sustainable workloads and less burnout | New, resource-driven critical paths appear |
| Earlier warning of resource shortfalls | Float is consumed, so the plan has less slack for surprises |
| Fewer surprise delays during delivery | Takes effort, and needs repeating as things change |
| Better evidence for hiring or contracting decisions | Split tasks can reduce efficiency |
Common mistakes and practical tips
- Leveling after work has started. Level before the baseline is approved, then re-level only when something changes.
- Using 100% availability. Nobody spends every hour on project tasks; use realistic capacity.
- Accepting automatic leveling blindly. Review the result and its effect on milestones.
- Hiding the impact. If leveling moves the finish date, tell the sponsor and show the options, as in the example above.
- Inventing logic links to stop clashes. A resource clash is not a dependency; once the clash disappears, a fake link keeps delaying the work.
- Leveling one project in isolation when the same people work on others.
- Forgetting non-human resources such as test environments, equipment or meeting rooms that are also limited.
Resource leveling sits within the wider process described in our project scheduling guide and depends on knowing your project resources. The free project schedule template and critical path template are a good place to build the schedule you will level.
Free templates for this topic
Frequently asked questions
What is resource leveling in project management?
A technique that shifts task dates so that no resource is asked to do more work in a period than it has time for. It removes over-allocation even if the finish date has to move.
What is an example of resource leveling?
Two developers are scheduled to work on tasks that need three people for three days. Leveling delays the one-person task until the larger task is finished, so demand never exceeds two, and the project finishes three days later.
What is the difference between resource leveling and resource smoothing?
Leveling can move the finish date and change the critical path to remove over-allocation. Smoothing keeps the finish date fixed and only moves tasks within their float, so it may not remove every peak.
Does resource leveling change the critical path?
It often does. Delaying tasks to resolve clashes can make previously non-critical tasks critical, creating a resource-driven critical path.
Does resource leveling increase project duration?
It can. If the over-allocation cannot be resolved within the available float, the leveled project finishes later than the original schedule.
What is a resource histogram?
A bar chart showing how much of a resource is needed in each period, usually with a line for available capacity, so over-allocation stands out.
When should you use resource leveling?
When resources are fixed or scarce and the schedule shows demand above capacity, ideally before the baseline is approved and again whenever resources or priorities change.
Which tasks should be delayed first?
Usually the tasks with the most float and the lowest priority, so critical work keeps its dates where possible. Avoid interrupting tasks that have already started.
Who is responsible for resource leveling?
The project manager or project scheduler levels the project schedule. Where people are shared across projects, a resource manager or PMO usually agrees priorities across the portfolio.
Is resource leveling the same as resource allocation?
No. Resource allocation assigns resources to tasks; leveling adjusts the schedule to resolve the over-allocation that allocation reveals.
Can software level resources automatically?
Yes. Microsoft Project and other scheduling tools have automatic leveling, and many cloud tools offer workload views for manual rebalancing. Always review the result, because the software does not know your priorities.
How do you level resources without delaying the project?
Use only available float (resource smoothing), reassign work to people with spare capacity, add temporary capacity or reduce scope. If none of these is enough, the date has to move.
What are the alternatives to resource leveling?
Adding people, paid overtime, outsourcing, reducing scope or crashing the schedule. Each one trades time against cost or scope.
Is resource leveling on the PMP exam?
Resource leveling and smoothing are standard resource optimisation concepts in PMI's PMBOK Guide and are commonly covered in PMP exam preparation; see our PMP certification guide.