Quick Links

Resource Leveling: Scheduling vs. Leveling

“Don’t click the level button — it messes up your schedule.” How many times have you said this or heard it? If I had a nickel for each time I’ve heard this over the course of 25-plus years, well, let’s just say I’d be a wee bit closer to a comfortable retirement. There’s a truth in that statement. Microsoft Project will mess up your schedule — if you don’t understand what leveling does or how it works.

Sometimes we forget that Project is only a software tool, albeit a complicated one. It has no perception of time and therefore doesn’t understand concepts like today, the past or the future. It only has algorithms. And it doesn’t understand what we “want” it to do; it only does what we “tell” it to do. As a result, the ownership is on us, the human, to learn how Project works and what the available options do so that we can “tell” Project the right things to get the results we “want.”

Resource leveling — or just “leveling” as it’s more commonly known — is probably the most complicated, feared and misunderstood functionality within Project. It takes a long time to learn and the learning process is often a series of anxiety-filled experiments that end up creating more frustration than understanding. And because project managers actually have projects to run (who knew?), they typically don’t have time to experiment. The result; “Don’t click that button…”

It’s time to change that.

This is the first in a series of articles focused on resource leveling. The series objective is simple; to uncloak the mystery that is resource leveling and help you, the project manager, transition from fighting the tool to controlling the tool. To accomplish the objective this series includes articles covering the following general topics:

  • Laying a foundation, including scheduling vs. leveling and problem indicators and what they’re telling you;
  • A deep dive into how leveling works, including leveling mechanics (what to level and when);
  • Leveling hierarchy, covering which task stays and which task moves;
  • Resolution options — ways to resolve overallocations and limitations;
  • Leveling a schedule such as preparing to level, the leveling functions and the leveling cycle; and
  • Leveling guidelines.

Want more? Watch Daryl Deffler’s two-part webinar series on resource leveling, now available, on demand.

Read Daryl鈥檚 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鈥檚 Time to Level Your Schedule”
“Resource Leveling: The Leveling Cycle”
“Resource Leveling: Recommendations”

Also, download a resource leveling “cheat sheet” in PDF format!

Scheduling vs. Leveling: An Overview

Scheduling and leveling are two distinct foundational concepts within Project. They’re as essential as formula calculations are to Excel. In essence, they’re the primary reason for Project; to automate the process of sequencing project tasks while making the most effective use of available resources.

Scheduling is timeline-oriented, focused on creating the absolute shortest schedule duration. It occurs when the Calculate Project icon is clicked. Or, if you’re like many project managers who turn on the “Calculate project after each edit” option, scheduling occurs automatically after every change.

Leveling is resource-oriented, focused on making the most effective use of available resources. It occurs when one of the leveling icons such as Level All is clicked. If the Leveling option “Leveling calculations” is set to Automatic, it can also occur automatically, after every change is made.

What does “timeline-oriented” and “resource-oriented” mean? The following sequence provides a simple illustration of how scheduling and leveling work. For this sequence automatic scheduling and leveling have been turned off.

The project manager creates Tasks 1 through Task 3 with no relationships as illustrated below. Resource A is overallocated on the first three days.

In the second screen, below, the project manager defines Task 1 as the predecessor to Tasks 2 and 3. Notice that even though the relationships have been established, nothing has changed.

The project manager clicks the Calculate Project button and the results are shown below. Tasks 2 and 3 are shifted later in the timeline because they’re Task 1 successors. But notice Tasks 2 and 3 start on the same day, even though this overallocates the resource. The reason is simple: Scheduling is focused on sequencing the tasks to create the absolute shortest possible duration. Starting Tasks 2 and 3 on the same day doesn’t violate any dependency relationship, but it does result in the shortest possible duration, regardless of resource impacts.

In the final sample, below, the project manager clicked Level All. At this time, leveling, which is resource-oriented, delayed Task 3 to start after Task 2. This was done not because of any dependency relationship between Tasks 2 and 3, but because the first availability for the resource was the following Friday.

The following table provides a summarized comparison of both scheduling and leveling.


Primary FocusEffectively using the timelineEffectively using available resources, which in most but not all cases is removing resource overallocations
Will move tasks?Moves tasks in both timeline directions, based on task or dependency changesOnly delays tasks from the scheduling-defined start or resume date
Adjusts task duration?May adjust duration based on changes to a predecessor taskMay extend calendar duration, but only if "Leveling can create splits in remaining work" option is checked
Can split a task?Yes, will split all remaining work from actual work if the scheduling option "Split in-progress tasks" option is checkedYes, will only split remaining work after the scheduling-defined resume date if the "Leveling can create splits in remaining work" option is checked
Fixes resource overallocations?No. Scheduling results will often create resource overallocationsYes. But may not fix all over allocations

