Leveling reference

[Scott McClure]

Could someone please recommend a reference work that would help us
understand leveling with multiple, complex projects and the effects of
priorities? PS and Pro 2002.

Thanks,
Scott

 

[Trevor Rabey]

there is not a lot to understand about levelling. it doesn't really warrant
any reading. except this:
tasks get delayed to eliminate resource conflict. higher priority tasks get
delayed after lower priority tasks. that's it.

 

[Mike Glen]

Hi Scott,

Welcome to this Microsoft Project newsgroup

There a number of reference in FAQ Item: 40. Project 2002 Books and
References, most of which will cover the basics of levelling. FAQs,
companion products and other useful Project information can be seen at this
web address: http://www.mvps.org/project/.

However, you might like to read something I penned a while back:
-------------
As a matter of interest, some 20 years ago, I attended the launch of
Computer Associates' Superproject for Windows. At the end of the
presentation I asked if he would tell us the algorithm that they used to
determine the levelling process. He looked me in the eye and said: "That's
propriety information - next question please?" This part of the scheduling
engine that make one product different from another, and thus a jealously
guarded secret! However, one can make some educated guesses - Project
obeys the logic linking and starts at the first minute of the project
looking down the task list to see if there's any overallocation. It will
then look at the slack and delay a non-critical task in of a critical
task. If there is more than one non-critical tasks overallocated, it will
delay the one with the most slack first. And so on... And then the trail
stops - what if there are 2 critical tasks, which one gets delayed? My
guess is the one with the highest Task ID as there is an option to level by
ID Only. Now consider there being more that one resource assigned - which
one gets delayed? Again my guess is the resource with the highest Resource
ID. I'm sure you can see how complicated the algorithm can become with
multiple resources assigned! Nevertheless, this knowledge, plus the use of
priorities, give us plenty of scope for tailoring levelling to optimise our
requirements should we so desire."
-------------------

Hope this helps - please let us know how you get on

Mike Glen
Project MVP

 

[Scott McClure]

Thanks Mike. Sure wish it was as simple as the previous post but 'aint so!
Just trying two projects, 4 tasks each (all staying at 500 and of course in
the same time frame) and one resource points this out. It's pretty hard to
predict how things will come out with changes to the Project priority.

Keepin on...

Scott

 

[Mike Glen]

Yes, Scott, the mysteries of levelling! However, I think the important
point with levelling lies in the outcome. Is the outcome acceptable? If it
is, go with it! If not, that's when you try changing things like
priorities, or ID order or whatever, until you get an acceptable result.
The whys? are somewhat academic and you could spend years trying to fathom
it out.

Mike Glen
MS Project MVP

 

[Scott McClure]

Thanks Mike,

The problem with the trial & error method is that we have five projects
going to schedule 300 mechanics with about 250 tasks each so not being able
to predict what will happen means an awful lot of experimentation. I don't
believe we have time to try all of the combinations. Our goal is to make
Project understand our work so that we can start to predict and measure how
we're doing. If we can't understand Project, we don't know what to "teach"
it.

We will, however, keep trying...
Scott

 

[Mike Glen]

OK Scott - the best of luck! If it's any consolation, this is a problem all
project planners are paid for and it's not limited to a Microsoft product!

Compliments of the season!

Mike Glen
MS Project MVP