Resource Leveling: The Leveling Hierarchy, Part 1

Last time we examined resource leveling mechanics for Microsoft Project. This time, we look at the leveling hierarchy. And because it’s a BIG topic that can easily overwhelm, I’m breaking it into two “bite-sized” articles.

Overallocation Types

As a refresher, an overallocation is a situation where a project resource is scheduled to work more than he or she is available. For example, Joe is scheduled to work 58 hours in a week even though he is only available 40 hours per week.

There are two types of overallocations. The first type is a combination of the task configuration and resource assignment which results in an overallocation within a single task. The project manager must fix these scenarios by making task configuration and resource assignment changes. Leveling will not fix these.

The second type of overallocation is the result of multiple tasks scheduled in parallel. Because leveling will generally fix these, I focus on this type of overallocation in this article.

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 Hierarchy

When resolving an overallocation, Project follows a decision tree — a tie-breaking hierarchy to determine which task wins (stays put) and which task loses (is delayed). The first and last parts of this hierarchy are predetermined by Microsoft and built into the scheduling engine. But the project manager can tailor the core of this hierarchy by changing the “Leveling order” parameter.

The Leveling order parameter is part of the Resource Leveling window. You access it by clicking the Leveling Options icon in the Resource ribbon. There are three options: “Standard,” “Priority, Standard” and “ID.” Each parameter or option represents a predefined hierarchy list inserted into the middle of the overall hierarchy.

Here’s a little chart that lays out the leveling hierarchy, including the predefined leveling order options. The first three levels — Priority 1000, Manual Tasks and Started Tasks — are predetermined by Microsoft. After that the ordered list associated with the selected leveling order value is inserted. And the last two levels — Task Duration and Task ID — are also predetermined.

Leveling Sample Options

The following sections illustrate each tie-breaker within the leveling hierarchy. I present them in the Leveling order = Standard sequence. Unless I indicate otherwise, for all of my examples, overallocations are examined on a “Day by Day” level, the scheduling option “Split in-progress tasks” is unchecked and all the “Resolving overallocations” options are also unchecked.

Many leveling examples purposely contain limited or no dependency relationships so that leveling results can be seen in a scenario where tasks can be moved freely by the leveling engine.

Initial Predefined Hierarchy Levels

The following hierarchy levels are predetermined by Project. They are the first three levels within the overall hierarchy.

Priority 1000 and Manual Tasks

Priority 1000 is the highest-level tie-breaker. Nothing else is higher. Priority 1000 is a value of 1000 inserted into the Priority column at the task level. This task will never be touched by leveling. Nor — short of manually changing the task configuration — is there a way to make leveling delay a Priority 1000 task. Other priority values and their impact on leveling will be discussed later in this article.

The second highest tie-breaker is Manual Tasks. These are tasks with a Task Mode value set to Manual. Manual tells Project to bypass this task during leveling. However, as I will explain in a later article, the “Resolving overallocations” option “Level manually scheduled tasks” can allow leveling to move a manual task, but probably not in the way you’d think.

The following two examples illustrate leveling with Priority 1000 and Manual Tasks. The first screen shows the schedule before leveling. Task IDs 2-5 are general tasks. Task ID 6 is a Priority 1000 task, and Task IDs 7 and 8 are Manual tasks.

The screen below shows the results after leveling. Task IDs 6-8 stayed put and Task IDs 2-5 were delayed to fit around the Priority 1000 and Manual tasks. Additionally, notice the “burning man” problem indicator on Task IDs 6 and 7 which indicates resource DD remains overallocated. This overallocation remained because one task is Priority 1000 and the other task is Manual. Both task configurations tell the leveling engine to skip the task. As a result, an overallocation remains.

Started Tasks

Started Tasks are any task with actual work applied. Project contains internal logic that assumes a started task takes precedence over an “un-started” task. While the leveling engine treats all started tasks in the same manner, leveling results are best illustrated when a task is started out of sequence.

The following two examples illustrate how the leveling engine treats Started Tasks. The first screen shows the schedule before leveling. Task IDs 2-5 are general tasks linked in a waterfall dependency sequence. Task ID 5 has been started out of sequence, having actual work applied before any of its predecessor tasks. Task ID 6 is a Priority 1000 task, and Task IDs 7 and 8 are Manual tasks.

The screen below shows the results after leveling. The remaining work for Task ID 5, the started task, is now scheduled first, even though this breaks dependency logic and creates a resource overallocation with Task IDs 6 and 7. Again, Project assumes that started tasks take precedence over un-started ones. In simple terms, if you started it ahead of other tasks, it must be because it’s more important. Task IDs 6-8 stayed put because they are Priority 1000 and Manual tasks. Task IDs 2-4 were delayed to start after the started task and to fit around the Priority 1000 and Manual tasks. But notice that Task ID 5 now contains a burning man problem indicator also. Even though the remaining work for Task ID 5 creates an overallocation, the leveling engine doesn’t delay it.

The “Split in progress tasks” option will correct this scenario. This will be discussed in more detail in a future article.

Next time, we’ll continue our examination of the leveling order hierarchy.