Resource over-allocation and levelling: find it and fix it by hand, with an example

A plan can respect every link and still be impossible. In the app release used throughout this guide the dates are correct, yet on days 8 and 9 Dana, the only tester, is down for two full-time test tasks at once. A Gantt chart draws one bar per task, so Dana's two bars on the same days look like any other pair of overlapping bars.

This guide shows how to measure resource over-allocation day by day against each person's calendar, then removes it by hand with four moves: smoothing within float, reassigning, delaying and adding capacity. Every move is tried on the same release, with the finish day it produces and the over-allocated days it leaves.

What resource over-allocation is#

Resource over-allocation is a scheduling condition in which a person or piece of equipment is assigned more work in a period than their available working time allows. Left alone, it becomes a late finish: in the example below, two days at 200% for one tester move an app release from day 12 to day 14 when nobody else can take a test. It also stays hidden. The US Government Accountability Office (GAO) gives the reason in its Schedule Assessment Guide: a schedule without resource assignments implies an unlimited number of resources with unlimited availability^[1].

The fix is called resource levelling (resource leveling in US spelling). GAO describes it as adjusting the scheduled start of activities, or the work assignments of people, to account for their availability, and adds that it can be as simple as moving work from an over-allocated person to an under-allocated one or delaying a start until the person is free^[1]. Levelling that stays inside float, so that the finish date does not move, is known as resource smoothing; Microsoft Project offers it as the option Level only within available slack^[2].

Who needs an over-allocation check, and when#

A plan needs the check from about 3 named people and 15 tasks, which is our rule of thumb for the point where one person ends up with two tasks open on the same day. The project manager runs it and makes the levelling decisions. Team leads read the result for their own people, and on teams of 4 to 15 each person reads their own row to see which tasks moved. The sponsor sees only the consequence, a finish date.

Run the check after the first complete draft, once links, durations and assignees are all in, and before you save the baseline. Then repeat it every time a date moves, because a slip upstream pushes tasks into somebody else's days.

Two situations can skip it. Someone who works one stream at a time, or a team that pulls tasks from a board with a work-in-progress limit, cannot be double-booked by the plan, since the limit already caps how many tasks each person holds. A plan that stops at phases has nothing to level: GAO's guide says levelling should never be applied to summary schedules^[1].

How the load is measured, day by day#

A person's load on a day is the hours of every task assigned to them that day, each multiplied by its assignment, divided by the hours they work that day; above 100% they are over-allocated. In this guide the assignment is the share of time a person gives to one task (50%, 100%), and the load is always that daily ratio.

For Dana on day 8 of the example, with two tasks at 100% and an 8-hour day, the load is (8 + 8) / 8 = 200%.

The calendar changes the denominator. On a day off it is zero, so any planned work is over-allocation. A half day off leaves 4 hours, and one task at 100% becomes 8 / 4 = 200%. Someone available 80% of the time works 6.4 hours of an 8-hour day, so one task assigned at 100% puts them at 8 / 6.4 = 125%.

Count by day, then summarise. If day 1 is a Monday, Dana's week from day 6 to day 10 holds 48 hours of testing against 40 available, a load of 120%, and the 20-working-day month around the release holds 64 hours against 160, which is 40%. A monthly view shows Dana with time to spare. Microsoft Project lets levelling look for over-allocations at any period from minute by minute to month by month, and its documentation warns that, depending on the period chosen, a resource can look over-allocated without being flagged^[2].

Scope matters as well. A load calculated inside one project ignores the person's work in other projects, so someone shared by three plans can look free in each of them. Where people are shared, run the check across projects.

A worked example: an app release with one tester#

The example has 6 tasks, 4 people and a 12-day critical path. A team prepares a release of a shopping app: Lena writes the spec, Marco builds the checkout API, Priya builds the mobile screens and Dana is the only tester. Durations are in 8-hour working days, every link is finish-to-start and every assignment is 100%. One detail sits in a calendar: Priya has a day of leave booked on day 9.

The critical path runs spec, API, API test and regression: 2 + 5 + 3 + 2 = 12 days. Dana's load is 100% on day 7, 200% on days 8 and 9, and 100% again from day 10 to day 12. Nothing in the dates looks wrong.

Measured, the problem is 2 over-allocated days for one person, a peak of 200% and 16 hours of excess work. Putting Dana's tests in sequence costs 2 days (move 3 below), so that is the ceiling for any fix. The API test cannot help by moving earlier, because the checkout API is finished only at the end of day 7 and the test, sitting on the critical path, has zero float to give.

Four moves to level the plan by hand#

Try the moves in this order and record two outputs for each: the new finish day and the over-allocated days that remain. Smoothing goes first because it costs nothing when it works; buying capacity goes last because it costs money.

