In prior articles, we’ve talked about two of the three resource leveling components. The first component, leveling mechanics, defines what will be leveled and when leveling will occur. The second component, leveling hierarchy is a decision tree for defining the tie-breaker aspects of leveling. In other words, it determines which task stays put and which task is delayed.

In this article, we’ll examine resolution options, the third component of resource leveling.

Resolution Options

Once the leveling engine identifies which task will be delayed, the question becomes how to resolve the overallocation. By default, the leveling engine will simply move that task after the completion of the higher precedence task. The resolution options, shown in the screen below, are part of the resource leveling window, which is accessed by clicking the Leveling Options icon in the Resource ribbon. These options provide additional possibilities. Let’s look at each individually.

Resolution options

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!

“Level only within available slack”

This option is related to the “Slack” tiebreaker I discussed in the leveling hierarchy articles, except it places a constraint on the resolution. When checked, this option tells the leveling engine that tasks can only be delayed within available slack. If insufficient slack is available, this option will leave resource overallocations.

This sample shows a series of tasks before leveling.

The Task ID chain driving the finish milestone is comprised of Task IDs 60, 61 and 66.
The current completion date is 7/20.
Task IDs 62 through 65 are all direct successors of Task ID 61 and can start on the same day. They are all direct predecessors of the finish milestone, have varying amounts of slack, and are the only tasks with resource overallocations.

This next screen shows the leveling results when the “Level only within available slack” is checked. Task IDs 64 and 65 were delayed as far as possible without impacting the 7/20 date. As a result of this constraint, both Task IDs 64 and 65 still contain an overallocation but the finish date remains unchanged.

The final example below shows the leveling results when the “Level only within available slack” remains unchecked. In this scenario, Task IDs 64 and 65 could be delayed to the point that the overallocations were resolved. But this resulted in the final date moving to 7/27.

Some project managers like this option checked because the resulting overallocations indicate key points within the schedule where additional work will be required, which could mean overtime or the addition of a temporary, short term resource, if feasible. Other project managers like this option unchecked because this result alerts them when the target date moves and allows them to determine how to bring the date back in.

“Leveling can adjust individual assignments on tasks”

When checked, this option allows the leveling engine to stagger start dates for each resource assigned to a task. In other words, Joe can start his task work on Monday, Sue can start her work the following Friday, and so on. When this option is unchecked, all assigned resources must be available before the task can be started. This option does nothing if only one resource is assigned.

While the staggered start dates have a good chance of extending the task duration, this option will allow the leveling engine to make much more effective use of the resources, as will be demonstrated by the following examples.

The first example below shows the schedule before leveling. Daryl and Sue are assigned to Task ID 37. Daryl has one day of work while Sue has five days of work. Task ID 38 is very similar. Daryl has one day of work, Sue has three days of work, and on this task Joe also has five days of work.

The sample below shows the leveling results with this option unchecked. There are two key items of note. First, ALL of Task ID 38 work is delayed until after ALL the work on Task ID 37 is completed. Second, Daryl now has a four-day gap in planned work because Daryl’s work on Task ID 38 can’t start until all work on Task ID 37 is finished. Also note that Joe doesn’t start work until day six.

The final sample below shows the leveling results with this option checked. Task ID 37 wasn’t adjusted, but Task ID 38 can now start on the same day. This occurs because Joe has no predecessor work and can start his work on Task ID 38 immediately. Daryl can start his work on Task ID 38 on day two, immediately after his one day of work completes on Task ID 37. And finally, Sue’s work on Task ID 38 is delayed to start on day 6, immediately after her 5 days of work completes on Task ID 37. As a result, the gaps left when leveling with this option unchecked disappear, and all the resources are used much more effectively. Also observe that the duration of Task ID 38 changed from 5.36 days to 8 days due to the staggered start/finish times.

This option works best when there is no requirement that all assigned resources work on the task at the same time. For example, each resource could be working on a different chapter of the training manual.

“Leveling can create splits in remaining work”

Leveling results with this option are tightly tied to the scheduling “Split in-progress tasks” option located in the File | Options | Schedule window. Due to the complexity of this relationship, these two options will be examined in the next article in this series.

“Level resources with the proposed booking type”

The “Booking Type” field allows the project manager to define a project team resource in one of two states. “Proposed” means the resource is tentative. It can be thought of as a placeholder resource. The resource can be used for cost and schedule forecasting within the project schedule, but the resource’s enterprise availability isn’t affected and tasks assigned to a “Proposed” resource will never appear on their timesheets. “Committed” means the resource is working on the project. Enterprise availability is impacted and tasks assigned to committed resources appear on timesheets.

This option is basically an additional parameter for the Level All function. It doesn’t define how to resolve an overallocation. It defines the type of resource to include in leveling. By default, Microsoft Project will only level committed resources. When this option is checked, resources with a Booking Type value of Proposed will also be included in leveling. Consider the following examples.

In the example below Resources A and B are assigned to a project. Resource A has been formally assigned to the project and as such, that is reflected in the Booking Type value of Committed. Resource B, however, is tentative and is being used as a placeholder until either confirmed or another resource is assigned. As such, resource B is identified as Proposed.

The following example shows the schedule before leveling. Note that Task IDs 3 through 5 are assigned to Resource B.

With this option unchecked, the results are shown below. Only resource A is leveled.

With this option checked, the after-leveling results show that resource B is also leveled.

“Level manually scheduled tasks”

This option allows the leveling engine to delay one manual task when it creates an overallocation with another manual task. The leveling engine uses the leveling hierarchy tiebreakers to determine which manual task is delayed. This is illustrated in the following samples.

The first sample below is before leveling. Task IDs 36 and 39 are conflicting manual tasks with the same resource assigned.

With the option unchecked, Task IDs 36 and 39 are not moved and the resource remains overallocated.

With the option checked, Task ID 36 is delayed to start after Task ID 39. As a result, there are no more overallocations.

Scheduling Options that Influence Resource Leveling

Two scheduling options have a direct impact on the resource leveling results. Both options can be found in the Schedule options window, File | Options | Schedule:

“Tasks will always honor their constraint dates”: This option and its relationship to the Task Constraints hierarchy level was discussed in earlier articles on the leveling hierarchy, which you can read in “The Leveling Hierarchy,” part 1 and part 2.

“Split in-progress tasks”: This option will be examined in conjunction with the resource leveling option, “Leveling can create splits in remaining work,” which I’ll be discussing next.

A Mish-mash of Alternatives

The resolution options are a mish-mash of alternatives. Several provide the leveling engine possibilities to make better use of allocated resources, while others constrain leveling or simply identify which types of resources to level. Unlike the leveling hierarchy, which exits the decision tree logic as soon as it determines which task to delay, the resolution options are either available for use (checked) or not available (unchecked). So it is possible for the leveling engine to apply multiple options to the same task.

As I noted earlier, my next article will focus on task splitting options available in both the scheduling and leveling options. But in the meantime, challenge yourself. Before instinctively clicking the Level All icon, take a minute to manually review an overallocation and try to determine, based on the leveling hierarchy, which task the leveling engine will delay and why. Then after leveling, examine the results to determine which — if any — resolution options were applied.

Have questions for author Daryl Deffler on resolution options? Post them in the comments below.