Understanding Leveling Priority

Steve,

It's probably good that Trevor convinced you to use leveling priorities.  I've never allowed leveling to be performed without them - but of course that wasn't the question you asked.

AACE International (Association for the Advancement of Cost Engineering) published one of my recent papers called "Extracting the Resource-Constrained Critical/Longest Path from a Leveled Schedule."  The paper explains how to convert the leveler's decisions into inferred logic links between tasks, for incorporation into a logic-tracing algorithm.  The resulting critical path (or chain) reflects the combination of logical sequence constraints and resource limits that drive the completion of the project.  With task leveling priorities, the planner has a way to force leveling decisions - and resulting driving/critical paths - that conform to an overall plan for completing the work.  This is preferred to extensive soft (i.e. non-technology-driven) logic links that are often proven wrong in practice.

Hi Tom, Trevor, 

Thanks so much for taking the time to respond to my query, its hugely appreciated.

Tom, Daryl Deffler's information which you pointed me to has been incredibly useful to me (both posts), and has really helped to explain and understand the complexities and general conciderations for MSP's levelling feature.  I wasnt taking into account slack or critical path analysis for my original post, and think this has given me a new chain of thought towards working with levelling.

Trevor, thanks also for your insightful reply. You raised some good points with regards to a slightly different chain of thought, and have also made me realise that I originally may have been over thinking the use of the "Priority" field.  I originally thought that this would be very confusing remembering which values has been used for which task (when working with larger plans), as thought i would be continuously reviewing this value for previous tasks everytime i added a new one.  But think now, I will revisit using Priority but more generally ie. 500 is non urgent 600 more important and so on.

Really grateful and thanks again for taking the time to help me!!

Perhaps it would be better to adopt a slightly different approach. It is not necessary to have an in depth or precise understanding of how the leveling algorithm works (but thanks, Tom, for the list). It may look random but there is a method in it. If you run leveling with all options turned off and get a solution, that alone is reassuring because if there is at least one solution there will probably also be more and perhaps one of them will be the one you prefer. In any case, you have no choice but to "prefer" one of the possible solutions since no others will be available. Even with just two tasks with the same resource assigned, there are at least two complete leveling solutions immediately and more might be available with some combinations of the option checkboxes (but at the cost of a bit more complexity).

When you assign priorities to tasks all you are doing is imposing your preference for one of the possible solutions, but you have to tell MSP what that preference is.

That's what priority is for, and I do not understand why you are reluctant to use it.

Steve,

Daryl Deffler wrote an excellent series of articles about just this subject last month: MPUG Leveling 2.

The scoring order is nominally:

1. Priority 1000
2. Manual tasks
3. Started Tasks
4. Predecessors
5. Slack
6. Task Dates
7. Task Constraints
8. Task Priority
9. Task Duration
10. Task ID

Most of these are straightforward, except for "Predecessors" - i.e. logic.  The algorithm there seems not well documented, and your guess is as good as anyone else's out here.  Two things are clear:

1. In MSP 2010, your leveling results (including the defined "critical" path) will change just by adding a completion milestone as a successor to the logical chains.
2. Microsoft changed the details of the leveler between 2010 and 2013 versions, leading to generally longer schedules but more stable critical paths in the later versions. (I think Daryl's examples are all based on MSP 2013 or 2016.)