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: http://wp.me/p6CCB4-v.)

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.