Resource leveling

[Rob Perry]

In our organization, we are using Project 2003, and we have one user in
particular that is having problems with resource leveling. It would appear
when he starts the process that Project is hung in a leveling operation, and
it will remain in this state for 50 minutes or more.

How can we optimize the leveling operation and get it to run in a shorter
period of time? Is it possible?

He is running on a Pentium 4, 2.4 Ghz with 1 GB of RAM, so it isn't like his
machine is out of horsepower for the product.

 

[Brian Stebbins]

Rob,

I run a Pentium 4 processor with 2.8 Ghz processor. Now, from this
computer I operate a Master consolidated project with about 20-30 inserted
projects at any given time. Combined my file can have about 200 resources
assigned to about 3000-4000 tasks. The file has about a years worth of
actuals at any given time and is a huge file.
That now explained, you should understand my concern over a leveling that
takes 50 minutes because my comp.'s specs are VERY similar to the machine
you described, and it takes ME about 5-10 minutes to level this massive
file. Therefore my only thought on this is that you either have a HUGE
project file, or there's something wrong with the MS Project installation on
that machine.
Could you provide some more information...
You said one user in particular... is he the only one with this problem or
is he just the worst?
How big is your project file?
Have you tried re-installing Project on that machine?
Provide some more information, and this newsgroup can provide more
assistance. But untill then... determine if it's only that machine, and if
it isn't try leveling a FEW of your resources at a time instead of the whole
pool. That will not cut down the TOTAL time, but he'd be able to level a
few... do some other work... level a few more... do some work... etc.
Please let us know more... and I hope SOMETHING from this post is helpful
to you!!
Thanks for your time!!

-Brian Stebbins

 

[Neil Peterson]

Howdy all,

Thanks for posting Rob, I'll add more details (since I'm the guy in
question).

My original setup was Project 2000 (pre-SP1). Usually working in the
master project file (3000-4000 tasks, 70 resources, a dozen linked
files). Time to level was around 2 minutes - about what you would expect.

As the next year's projects started planning I linked in another dozen
projects involving probably another 2000 tasks. Levelling time jumped
to 50 minutes (ouch). We started to look into this and the levelling
time dropped back to 2 minutes. Things continued fine for a couple of
days then jumped back up to 50 minutes.

For the record:
Pre-change filesize of the master project around 1.0M, and the resource
pool 3.3M. Current filesizes are 1.2 and 4.2 respectively. That
doesn't look like the bloat-corruption problem to me - it looks about
right. Out of curiosity how big is your master and pool?

Upgraded Project 2000 to SP1, with the hotfix. No obvious impact on
levelling time.

The CPU (multi-threaded) maxes out one virtual CPU, memory usage is
quite low (0.25 G).

I run a Pentium 4 processor with 2.8 Ghz processor. Now, from this
computer I operate a Master consolidated project with about 20-30 inserted
projects at any given time. Combined my file can have about 200 resources
assigned to about 3000-4000 tasks. The file has about a years worth of
actuals at any given time and is a huge file.

Funny I think of that as maybe a "big" file but not huge compared to
some that I've seen in play. The stuff I'm doing is only "medium" size
(especially without any actuals for the stuff I just added).

Could you provide some more information...

Ask away.

You said one user in particular... is he the only one with this problem or
is he just the worst?

Project is not a high-use item here. I'm probably the main user
although there are some others. At the moment there are two of us
accessing the file in question (via a source control system). The other
person rarely opens the files but we were using his system yesterday for
a brief moment. The levelling operation he did went VERY fast (around 5
seconds!) and produced incorrect results [low priority tasks scheduled
before high]. We haven't yet had time to dig into that and see if it is
related or has more to do with the source control and linked files, etc.

How big is your project file?

See above.

Have you tried re-installing Project on that machine?

Attempted to install SP1 (had an install error). Uninstalled Project.
Re-installed with SP1 and hotfix - I think it may actually be slower now.

