Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Resource Leveling MSP 2010 vs MSP 2013

5 replies [Last post]
Alexandre Faulx-B...
User offline. Last seen 1 year 32 weeks ago. Offline
Joined: 20 Jan 2003
Posts: 1355


Has somebody noticed that Microsoft dramatically changed the way resource leveling is computed since MS Project 2013?

Figure 1 shows a project sample leveled in MS Project 2010: task 8 has moved after task 5 as Resource 1 was overloaded 

Figure 2 shows the same project leveled in MS Project 2013: task 5 is moved after task 8

Both projects have been leveled with all the leveling options de-activated; resources 1 and 1 have a 100% max. capacity in the resource sheet.

What could be the reason of that change?

Thank you for your help



Tom Boyle
User offline. Last seen 8 weeks 5 hours ago. Offline
Joined: 28 Nov 2006
Posts: 304
Groups: None

Hi Alexandre,

I'm sorry for that.  I don't understand why PP seems to encourage/allow uploading of images only to dump them within a few hours.  I've edited my post to include links to the images.

I also included a slightly revised/expanded version of the post - including inline images and highlighting a little more of what I do with BPC Logic Filter - on my blog here:

Tom Boyle
User offline. Last seen 8 weeks 5 hours ago. Offline
Joined: 28 Nov 2006
Posts: 304
Groups: None

Hello Alexandre,

I’m still on 2010, so I haven’t noticed the change in 2013.  While it’s clear that Microsoft has modified the leveling rules from version to version, they don’t publish the details, so addressing the “reason for the change” is just speculation.  My own speculation is that minor changes to the leveling algorithm were made to limit apparent changes to the pre-leveling “Critical Path,” even at the expense of extending the schedule.  For your specific example:

·         The pre-leveling (i.e. CPM) critical path runs through task 5.  It has 0 days of total slack, while task 8 has 2 days of slack.


·         In resolving the resource conflict between task 5 and task 8, MSP 2010’s default rule gives greater scheduling priority to task 5 because:

o   It comes first on the task list;

o   The CPM schedule has it starting earlier;

o   It has a longer duration;

o   It has lower total slack in the CPM schedule;

o   It is marked as “Critical”;

o   Some other factors….

(I have no idea what the relative contributions of these factors are in the scoring.  Some might be zero.)

·         As a consequence of leveling, task 5 (the “critical” one) is scheduled first, while task 8 is delayed, and the project is extended 1 day.  Total slack is re-computed after incorporating the leveling delays, and a new “Critical Path” is displayed.

o   Perversely, Task 5 – which was clearly “critical” before leveling and is also clearly a resource driver for the project completion – now has 1 day of Total Slack.

o   Task 7 is shown as “Critical,” even though there is neither a logical nor a resource-driving reason justifying it.

o   So in short, the MSP 2010 leveling algorithm can substantially change the “Critical Path,” and the resulting slack values can be completely misleading.  (I wrote about this here:

o   This figure illustrates the actual resource-constrained Longest Path through the 2010 schedule (from BPC Logic Filter).

·         In contrast, MSP 2013 task gives greater scheduling priority to task 8, delaying task 5.  I suspect this is driven by some tuning of the leveling rules around Total Slack. (I’ve mimicked this in my MSP 2010 model by explicitly prioritizing task 8.)

o   The resulting “Critical Path” appears essentially the same as the pre-leveling version, but with an added 3-day leveling delay before task 5.  This may give project managers confidence that the leveling exercise has not “screwed up” their critical path.

o   Unfortunately, the project finish has been extended by an additional 2 days compared to the MSP 2010 leveler.

o   The project manager’s confidence in the critical path is still misplaced.  Task 7 and task 8 are now shown as far from critical, with 5 days of total slack.  As shown in the next figure, however, they are obviously on the resource-constrained longest path through the schedule.



look at

Tests showed that MSP 2007 creates shorter schedule than MSP 2010, MSP 2010 creates shorter schedules than MSP 2013, MSP 2013 and 2016 use the same algorithms.

MSP degrades.

Zorin may explain test details.