0

I have set Leveling Order to be Priority, Standard. Therefore I expected the hierarchy of leveling tests to be as follows

  1. Is the Priority of any of the contending tasks 1000?
  2. Are any of the contending tasks Manually scheduled?
  3. Have any of the contending tasks actually started?
  4. Which of the contending tasks has highest Priority?
  5. Are any of the contending tasks Predecessors to other tasks?
  6. Which of the contending tasks has the LEAST Total Slack?
  7. Which of the contending tasks has the earlier Start date?
  8. Do any of the contending tasks have date constraints set?
  9. Which of the contending tasks has the longest Duration?
  10. Which of the contending tasks has the lowest ID?

My schedule consists of about 50 projects each with 5 sub-tasks. Each project has a unique Priority Score with the highest being 950. All sub-tasks for a project share the same Priority as the project, and each Project sub-task except the first has a predecessor to determine its dates. All projects are independent of each other. No project of sub-task has a Priority of 1000 and none are Manual and none have an Actual start date.

Given the above, I expected that Total Slack (item 6) would be irrelevant in my case as I thought Priority and Predecessors (items 4 and 5) would always be sufficient to resolve any resource contentions.

However I have at least 2 instances where this is not working as expected. In these cases sub-task A has a higher Priority than sub-task B, it is a Predecessor of another sub-task (as is sub-task B), but the available resource is being allocated by Leveling to sub-task B rather than sub-task A.

I have noticed that the Total Slack of B is lower than that of A. In my case, given my schedule consists of 50 independent projects, Total Slack is not relevant, but of course Project does not "know" that. However, with the above hierarchy (with Priority near the top) and given the Priority of A is higher than that of B, the "Total Slack" test should never need to be applied, should it? All leveling should be determined by tests 1-5. Or am I misunderstanding how this should work?

Thanks for any insights you can offer.

Eric

Eric
  • 111
  • 6

1 Answers1

0

Beyond the excellent article on the subject by Daryl Deffler over at MPUG.com (which it appears you've read), there's not a good answer. The leveling calculations (and the rules themselves) in MSP are much more complex than implied by the relatively straightforward hierarchy, and they do change from version to version. (Look for some PhD dissertations on resource-constrained scheduling.) In particular, I believe the characterization of a leveling decision as the result of sequential binary tests (i.e. tie-breakers considering two tasks at a time) is an oversimplification for real-world schedules. In your case I would suspect that the relative positions of your two tasks are influenced by calculations involving one or more other tasks in addition to A and B. You could probably get what you want (A before B) by raising the priority of A and dropping that of B. You could most certainly get it by imposing a logic link between them. At the end of the day, MSP's leveling engine is a black box that provides "good enough" results with minimal user control. Most folks leave it at that.

Tom Boyle
  • 1,031
  • 7
  • 7
  • Thanks Tom. I have indeed read that article, and several others. I kind of expected an answer like yours, but I did hope there would be a simple answer that i had overlooked. Unfortunately due to what I am trying to achieve I can't simply revise the priorities or create notional predecessor relationships. It looks like I will have to do some manual intervention after each re-leveling, which is a pain. But thanks again for your input. – Eric Jan 29 '19 at 09:51