Provide some more information, and this newsgroup can provide more
assistance. But untill then... determine if it's only that machine, and if
it isn't try leveling a FEW of your resources at a time instead of the whole
pool. That will not cut down the TOTAL time, but he'd be able to level a
few... do some other work... level a few more... do some work... etc.

Actually I'm doing the "make a few changes, start levelling, go to a
meeting or two, come back, repeat" process. Not good but I am limping
along. In the mean time trying a range of activities to see if I can't
spot the problem.

Neil Peterson
Project Manager
Maplesoft

 

[Jan De Messemaeker]

Hi,

He has assigned a resource to both a task and its summary task and then said
"Skip all" when asked for it.
DO NOT ASSIGN RESOURCES TO SUMMARY TASKS

Other nice impossibilitie to confront leveling with
- Giving a resource a max Units of 0%
- Contouring a resource's availability to be 0 after a certain date (a
temporary collaborator f.i.) then ask leveling to level work for the guy
after that date

Leveling "hanging" or rather, shifting work to the end of the calendar is
ALWAYS a mater of askiung the impossible, with leveling trying very very
hard for well, yes, 50 minutes.

HTH

 

[Neil Peterson]

He has assigned a resource to both a task and its summary task and then said
"Skip all" when asked for it.

No. I just did the fast scan and no summary tasks have resources
assigned. This situation (which I have done before -- usually when
adding subtasks while promoting a task to a summary task) causes a
pop-up window to appear with information about overallocation.

Other nice impossibilitie to confront leveling with
- Giving a resource a max Units of 0%

Not relevant to us (all scheduled resources are non-zero). Also note
that this would not account for the pattern I posted in my followup to
Rob's post.

- Contouring a resource's availability to be 0 after a certain date (a
temporary collaborator f.i.) then ask leveling to level work for the guy
after that date

Commonplace here. We also employ co-op univeristy students who do 4
month work terms. With a nice complex project with loads of
dependancies having a co-op whose last couple of tasks get pushed past
their end date happens to me at least once a week.

Symptoms produced, however, are quite obvious (a pop-up window
indicating overallocation on the first non-working day for that
resource) and easily corrected. So this also cannot be the problem.

Leveling "hanging" or rather, shifting work to the end of the calendar is
ALWAYS a mater of askiung the impossible, with leveling trying very very
hard for well, yes, 50 minutes.

Wonderful. So in some way I was asking the imposible (or rather "hard
enough to require 50 minutes to reset only 2000-3000 tasks).

The problem is that each of the ways you defined MS project has an
answer -- a pop-up appears -- which did not occur in these cases. Can
you provide a situation where that pop-up does not appear?

Neil

 

[Neil Peterson]

To address the problems I was having we have upgraded to Project 2003.
No more insanely long leveling times -- YEAH!

I am noticing, however, that the leveling that is happening is not
matching my expectations.

My guess is that this is caused by a new or changed setting in Project
2003 which I don't know about.

Can anyone point me to a good page with more info about leveling
(specifically for 2003) than the on-board help provides?

Neil Peterson
Project Manager
Maplesoft

 

[Steve House [MS Project MVP]]

In what way is it not matching your expectations? That can cover a lot of
territory <grin>. What are you expecting and what is Project doing instead?

There's no a whole lot of esoterica involved, really. Leveling delays work
to resolve resource overbooking and delaying work is all it does. When a
resource is booked on two or more tasks occuring at the same time or
partially overlapping in such a way that his total allocation at any given
instant exceeds his maximum allowed allocation, some of those tasks must be
delayed to resolve it. The exact algorithm Project uses to decide which
task(s) to delay is proprietary but the general factors are documented in
help. If you have a preferred sequence where it's more important for Task X
to be done earlier than it is for Task Y if they can't be done together, you
can insure Y is the one delayed rather than X if one of them has to move by
setting a priority on the tasks, the higher the priority the harder Project
tries to keep it first in line if you tell it to pay attention to the
priority setting. The level on "day-by-day" "hour-by-hour" "
minute-by-minute" etc setting determines the smallest time interval of
overlap that Project will worry about when it runs the leveling process.

