Resource Leveling MSP 2010 vs MSP 2013

Hello (sorry I have sent the post too early),

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 Alexandre was overloaded

http://afaulxbriole.pagesperso-orange.fr/Figure1.jpg 

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

http://afaulxbriole.pagesperso-orange.fr/Figure2.jpg

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

What could be the reason of that change?

Thank you for your help

Alexandre

Alexandre,

look at http://www.planningplanet.com/forums/planning-scheduling-programming-discussion/531539/test-report-comparison-resource-leveling-en

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.

Hi Tom,

thank you for explaining MS Project's computations; unfortunately, I cannot read your png files, as the links seem dead; could you send them to me by e-mail: afaulxbriole@orange.fr?

Thank you

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: http://wp.me/p6CCB4-4i

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.