Last time I introduced the concept of the “leveling hierarchy” and examined the first three hierarchy levels: Priority 1000, Manual and Started Tasks. In this article, we review the remainder of the leveling hierarchy.

As a reminder, all of the examples I present look for overallocation on a “Day by Day” level with the scheduling option “Split in-progress tasks” unchecked and all “Resolving overallocation” options also unchecked.

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

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 Order

The following hierarchy levels are part of the ordered list associated with the selected leveling order value. They are presented in the sequence, Leveling Order = Standard.

Predecessors

The predecessor tie-breaker looks at task dependency relationships. Predecessor tasks are given higher leveling priority than their successor tasks.

The next example shows how the leveling engine treats tasks with predecessor relationships. The screen below is pre-leveling. Task IDs 10-13 are linked in a basic waterfall chain, Task ID 14 is a Priority 1000 task and Task ID 15 is a Manual task.

The following sample shows the results of leveling. Task ID 14 stayed put because it’s a Priority 1000 task. Task ID 15 didn’t move either because it’s a Manual task. Task ID 10 is leveled first, because it is the predecessor task to the entire dependency chain. Because it created an overallocation with the Priority 1000 task, Task ID 10 is delayed to start after the Priority 1000 task. Task ID 11 is leveled next; but because it can’t start immediately after Task ID 10 without creating an overallocation with Task ID 15, it’s delayed to start after Task ID 15. Then Task IDs 12 and 13 follow in sequence.

Slack

Slack is the amount of time a task can be delayed without affecting its successor task. When Project uses Slack values to determine which task to delay, the task with the smaller Slack value (before leveling) wins, and the task with the larger Slack value is delayed. Translated, the task with less wiggle room is leveled first. This is somewhat counterintuitive, but it will make more sense to you if you go through the examples below:

The Task ID chain driving the finish milestone is comprised of Task IDs 2, 3, 7 and 8.
Task IDs 4-7 are all direct successors of Task ID 3 and can start on the same day.
The combination of Task ID 7 and 8 is an eight-day duration.
Task IDs 4-6 are also direct predecessors of the finish milestone. These three tasks range from one to three days of duration and have a range of eight days in which to complete their work before causing an impact on the completion milestone. Thus, they have slack.
Task ID 6 has five slack days.
Task ID 5 has six slack days
Task ID 4 has seven slack days.
Because Task IDs 7-8 are a different resource altogether, only Task IDs 4-6 are overallocated.

When Project levels Task IDs 4-6, 6 wins and stays put because it has the smallest window for delay (five slack days). Task IDs 4 and 5 are delayed until after Task ID 6. Then Task ID 4 and 5 are compared and Task ID 5 wins because it had the next smallest delay window (six slack days). As a result, Task ID 4 is delayed until after Task ID 5. This can be seen in the screen below, which shows the results after leveling.

Note: Prior hierarchy levels didn’t resolve the resource overallocation on Task IDs 4-6. There are no Priority 1000 tasks, no Manual tasks, no tasks Started, and all three tasks had the same predecessor or successor. As a result, resolving this overallocation came down to Slack values.

Dates

This tie-breaker looks at task Start dates. When two tasks create an overallocation, the task with the earlier start date before leveling wins, and the later start date task is delayed.

In the first sample below, Task IDs 3 and 5 are assigned to the same resource and there is an overallocation as indicated by the burning man problem indicator. Task ID 5 has an earlier start date.

After leveling, Task ID 3 has been delayed to begin after Task ID 5 because Task ID 3 had the later start date before the leveling.

Priority field values to determine leveling order.

Note: If the tasks are in the same dependency chain, meaning Task IDs 2 and 4 have a common predecessor, the Dependency tie-breaker takes precedence. While the concept of this level is simple, it may be rarely used if all schedule tasks have predecessors and successors.

Constraints

This tie-breaker applies to tasks with a user-entered constraint type other than “As Soon as Possible.” The leveling engine will always try to honor those constraints; however, there are scenarios where Project will disregard the constraint date and delay the task. There’s also a way to force Project to honor the constraint.

In the first example below, Task ID 5 has a Must Start On constraint with the date of June 6, 2016.

The second example shows the leveling results. Task ID 1 can finish before the constrained task, so it stays put. Task ID 2 is delayed to begin after the constrained task, and Task IDs 3 and 4 are also delayed as shown.

Priority field values to determine leveling order.

The third example is another pre-leveling example. In this scenario, Task IDs 1-4 are linked in a basic waterfall relationship and Task ID 5 has the same constraint as prior examples.

Priority field values to determine leveling order.

The schedule after leveling is shown below, and the results are similar to the previous example. But why didn’t Task ID 2 take precedence over the constrained task? After all, it has a predecessor, which gives it a higher tie-breaker level. As I mentioned, Project tries to honor the constraint because this can be thought of as a pseudo-manually scheduled task. While not manually scheduled, it has a manually entered override constraint. In the screen below, Task ID 1 stays put. Since the manual constraint can be honored, Project leaves Task ID 5 alone and delays the remainder of the dependency chain until after Task ID 5.

Priority field values to determine leveling order.

The next example, below, shows a different twist. The only change is that duration of Task ID 1 was changed from two days to three days. Now, when leveling occurs, Task ID 1 stays put, but because its duration overlaps with the constrained task, the constrained task is also delayed a day. The result is a constraint violation identified by the circled problem indicator.