Although Project won't prevent you from doing it, a single individual should
NEVER be allocated more than 100% at any point in time since that means he
can somehow magically produce more work output from a task than the time he
puts in on it -- for example, an allocation of 125% on a 1-day duration task
means that somehow in the course of working just 8 hours he can do 10
man-hours of work, a rather super-human feat and something that physically
just can't happen.

 

[Jan De Messemaeker]

Hi Neil,

Simply, bluntly, No sorry, never seen.

 

[Neil Peterson]

In what way is it not matching your expectations?
That can cover a lot of territory <grin>. What are you expecting and
what is Project doing instead?

Well the example I use was a task with a priority of 500 being scheduled
before a 700 (when their predecessors/successors should allow the
priority order to be used).

A couple of things should be said though:

1. It appears the root cause of my problem was file corruption which
appears to be 90% resolved. It is certainly possible this had an impact.

2. I was/am commenting on something fairly abstract that I noticed while
dealing with a range of issues (corruption, version upgrades). So it
was more a "feeling" and less a list of specifics. (20 projects in a
master involving many thousand tasks -- the schedule I had seen in
Prj2000 was not the same as what Prj2003 was showing me -- but
specifics? much more work to locate, minimalize, and ask about).

Combining these two led to the request for reading material rather than
"help" for a specific "problem".

General observations (subject to the caveats above - Your experiences
may differ).

1. 2003 seems to pay more attention to deadlines when scheduling then
2000 used to. (Note that this is barely mentioned in the help)

2. Setting the leveling option to "priority,standard" instead of
"standard" moved it much closer to what I had expected. "standard"
appeared to be ignoring the priorities.

3. It is interesting that the File menu's recent files list seems to
show the last files SAVED rather than the last files opened. (i.e.
open my master file, open the resource pool as read/write using the
pop-up dialog, hit save, open the file menu -- notice that the master
file is not listed in the "recent" files)

4. It would have been nice if my macros/tables/views in global.mpt would
have transfered over as part of the upgrade. mvps.org had a solution to
this in the FAQ which was nice and worked fine. (Although I would change
the wording a bit. I "followed" the instructions and opened
tools/organizer and then spent time trying to figure out why the other
..mpt files wouldn't appear in the pull down boxes on the bottom before I
tried a "file/open" on the old .mpt file -> which brings up the
organizer .... wording can be so crucial)

Random observations from a PM under change.... not anything that needs a
"solution".

Neil Peterson
Project Manager
Maplesoft

 

[Steve House [MS Project MVP]]

Comments on your first two points -

I don't think 2003 actually pays more attention to deadlines that 2000 - as
far as I can tell the behaviour of the two versions is identical. Neither
one actually uses deadlines in scheduling as such. If a task gets pushed
past its deadline, regardless of how it comes about, both versions let it go
where it will and then red flag the missed deadline in the indicator column.
When a deadline date is on one or more tasks and you are resource levelling
with the "level only within available slack" flag turned on, the deadline
date is used to calculate available slack so that levelling won't delay a
task past that point - the working definition of slack time becomes "the
amount of time the task could be delayed before it or a subsequent task is
delayed past a deadline, or the project finish is delayed." Slack time in
projects with deadlines on some of the tasks is calculated exactly the same
as if those same tasks had Finish No Later Than constraints applied to them
instead but they're scheduled as if one turned off the "task will always
honour their constraint dates" setting.

If you want priority settings to have any impact on the levelling, you do
indeed have to turn on the "priority, standard" option in the levelling
screen. Again, this is as it's always been. Unless priority is explicitly
included in the levelling algorithm the settings are ignored.

