Don,
I guess I should have been a little more specific. I
have 20 Level of Effort tasks. The other 980 or so are
regular tasks. The 980 will be set up without
constraints (as much as possible) and Project is going to
run through it normal calculations for leveling. It is
the 20 LOE tasks that are concerning me. Basically these
tasks pertain to Leads. Their basic function is to be
support for their people to guide, answer questions, and
the like. The initial phases of the Project they will
have to spend more time. Then as the project begins to
wind down (the last 6 months) is when their level of
support begins to decline.
These LOE tasks themselves are not linked to any
tasks other than the program start. They do not even
effect the program end date. They are basically there
for cost purposes.
I did run a little experiment as you suggested. I
had entered the data for 2 of my LOEs in the manner I
described in my first message and then leveled the
project and they stayed where I put them. Your statement
about the resource being available to me for other tasks
after Dec. '05 and planning to reduce their commitment to
the task is closer to what is happening on these 20 LOE
tasks. Being Leads after Dec. '05 they will probably
start picking up new Projects to work on or may even be
assigned tasks their subordinates were doing in order to
meet the dead line.
So after much rambling on here, it is looking like I
will just have to keep an eye on these 20 tasks to make
sure they don't start moving on me when I level.
Thanks,
Shaun
-----Original Message-----
Set up a small test case and experiment. I think your
approach may not survive leveling and/or replanning.
My philosophy is to always set up the parameters to
mimic reality and let project do its calculations, rather
than to hard-code data. The calculated, levelled plan is
a "model" of the expected project reality; you enter the
constraints and current conditions and let the modelling
engine do its thing. Like weather forecasting. If you try
to hard-code that it will rain next wednesday, then when
the circumstances change either your hardcoding will be
changed and your forecast will be wrong when you make it
rain anyway, or if you manage to force your forecast to
persdist, you' better know how to make it rain on demand!
If you KNOW it's going to rain, put in the paramters that
will make the modelling engine come to the same
conclusion. Pardon my philosophizing, can't help myself
Anyway, by setting up the constraints to force project
to produce the desired results, rather than hardcoding
the results, you have a better chance of making the
results persist through multiple updates.
If the resource is only available to your project 50%
after dec 05 then you could adjust the resources'
availability in the resource calendar. Then project will
limit the resource to half-days in all its calculations
for that timephase. If the resource is available to you
for other tasks and you're just planning to reduce
his/her commitment to task a, that's a little trickier. I
don't think project has a specific parameter to trigger
that in the future. If you're not using a resource pool
and don't mind some slightly kludgy reports, you could
create a second version of the resource (bob is assigned
at 100% til dec 05; halfbob is assigned at 50% after dec
05, and can spend the other half on other tasks). You'll
still have to make halfbob not available prior to dec,
and bob not available after.