Priority field values to determine leveling order.

In my final example below, the scheduling option “Tasks will always honor their constraint dates” has been checked. This option can be found in the File | Options | Schedule window.

Even though this option is a scheduling option, it has an impact on leveling because it forces Project to honor the constraint date in both scheduling and leveling. The final leveling results are shown below. Since Task ID 1 overlapped the constrained task, it was delayed until after the constrained task completes. The constrained task takes precedence. The rest of the tasks then follow the dependency chain.

Priority field values to determine leveling order.

Priority

This tie-breaker examines the individual task level Priority field values to determine leveling order. The field values can range from one to 1,000 with one being the lowest priority. Priority 1000, which I covered in the last article, has special meaning and won’t be discussed here. The default value is 500.

In the screen below, I’ve highlighted the non-default Priority values. Note that Task ID 3 contains a “must start on” constraint of June 8.

Priority field values to determine leveling order.

The screen below shows the results after leveling. Task ID 4 has the highest priority at 600 and takes precedence. Task ID 3 contains the constraint, so it leveled second. Then, the remaining tasks are leveled in descending order based on their priority value.

Priority field values to determine leveling order.

If Priority values are being used, it’s beneficial to change the leveling order value to “Priority, Standard.” Without changing this parameter, the Priority value won’t be taken into consideration until almost the bottom of the hierarchy (Leveling Order = Standard) or not even included (Leveling Order = ID Only).

Final Predefined Hierarchy Levels

The following two tie-breaker levels are predetermined by Project. They’re the last two levels within the overall hierarchy.

Duration

When tie breakers with no higher precedence can determine which task stays put and which task is delayed, the leveling engine will examine task duration. Longer tasks are considered more important and will therefore be leveled first.

In the sample below, Task ID 4 has five days of duration, Task ID 3 has four days and the remaining tasks last three days.

After leveling, the tasks are ordered in descending rank by duration. But why did Task ID 1 take precedence over Task ID 2? That’s the final tie breaker.

Task ID

The final tie breaker in the hierarchy is the Task ID value. Tasks with a lower Task ID value will level before tasks with a higher Task ID. In other words, top down. In the first screen below, both tasks are the same in every respect, which means no other hierarchy level breaks the tie.

Priority field values to determine leveling order.

After leveling, Task ID 2 is delayed because its Task ID value is greater than Task ID 1.

Leveling Order Comparison

The following compilation illustrates how the leveling results can be radically different when you use each of the three leveling option values. (I’m showing the chart again so that you don’t have to go hunting for it at the start of the article.)

Each sample started with the same schedule and other options. However, there’s one difference on these examples from those presented earlier. I’ve checked the scheduling option, “Tasks will always honor their constraint dates.”

Leveling Order Standard Results

Task ID 9: Priority 1000;
Task ID 5: “Must Start On” constraint;
Task IDs 10-12: Predecessor relationships;
Task IDs 8 and 7: In descending priority value sequence;
Task IDs 4 and 3: In descending duration sequence;
Task IDs 1 and 2: In ascending Task ID value sequence; and
Task ID 6: The “Finish No Later than” constraint can’t be honored, so the task is delayed until the end of the schedule and shows a constraint violation problem indicator.

Leveling Order Priority, Standard Results

Task ID 9: Priority 1000;
Task ID 8 and 7: In descending Priority value sequence;
Task ID 6: The “Finish No Later than” constraint was close, but couldn’t be honored; so the task is delayed and the task shows a constraint violation problem indicator;
Task IDs 10-12: Predecessor relationships;
Task IDs 4 and 3: In descending duration sequence;
Task IDs 1 and 2: In ascending Task ID value sequence; and
Task ID 5: “Must Start On” constraint can’t be honored; the task is delayed until the end of the schedule, and the task shows a constraint violation problem indicator.

Leveling Order ID Only Results

Task ID 9: Priority 1000;
Task ID 5: “Must Start On” constraint could be honored;
Task IDs 1-3: in ascending Task ID value order. Note that ID 3, was started and split around Task ID 6;
Task ID 6: The “Finish No Later than” constraint is close, but can’t be honored; the task is leveled next and shows a constraint violation problem indicator;
Task ID 7-8: in ascending Task ID value order; and
Task IDs 10-12: in ascending Task ID value order.

It’s a Tie-breaking Decision Tree

An overallocation is a scenario where a project team resource, for example, Joe, is scheduled to work on multiple tasks, A and B, concurrently. As a result, Joe’s planned work in that period exceeds his availability. In this scenario, the first thing resource leveling must do is answer one simple question: Which task is delayed, A or B?

The leveling hierarchy defines a decision tree for answering that question. It offers a series of six to 10 tie-breakers that compare attributes of both tasks, checking user defined aspects such as priority or constraints, task progress (started), and other characteristics such as slack, duration and Task ID. Eventually, the hierarchy will find a tie-breaker; the task with higher precedence will stay put, and the other task will be delayed.

Once a determination is made to delay task A or B, Project needs to know which leveling techniques can be used to make the most effective use of available resources. These are the resolution options, which we’ll discuss in the next article.

Have questions about these aspects of resource leveling? Pose them to author Daryl Deffler in the comments below.