Your first comment makes it sound like you expect priority would be used in
scheduling per se but it's not. It ONLY has effect in resource levelling,
determining which tasks out of an overlapping set of tasks get delayed by
the levelling engine if one or more of them must be delayed to resolve a
resource overallocation. If there are no resource allocation problems
and/or you aren't running the levelling tool at the moment, the priority
doesn't enter into the picture at all.

I'm also wondering about your anomalous behaviour levelling tasks with
priority. You mention you are working with a master project with
subprojects. Remember that not only do TASKS have priority but so do the
projects themselves. A 500 priority task in an 800 priority project will be
scheduled before an 800 priority task in a 500 priority project by the
resource leveling process. Could this be the cause of the behavior you're
seeing?

 

[Jan De Messemaeker]

Hi,

This only to complete Steve's very accurate answer to the questions:

Even with "Level only within available Slack" off, deadlines do influence
leveling priority.
Indeed, as Steve very rightly points out, they influence Total Slack and
since Total Slack is the main component of the "Standard" priority
aggregate, deadlines do influence leveling order whatever the setting.

HTH

 

[Neil Peterson]

I'm also wondering about your anomalous behaviour levelling tasks with
priority. You mention you are working with a master project with
subprojects. Remember that not only do TASKS have priority but so do
the projects themselves. A 500 priority task in an 800 priority project
will be scheduled before an 800 priority task in a 500 priority project
by the resource leveling process. Could this be the cause of the
behavior you're seeing?

I hope not. I have not set project priorities (which does not mean that
one didn't wind up getting set during one of the corruptions). I should
go review all of the files involved. Mind you since I haven't had this
problem in a week or more its more likely it was corruption-based.

Personal observation: The project priority appears to be too rigid for
me to use. In the world I work in I simply can't forsee ever saying
"even the lowest priority task in this project is more important than
the highest priority task in all of my other projects". I'll stick to
using just task priorities. Now if the project and task priorities were
actually combined with an algorithm that didn't trivialize the task
priority (say Adjusted task priority = (Prj.Priority - 500) + task
priority) then I would likely wind up using it someday. (and yes I can
do this myself converting priority to a custom field using two other
fields for project priority and task priority -- I've just got other
things on my own priority list)

Things seem to be stable now so I did want to say "thanks" to everyone
who offered suggestions.

An extra thanks for the discussion on the deadline/slack time/leveling
connection [not mentioned in the help pages]. It is information of this
type that I was looking for in my original request for reading material
that goes into some depth on calculation/levelling.

Neil Peterson
Project Manager
Maplesoft

 

[Jan De Messemaeker]

Tnx for the kind words on the end.You're welcome!

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/index.htm
32-495-300 620

I'm also wondering about your anomalous behaviour levelling tasks with
priority. You mention you are working with a master project with
subprojects. Remember that not only do TASKS have priority but so do
the projects themselves. A 500 priority task in an 800 priority project
will be scheduled before an 800 priority task in a 500 priority project
by the resource leveling process. Could this be the cause of the
behavior you're seeing?

I hope not. I have not set project priorities (which does not mean that
one didn't wind up getting set during one of the corruptions). I should
go review all of the files involved. Mind you since I haven't had this
problem in a week or more its more likely it was corruption-based.

Personal observation: The project priority appears to be too rigid for
me to use. In the world I work in I simply can't forsee ever saying
"even the lowest priority task in this project is more important than
the highest priority task in all of my other projects". I'll stick to
using just task priorities. Now if the project and task priorities were
actually combined with an algorithm that didn't trivialize the task
priority (say Adjusted task priority = (Prj.Priority - 500) + task
priority) then I would likely wind up using it someday. (and yes I can
do this myself converting priority to a custom field using two other
fields for project priority and task priority -- I've just got other
things on my own priority list)

Things seem to be stable now so I did want to say "thanks" to everyone
who offered suggestions.

An extra thanks for the discussion on the deadline/slack time/leveling
connection [not mentioned in the help pages]. It is information of this
type that I was looking for in my original request for reading material
that goes into some depth on calculation/levelling.

Neil Peterson
Project Manager
Maplesoft