Quick Links

Resource Leveling: Limitations

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.

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”
“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!

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.

Avatar photo
Written by Daryl Deffler

Daryl Deffler is currently employed by a large insurance company where he provides project management, project scheduling tool, process, and standards consulting for an enterprise project management office comprised of about 200 project managers. He has over 25 years in the IT project management field with experience managing small projects to large programs. During this time he has also developed and taught classes in both project management and scheduling tools such as Microsoft Project 2013, Primavera and ABT Workbench. He has been employed in the IT industry since 1979 in additional roles, including software development, technical support and management across mainframe, midrange and PC platforms.

Share This Post
  1. Leveling is tool that complements Schedule and Project Management. Starting with the obvious tasks constraints must be kept to a minimum. Yes they are a reality, but too many and you might as well use google sheets to plan your project (much cheaper).
    • I personally see no good reason to use manual tasks ever, again, expensive spreadsheet (call me a purist).
    • “Split in-progress tasks”, can make the WBS look good, but usually not realistic. To actually perform the work this way is inefficient; the context switching alone would add duration and lead to errors.
    • Leveling only within available slack, yes it causes problems, so don’t do it. Deal with reality.
    • Hard constraints, find ways to avoid them rather than ways to “fix” your WBS after leveling.

    It is the very rare WBS that is not resources constrained. Leveling provides a guide. Before leveling, your resources should be balanced. Look for opportunities to match up resource types so the work flows.

    Level by week and manage your resources. So resources are a little under or over allocated, so what? Will they make their dates? Leveling can be manually adjusted at the task level.

    I have seen schedules were too many resources were being used, reducing the count leveled out the work and added maybe 2 weeks to the duration. I some cases the duration was reduced because of the gained allocation efficiency. There are certainly times when more resources are required, but do the due diligence to determine the type, when, and duration.

    Ultimately the purpose of the WBS is to manage deliverables and dates (mostly the ones on the critical path, this requires resources to be plugged in. However, resource management is done in the real world. Don’t try to make the WBS a photograph of reality, it is Monet; modeling too much detail in the WBS is a trap. Finalize it, get the team buy in, and then manage the resources so they can make the dates modeled in the WBS.

  2. Avatar photo

    Thanks for the comment. I touch on a lot of your thoughts in later a later article of this series.

  3. What I don’t totally get about Leveling with ALAP is why Leveling doesn’t take in to account Priority, and simply nest the tasks together at the end of the Project.

    Example:I may have 10 tasks on one person that are ASAP – those level just perfectly. When I switch two to ALAP, I would expect those two to be scheduled at the end of the project date – seated right next each other and not overlapping.

    Instead, Project freaks about and scheduled them on top of each other, resulting in a resource allocation.

  4. Avatar photo

    Hey Eric
    As noted in the article, if your project is being scheduled from the project start date forward, ALAP tasks are not leveled. Which means none of the leveling hierarchy tie breakers come into play (including priority). Also remember from the Scheduling vs. Leveling article at the beginning of this series, leveling will only delay a task.

    In your question you ask why the tasks end up at the end of the schedule on top of each other. Essentially, where the ALAP task ends up is dependent on the ALAP task successor. If ALAP tasks have no successor, the scheduling engine places them at the end of the schedule. And if the ALAP tasks have no relationships within each other, or to other tasks to sequence them, the scheduling engine will end up stacking them on top of each other. Then, since ALAP tasks are not leveled (there’s no room to delay them which is what leveling does), they end up remaining right where the scheduling engine placed them. If those two tasks had a successor relationship (Y is a predecessor of Z), then task Z would end up at the end of the schedule and Y’s finish date would be snugly up against the start date of Z.
    If you look at your example of 10 tasks with ASAP configuration, ASAP tasks ARE leveled. Scheduling places these 10 tasks as early as possible in the timeline based on predecessors. After scheduling they could end up stacked on top of each other. However, ASAP task are leveled and leveling will then delay some of these tasks to resolve over allocations. Leveling can move these ASAP tasks because there is room to delay them.

    It’s not an obvious concept and it took me a while to figure it out. So I hope this helps.


Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>