In prior articles I’ve reviewed how leveling determines which task to delay and the techniques Microsoft Project can use to resolve those allocations. In this article you learn about additional resource leveling limitations.
Contrary to what you might think, leveling doesn’t always resolve every overallocation. I know, it’s hard to believe, isn’t it? Prior articles have already shared scenarios such as those bulleted below that can leave resource overallocations even after leveling has been executed:
- Priority 1000 tasks; conflicts with other Priority 1000 or Manual tasks;
- Manual tasks; conflicts with other Manual or Priority 1000 tasks;
- Not allowing “Split in-progress tasks”; with tasks starting out of sequence;
- Leveling only within available slack; with insufficient slack;
- Hard Constraints (Must finish on, etc.); conflicts with other constrained tasks; and
- Not leveling Proposed resources.
While this is not an all-encompassing list, it provides enough examples to show that after leveling has been done, the project manager should still be looking for overallocated resources or other post-leveling issues.
Beyond the scenarios I’ve noted above, there are a few other circumstances where leveling has no effect. Let’s go through these limitations.
As Late as Possible
When leveling a project from the project start date forward, tasks with an “As late as possible” constraint won’t be leveled. It makes sense if you think about this. As late as possible tasks are scheduled with their finish date snugly against their successor task start date. If the successor task is delayed, the “As late as possible” task automatically moves with it.
But wait! If a task with this constraint isn’t leveled, can’t this create an overallocation? In short, yes. Let’s look at this scenario and see how to correct it.
The sample below shows our starting point schedule. ALAP Task is the “As late as possible” constrained task and it’s assigned to DD to create an overallocation scenario with DD’s other tasks. Tasks 2 and 3 were created to schedule in parallel so JR’s tasks would be adjusted when leveled.
With the Leveling Options window configured as shown here…
…the schedule was leveled and the results are shown below. There are two key items of note in the results. First, ALAP Task remained snugly up against Task 5 (its successor) even though Task 5 was delayed.
But second, and more interestingly, for some reason, the leveling engine created two gaps. There’s a four-day gap in DD’s work and a three-day gap in JR’s work, which can be seen in both the Gantt and Resource Usage views. While it appears that the leveling engine attempted to compensate for the “As late as possible” task, it didn’t do a very good job.
What can be done to fix this?
The solution is to check the “Leveling can create splits in remaining work” option in the Resource Leveling window. With this option checked, the results, shown below, look much better. The ALAP Task is still snugly against its successor, but more importantly, the large gaps from the first scenario are gone. Task 7 now shows a one-day split. But for some reason both ALAP Task and Task 7 still show an overallocation.
Looking at the Resource Usage view of this result, Daryl shows a one day split in Task 7, but on the next day, both the ALAP Task and Task 7 have work scheduled on the same day. While overallocated on one day, Daryl is not overallocated for the entire week.
But why did the leveling engine only create a one-day split?
Apparently, the length of the split is equal to the duration of the “As late as possible” task. In the example above, the duration of the ALAP Task was only one day. In the example, below, the ALAP Task duration was changed to three days, and the result is a three-day split within Task 7 followed by three days of overallocation.
As Soon as Possible
The same logic applies to tasks with an “As soon as possible” constraint when leveling the project backwards from the project finish date.
Fixed Duration Tasks
While I touched on this topic in an earlier article (“Resource Leveling: Leveling Fields“), it’s worth repeating here. By default, Fixed Duration tasks have their “Level Assignments” field value set to “No” and you can’t change this value. This disallows the leveling engine from using staggered assignment start dates on that task.
Project Manager-Created Issues
Task Level Overallocations
Project won’t fix task level overallocations.
I’ve previously discussed time period and task level overallocations. The first occurs when you schedule multiple tasks in parallel, resulting in an overallocation within a period. Leveling will generally fix these.
On the other hand, a task level overallocation is caused by a combination of project manager-entered task and resource assignment parameters. These must be fixed manually by the project manager. These scenarios appear on Fixed Duration tasks — for example, when there’s a three-day fixed duration task with an 80-hour work estimate or when somebody has entered an Assignment Units value of 100%, exceeding the resource Max Units value of 80%.
Dependency Relationship Problems
While these articles have primarily focused on overallocations, scheduling and leveling may result in large gaps of no assigned work. I’ll touch on this topic in a future article in this series. Microsoft Project must schedule and level the project schedule within project manager-defined “rules,” which includes obeying dependency relationships. The result could be gaps in resource utilization.
Next time, we examine the leveling process.