Note: Task-level adjustments such as changing work, resource assignment units or duration adjust the individual task immediately, regardless of the automatic schedule or level option selections.


As tempting as it might be to set both scheduling and leveling to occur automatically, I don’t recommend this. My suggestion: Configure scheduling to occur automatically and leveling to occur manually.

This is recommended for several reasons. Performing both processes automatically blurs the process boundaries, and as a result it becomes difficult to determine if an issue appeared during scheduling or leveling. Performing these processes separately helps resolve issues at a high level. If the issue appears after scheduling (before leveling), it’s task related (task configuration, task dependencies, etc.). When the issue appears after leveling, it’s resource related.

Additionally, Microsoft recommends executing these processes separately to enable better tool performance and to produce better results.

Next time: Learn about resource leveling indicators.

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. Thanks for the first instalment in this series Daryl. Eagerly awaiting the subsequent articles in your series!

  2. Thank you, Daryl, for tackling this topic. I use leveling all the time but there are still times when I don’t get the results I expect. For example, in Leveling Options / Leveling order, I select “Priority,Standard” but leveling still doesn’t always schedule higher priority tasks first. Perhaps this doesn’t work when using a master project? Thanks for the first installment. I’m looking forward to the remainder of this series.

  3. The schedule images in the article use the Task Usage view.
    All tasks are Auto Scheduled, rather than Manually Scheduled.
    The Resume date is a column than can be inserted in a table or column’s formula.
    When leveled, Task 3 is delayed past Task 2 because the leveling algorithm starts a longer task before a shorter task.

  4. Scheduling can change a task’s duration if its resource’s Assignment Units is changed, not it’s predecessor.

  5. Thank you Daryl, looking forward to your next article.

  6. Thank you for these insights. Looking forward to you next installment.

  7. Thanks for demystifying this exercise, and for highlighting its impact on managing project schedules. Looking forward to learning more . . .

  8. Thank you for adding more insight into my understanding of project management. A new layer learning about levels was welcome.

  9. Ok, you can organize stuff and do some of Microsoft麓s job so the button will have some use. Howerver, adequate resource leveling can be executed with all these steps in more professional leveling engines and that can save anyone not just time in doing that, but actually getting better results that can save companies a lot of time and costs in projects. I have a prototype of a resource leveling engine that works together with MSP. Write me if you want to see what can be done with that!

  10. Hello,
    It seems MSP leveling algorithm prefers to “delay more one task” rather than “delay 2 tasks but preserving the order”. Unhapplily I would like to preserve the order (FIFO).

    Example : 3 suppliers deliver their product (delivery-1, delivery-2, delivery-3).
    There’s only one resource (ResourceA) to test their deliveries (and it is not possible to split the test task) in FIFO order (test-1, test-2, test-3 whose predecessors are respectively delivery-1, delivery-2, delivery-3) => with the same priority.
    I noticed that if delivery-2 arrives during test-1, and delivery-3 arrives later but after the end of test-1, resource leveling causes test-2 to start after test-3! It does not respect FIFO… and supplier 2 wont’t be happy! 馃檪

    Is there a way (without altering priorities because they mus stay equal since it’s FIFO) to tell the algorithm. “Ok, ressourceA is busy with test1, so you have to wait before you start the next test. But when test1 is finished you start with test2 according to FIFO (since its predecessor is earlier than test3). So you delay test3 until the end of test2. In this way 2 tasks are delayerd instead of one but FIFO is respected.

    Do you see a way?
    Thank you

  11. Laurent
    The simplest means to achieve your objective is to set finish-start dependencies between test1, test2, and test3. Generally, that should solve the issue. However, if it doesn’t, the next simplest approach is to use the priorities. Default priority is 500, so I’d set test1 to something like 505, test2 to 503, and test3 to 501. You also need to change your leveling options to use the Priority,Standard algorithm which places priority at the highest level.

    Not knowing the specifics of your schedule, if the arrival of Delivery2 means you mark the test2 task started, that could be causing the split issues since project assumes a started task has higher priority simply because it’s started. If this is the case, you might want to try using a milestone to signify Delivery2 arrival and set this as a predecessor to test2 also. With this approach you can identify completion of Delivery2 without starting test2.
    Hope that helps

  12. Oliver
    yes, you are correct. Having worked for years with a tool where “Duration” represents calendar duration and not work duration translated into days, I will occasionally say duration when I should have said calendar duration.
    As an example, Task A starts Monday 8AM and is 12 hours. Its successor starting on Tuesday at noon is Task B with 8 hours. Duration for A is 1.5 days and B is 1 day, but the calendar duration for A is 1.5 days and B is 2 days because it starts on Tuesday and finishes on Wednesday. Changing A to be only 8 hours of work means it completes at 5:00 on Monday which now allows B to start at 8AM on Tuesday and finish at 5:00 on the same day. B still has an MS Project Duration of 1 day, but the calendar duration on B is now 1 day.
    Sorry for my slip!

  13. Hello Daryl,
    Thank you for your time and answer above!
    The thing is the suppliers (and I have more products than 3) change their plannings more often than I would like 馃檪
    So I don’t know which one will actually be the first (then second, 3rd …)
    That’s why I can’t use set “finish-start dependencies between test1, test2, and test3” nor priorities. To respect FIFO they should have the same priority.
    In my wildest dream 馃檪 each week, I would update the delivery planning, I use the button “resource leveling schedule” and “voila”! MSP project would nicely reorder the tests tasks in FIFO order (according to each delivery).

    What do you think please?

    Here’s my example before “resource leveling schedule”:
    Name Dur茅e_pr茅vue Begin End Pr茅d茅cessors Name_resources
    Deliv1 0j 13 Juillet 2018 09:00 13 Juillet 2018 09:00
    Test1 13j 13 Juillet 2018 09:00 31 Juillet 2018 18:00 1 ResourceTest
    Deliv2 0j 16 Juillet 2018 09:00 16 Juillet 2018 09:00
    Test2 13j 16 Juillet 2018 09:00 01 Ao没t 2018 18:00 3 ResourceTest
    Deliv3 0j 02 Ao没t 2018 09:00 02 Ao没t 2018 09:00
    Test3 13j 02 Ao没t 2018 09:00 20 Ao没t 2018 18:00 5 ResourceTest

    and after “resource leveling schedule”
    Name Dur茅e_pr茅vue Begin End Pr茅d茅cesseurs Noms_ressources
    Deliv1 0j 13 Juillet 2018 09:00 13 Juillet 2018 09:00
    Test1 13j 13 Juillet 2018 09:00 31 Juillet 2018 18:00 1 ResourceTest
    Deliv2 0j 16 Juillet 2018 09:00 16 Juillet 2018 09:00
    Test2 13j 21 Ao没t 2018 09:00 06 Septembre 2018 18:00 3 ResourceTest
    Deliv3 0j 02 Ao没t 2018 09:00 02 Ao没t 2018 09:00
    Test3 13j 02 Ao没t 2018 09:00 20 Ao没t 2018 18:00 5 ResourceTest

    Delivery 2 (16/07) is before Delivery 3 (2/08) but Test3 is done before Test2, not in FIFO style.

  14. Laurent
    Unfortunately, MS Project doesn’t do well with dynamic fluctuating scenarios like you’ve provided. It likes defined structure. So, to provide a solution, there will be some aspect of manual changes that you will need to make to help MS Project adjust to the external dynamics of the random delivery dates. With that in mind, I would suggest the following.

    Make sure all the Delivery tasks are predecessors of their related testing tasks.
    Set all delivery/test task priorities to 500 to start.
    And for initial scheduling, set all delivery tasks to start-start relationships with one common predecessor. At this point, we don’t care how it schedules the testing work, but that’s fine.

    When the first delivery arrives, for example #2, bump the priority of the Delivery/test2 tasks to a higher number, such as 600. Set leveling options to use Priority,Standard.
    Now when leveled, Delivery/Test2 should schedule before 1 and 3 and we still don’t care how those schedule because we don’t yet know which will arrive next.

    When the next delivery occurs, lets say its #3, set those tasks to a priority that is lower than the first delivery but still higher than normal priority. For example, set it to 599. Now when leveled, all remaining work for #2 should schedule first (priority 600), then #3 (priority 599), and finally all the remaining deliveries (priority 500) in a sequence we still don’t care about.
    Each time a new delivery arrives, give those delivery/test tasks the next lower priority number.

    The other option would be to dynamically change the predecessor relationships as each delivery arrives. When the first delivery arrives, set all other delivery/test tasks predecessors to be the first test task. When the second delivery arrives, change all remaining delivery test task predecessors to be the test of the second delivery, and so on. This will achieve the same results, but it will be more work.

    I don’t know of any way that MS Project can handle the dynamic sequence that you’ve defined. So this is how I’d approach it.

    Hope that helps

  15. Merci / thank you very much Daryl!
    Maybe one day MS Projetc will add/create another leveling option “Priority/FIFO” 馃檪


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>

+ 75 = 76

Thanks for submitting your comment!