1. Smooth within float. The screen test has 1 day of float, so it can slide from days 7–9 to days 8–10. Dana then has both tests on days 8, 9 and 10. To clear the API test, the screen test would have to end by day 7, which means starting on day 5, while Priya is still building the screens until the end of day 6. Output: finish day 12, 3 over-allocated days instead of 2. Rejected.
2. Reassign. Priya finishes the screens on day 6 and is free from day 7, apart from the leave on day 9. Two reassignments are possible, and the calendar separates them: - Priya takes the API test. It needs days 8, 10 and 11, ends on day 11 and pushes the regression run to days 12–13. Output: finish day 13, 0 over-allocated days. - Priya takes the screen test. It runs on days 7, 8 and 10 and ends on day 10, inside its 1 day of float, while Dana keeps the API test and the regression run. Output: finish day 12, 0 over-allocated days. The cost is that the screens are tested by the developer who built them.

Forget the leave and the first option looks free, with Priya planned to work on a day off.

1. Delay. If nobody else can test, Dana does the three tasks in sequence: screen test on days 7–9, API test on days 10–12, regression on days 13–14. GAO observes that the activities delayed by levelling are typically those with the most free float^[1]. Here that choice is worse: delaying the screen test instead leaves Dana idle on day 7 and ends the regression on day 15. Output: finish day 14, 0 over-allocated days.
2. Add capacity. A contract tester on the API test for days 8–10 keeps day 12 for 3 paid days plus a briefing; the guide to recovering a delayed project compares extra people by cost per day saved.

Our recommendation for this release: give Priya the screen test, because a layout defect found after release costs this team less than a day of slip. For a change to the payment flow we would give Priya the API test and accept day 13. As a default, reassign first and delay second. Reverse the order when the only free person would be testing their own work on something risky and the committed date has room: if the release were promised for day 15, move 3 changes nothing anyone outside the team sees.

Before calling the plan levelled, check:

• every person's load is at or below 100% on every day, with leave and part-time days in their calendars;
• the finish day against the one before levelling;
• every task you moved by hand carries a link or a note saying why, so the next update does not undo it (GAO asks for changes made to resolve resource conflicts to be documented and understood by everyone^[1]);
• shared people, across all their projects.

Common mistakes#

• Splitting the assignment to make the warning go away. Putting Dana at 50% on both tests clears the red cells while each test keeps its 3 days, so on paper half the testing hours vanish. Done honestly, each test at 50% runs for 6 days.
• Keeping leave and part-time days out of the calendar. In the example, Priya's day 9 is the only fact that separates a reassignment costing 1 day from one costing nothing.
• Assigning the whole team to one task. Five names at 100% is the load of five people for the whole duration. Split the task into subtasks with one owner each, or give each person their real share.
• Levelling a plan of phases. A 15-day "Testing" bar assigned to two testers says nothing about who is busy on which day.
• Levelling once. GAO recommends comparing the date of the last levelling with the date of the last change to resources and their availability^[1]. Recheck after every slip.

The limits of levelling#

Levelling, by hand or by software, counts hours and treats people with the same hours as interchangeable. Dana may be the only person with access to the device lab, and Marco may be twice as fast on the API as anyone else; neither fact appears in a load percentage. When skills decide who can do what, settle the assignments first and level afterwards.

Automatic levelling fails differently. GAO tells planners to examine the output of automatic levelling routines and adjust it where necessary, and warns that a routine can prove inefficient by delaying activities while it waits for a person who is only partly available^[1]. In the example, a routine that will not split the API test around Priya's leave starts it on day 10 and finishes the release on day 14, a day later than the split done by hand.

By hand, the moves stop converging at some size. Our view: past roughly 5 people shared across 3 or more projects, each fix in one plan opens a clash in another, and an automatic levelling engine such as the one in Microsoft Project is worth the time spent reviewing its output.

The inputs set a ceiling too. If the duration estimates are wrong, the overload moves with them. GAO's guide adds that levelling can have little to no effect on a schedule or severely delay the forecast end date, depending on the float available, and that when it delays completion the resources are a real constraint and the plan needs another approach^[1]. Rule of thumb: if the same person is above 100% on more than 10 working days in a quarter, moving dates will not fix it; cut the scope or add a person.

How to do it in Planitude#

Assign people to tasks (right-click a bar, then Assign people) with the share of time each one gives. The Workload view shows each person's load by day, week or month, measured against their calendar and availability. Over-allocated cells turn red with a warning icon, a week or month cell turns red if any one of its days is over-allocated and reports how many days and the peak, and a click on a cell lists the tasks behind it. The Gantt chart names over-allocated people in a warning.

The portfolio adds up each person's load across every project you can see. When the assistant proposes a change, the preview flags anyone it would over-allocate, with the peak and their availability. A plan imported from a .mpp file keeps the levelling delay Microsoft Project stored for each task, the time it is held back from its early start^[3], and the dates include it.

Planitude does not level automatically. It does not calculate new levelling delays either: it shows the overload, and you resolve it with the moves above.

Frequently asked questions#