Resource leveling is comprised of three components, and you need knowledge of all three to understand leveling in Microsoft Project.

Leveling mechanics define the “what” and “when” aspects of leveling.
Leveling hierarchy defines the tiebreaker aspects of leveling — which task wins (stays put) and which one loses (has to move).
Resolution options define “how” overallocations can be resolved. Stated another way, it defines the techniques Project can use to resolve an overallocation and any restrictions that constrain the resolution.

Over the next few articles, I explain and illustrate the options in each component. Let’s start to peel back the layers of resource leveling with an examination of leveling mechanics.

Want more? Watch Daryl Deffler’s two-part webinar series on resource leveling, now available, on demand.

Read Daryl’s articles in this resource leveling series here:
“Scheduling vs. Leveling”
“Problem Indicators”
“Leveling Mechanics”
“Leveling Hierarchy, Part 1”
“Leveling Hierarchy, Part 2”
“Resolution Options”
“Understanding Split Task Options”
“Leveling Fields”
“Limitations”
“Preparing to Level”
“Resource Leveling: It’s Time to Level Your Schedule”
“Resource Leveling: The Leveling Cycle”
“Resource Leveling: Recommendations”

Also, download a resource leveling “cheat sheet” in PDF format!

Leveling Mechanics

In simple terms, leveling mechanics define when leveling will occur, what constitutes an overallocation and the date range to be leveled. These parameters are part of the Resource Leveling window (shown below), which you access by clicking the Leveling Options icon in the Resource ribbon.

Let’s examine the functions you’ll find in this window.

Leveling Calculations

This option determines when leveling occurs. If “Automatic” is selected, leveling automatically occurs for every task and every resource after every change. This is generally not recommended. With the “Manual” option selected, leveling only occurs when the project manager manually clicks one of the leveling icons (Level Selection, Level Resource, or Level All). The “Manual” option provides more control, allowing you to determine which resources to level, which tasks to level and when. It also lets you view and assess scheduling results separately from leveling results, which can be useful when you’re attempting to determine the cause of a schedule issue.

Look for Overallocations on a [Timeframe] Basis

When looking for an overallocation, Project knows that any resource exceeding the Max Units is overallocated. But the program also wants to know the size of the timeframe to be examined for an overallocation. This option defines that timeframe size.

When “Hour by Hour” is selected, Project will examine each hour looking for overallocations. In a simple scenario say that Harry works a 40-hour, five-day week and is available 100 percent of the time (Max Units). Translated, Harry can work one hour within each one-hour timeframe. Any one-hour timeframe with more than an hour of allocation would be considered as an overallocation.

Still considering Harry’s situation, if you select the “Day by Day” option, Project will look for any daily allocation exceeding eight hours. And when the “Week by Week” option is selected, Project looks for any weekly allocation exceeding 40 hours. The same pattern holds for the other options.

When smaller timeframes are analyzed for overallocations, generally, more overallocations will be found. Conversely, when larger timeframes are analyzed, fewer overallocations will be found. The larger timeframe allows more “fudge factoring.” Monday could be overallocated by an hour and Wednesday under-allocated by an hour. But the net result across the entire week is that the resource is allocated at 40 hours or less. This is illustrated by the following two examples.

The first example below illustrates leveling “Day by Day.” Notice that Harry’s work allocation is a nice, flat eight hours per day. This is pretty much what project managers expect to see after leveling.

The second example, below, is a bit more interesting. It illustrates the same tasks leveled with “Week by Week.” Here, Harry is allocated 16 hours on Monday and Tuesday, eight hours on Wednesday and zero hours on the remaining week days. But why is there no red text to indicate an overallocation problem on Monday or Tuesday, even though Harry is clearly allocated more than eight hours each day? The answer is simple. Project is looking for overallocations at a weekly level. When examined in that timeframe, Harry doesn’t exceed 40 hours per week so he’s not considered overallocated.

Generally speaking, set this parameter to match the timeframe most commonly used in project schedule analysis. If the project schedule will be scrutinized at a daily level, set this parameter to “Day by Day”. If analyzing the schedule at a weekly level, set this parameter to “Week by Week”.

Clear Leveling Values before Leveling

When checked, this option tells Project to reset, or clear the results of the prior leveling process before leveling the schedule again. This initiates the same function as clicking the Clear Leveling icon. If you leave this unchecked, the results of the prior leveling process won’t be cleared first.

Project uses fields such as Preleveled Start, Preleveled Finish and Leveling Delay to store pre-leveling values and post-leveling results. These fields allow Project to reset the schedule back to a pre-leveling state when the Clear leveling function is initiated. Because leveling may change task start and finish dates, the original start and finish dates are stored in the preleveled start and finish dates. After leveling Project determines the number of days that leveling delayed the task and stores that value in the Leveling Delay field as “edays,” or elapsed days.

This example shows a leveled schedule. Note the Preleveled and Leveling Delay column values.

After the Clear Leveling icon is clicked, Project resets the schedule back to the pre-leveled state as shown below. Tasks are moved back to their original Start and Finish dates, which were stored in the Preleveled fields. The Leveling Delay values are now zero.

Note: Microsoft recommends checking this option to avoid the potential of compounded leveling results.

Leveling Range

The leveling range options determine the date range to be leveled. The “Level entire project” option tells Project to level tasks regardless of the date range — basically, all tasks. The “Level From: To:” option tells Project to level tasks only within the defined date range. Tasks outside the defined range will be ignored.

The following examples illustrate leveling within a specific date range. The first screen shows the project schedule before leveling. All five tasks start on 4/28.

In the second screen the project schedule was leveled only within the 4/28 through 5/5 date range. Task 1 stayed put. Task 2 was delayed to start after Task 1 is finished. Tasks 3 through 5 were delayed, but because leveling was constrained within the 4/28 through 5/5 date range, as soon as these tasks were delayed beyond the 5/5 leveling constraint, leveling moved them no further and dropped them onto 5/8, the next working day.

Next time, we’ll examine the leveling hierarchy, the component that serves as the tie-breaking judge.