Leveling Changes from MSP 2010 to MSP 2013

[I’ve slightly edited this old article – mostly figures.  After “upgrading” to Microsoft Project 2016, I can confirm that MSP 2016’s resource leveler appears similar to MSP 2013’s leveler in the simple case examined; both are substantially different from MSP 2010’s.]

Over the last few years, some tests of resource leveling algorithms in various software packages have been reported informally over at Planning Planet.

• Planning Planet: Test report on comparison of resource leveling engine of Microsoft Project, Primavera, Asta Powerproject, and Spider Project
• Planning Planet: Comparison of resource levelling algorithms of different Project Management tools

When using “default” conditions (i.e. without implementing any user-defined priority schemes), the general picture was that leveled schedules from MSP 2010 were significantly longer than those from MSP 2007.  There have also been reports that MSP 2013 (and MSP 2016, which seems to use the same leveling rules) produces even longer leveled schedules than MSP 2010.  Other software (Spider Project in particular) tend to produce shorter schedules under resource constraints.  I haven’t paid too much attention to these reports because a) I don’t use resource leveling often, and b) when I do use leveling, I always define some specific leveling priorities, so the “default” results are not so relevant.

Last week, a French planner (“Alexandre”) on PP noted some significant changes in default leveling results when migrating a simple schedule from MSP 2010 to MSP 2013, wondering what might be the reason for the changes.  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 Alexandre’s specific example:

• The project has a total duration of 7.5 days, and the pre-leveling (i.e. CPM) critical path runs through task 5.  Task 5 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:
  • The CPM schedule has it starting earlier;
  • It has lower total slack in the CPM schedule;
  • It has a longer duration;
  • It comes first on the task list;
  • It is marked as “Critical” (?);
  • 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 for a total duration of 8.5 days. Total slack is re-computed after incorporating the leveling delays, and a new “Critical Path” is displayed.
    • 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.

      

    • Task 7 is now shown as “Critical,” even though there is neither a logical nor a resource-driving reason justifying it.
    • 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: Logic Analysis of Resource-Leveled Schedules (MS Project).)
    • The next figures (from BPC Logic Filter) illustrate the actual resource-constrained Longest Path (Fig. 2) and Multiple Float Paths (2a) through the 2010 schedule.

• In contrast, MSP 2013 task gives greater scheduling priority to task 8, delaying task 5. I suspect this is driven by some complex tuning of the leveling rules around Total Slack.
  • Alexandre provided the MSP 2013 leveled schedule here (which also includes a minor date shift).

    

  • I’ve repeated it below in my [MSP 2016 model using Standard leveling order.]  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.

    

    Unfortunately, the project finish has been extended by an additional 2 days compared to the MSP 2010 leveler.  It is now 10.5 days.

• • 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 two figures from BPC Logic Filter, however, they are obviously on the resource-constrained longest path through the schedule.

Comparing the 0-Float Paths of the two schedules (Figures 2a and 5a), we see that unlike MSP 2010, MSP 2013 and MSP 2016’s leveling engine has preserved the logic drivers from the pre-leveling CPM schedule while implicitly inserting task 7 and task 8 into the driving path to project completion.   Although the project is extended as a result, the appearance of a stable critical path is preserved.  Fortunately, BPC Logic Filter depicts the resulting resource-constrained critical path clearly in both cases.

My speculation on the reason for the changed algorithm is based on the Project development team’s demonstrated preference for the appearance of stability (for mid-level users) over behavior that might be more technically correct from an advanced user’s point of view.  (See the handling of inactive tasks in MSP 2013 for another example.)

For an update on this topic, see Resource Leveling Changes from MSP 2010 to MSP 2016 – Revisited