Scheduling/leveling a master project with multiple sub-projectsinserted (long read/questions)

[Mike]

Hi all,

I have a few questions about the best practices and settings for
scheduling/leveling in Microsoft Project (specifically 2k7.) I
recently changed companies and I have found that much of what they do
with Project seems, well.. pretty much wrong. I'll explain how we
work with Project currently, then ask specific questions after my
summary.

Currently at the company (an IT Software/database company) we have ~30
projects (or thereabouts), which we insert into one big master
project. We manage each of the projects individually, each project
being assigned to one of ~5 different PMs. Each sub-project uses only
Enterprise pool resources, we do not allow local resources to be typed
in or used... so each project in the Master project shares the same
pool of resources.

Project 2k7 is currently setup to do "Automatic" calculation in the
application's options (default is Manual). The leveling options are
set for manual, priority set to "Priority, Standard", and the only
checked option is "Leveling can create splits in remaining work."

Now, here is the kicker. From our management, we are only allowed to
use one constraint type, which is "Must start on." Everything else
must be set to "As Soon As Possible." We do use predecessors,
although the templates we're required to use have a lot of bad logic.
We're told to zero out the remaining hours of tasks we don't use in
the template, not to delete them.

So a couple times a week, our management asks us to "run the
master" (ie - schedule and level everything in the master project.)
The results, as some may have guessed, are sporadic at best. Since
we're not allowed to use "must finish on" or "finish no later than"
constraints, tasks are all over the map. For example, this week
requirements gathering will be finished on one of my projects. There
was an hour left of requirements gathering on a single task, which,
after that was complete the next phase of the project would begin.
However, the scheduling engine scheduled that remaining hour to occur
in September, thus pushing my entire schedule out for the next phase
and beyond to start after that task in September.

This is happening all over every sub-project in the master. Tasks are
split and pushed out into whatever date the scheduling engine thinks a
task needs to be done. Recently management decided that the way to go
about fixing this was to start putting priorities on all projects and
tasks. So now we're going through each task and trying to guess what
priority to make it, to force the scheduling engine to schedule it
sooner.

A side effect of this method is that we don't really know when
resources in the future are over-allocated. We may have a date in the
future, say 6 months from now, where 5 tasks MUST be done in a single
week, with a single resource that could be booked for 100 hours in
that single week, but since we use "asap" constraint type and let the
engine just flatten it out and push the schedule, we don't really know
that.

One other side effect of the scheduling/leveling we're doing is that
it continually reallocates resources. I can type a resource in and
say I want them at 75% allocation, but after the scheduling/leveling
engine is done, that resource might say 13% allocated, or 150%, or
even 4000%.

Naturally, the project teams that are trying to use the project plan
as a schedule are dismayed. They don't even look at the project plan
anymore, and many have in fact created their own "milestone" charts in
a regular word document just so they can keep track in their own mind
when something is coming up on a project. Which, I can't really blame
them.. in fact I've encouraged it, as my pleas to alter some of our
practices have fallen on deaf ears so far.

So, if you've read all of that, here are my questions:
1) Of the documentation I've read, scheduling calculations should be
manual, not automatic. Is that true? What are "best practice"
settings for the Project schedule/level engine?
2) Is there a way to prevent resource allocations from being changed,
or is that a function of our calculation being automatic?
3) If a project is being resource driven, is that a valid reason *not*
to use Finish constraint dates on the few tasks that we *know* need to
be finished on particular days?
4) Are there any other ways (of which I'm not thinking) that we can
use the scheduling/leveling engine to make our schedules look right,
*without* using normal constraints? Does anyone see any good reason
to withhold using the various constraints as necessary so the schedule
is correct?

Once again, if you've read all of this, thank you for your time.

Mike

 

[Jack Dahlgren]

You have a number of things going on. I can't completely untangle them but
here is a start.

1) Calculation mode (tools menu / options / calculation tab) is best set at
automatic. Without this the schedule does not recalculate according to
changes in task durations or dependencies. This should not have an effect on
resource leveling that I can foresee.

2) Resource leveling does not change resource allocations on individual
tasks. It attempts to "level" that allocation to the maximum set for each
resource. It does this by changing when the tasks are scheduled. If resources
are still over allocated then leveling is not doing its job. Perhaps the
people are over assigned on single tasks - leveling can't fix that. Perhaps
the leveling options are preventing it from working.

3) Yes. A must finish on constraint limits the usefulness of the tool for
calculating or predicting a "realistic" schedule. Imagine in excel you set a
formula to sum a column of numbers, but also had a formula which set the
total to be no more than 100. If the number added to more than that amount,
then the sum would no longer be an actual sum. What you "want" to happen is
different from what will happen given a plan and a limited set of resources.
The PM's job is to figure out how to get what needs to be done by that fixed
date with the resources they have - or get more - or renegotiate the date.

4) As mentioned above, constraints are generally perceived as limiting the
use of a critical path schedule. You will find many people who recommend
against their use. I use them only in a small set of circumstances. Just
because they exist doesn't mean you have to use them in a schedule. Try using
the deadline feature. It gives you what is effectively a soft constraint. Of
course, if there is bad logic in your schedule then that needs to be fixed as
well. But bad logic shouldn't be a reason for the heavy handed use of finish
constraints.


-Jack Dahlgren

 

[Mike]

You have a number of things going on. I can't completely untangle them but
here is a start.

1) Calculation mode (tools menu / options / calculation tab) is best set at
automatic. Without this the schedule does not recalculate according to
changes in task durations or dependencies. This should not have an effecton
resource leveling that I can foresee.

2) Resource leveling does not change resource allocations on individual
tasks. It attempts to "level" that allocation to the maximum set for each
resource. It does this by changing when the tasks are scheduled. If resources
are still over allocated then leveling is not doing its job. Perhaps the
people are over assigned on single tasks - leveling can't fix that. Perhaps
the leveling options are preventing it from working.

3) Yes. A must finish on constraint limits the usefulness of the tool for
calculating or predicting a "realistic" schedule. Imagine in excel you set a
formula to sum a column of numbers, but also had a formula which set the
total to be no more than 100. If the number added to more than that amount,
then the sum would no longer be an actual sum. What you "want" to happen is
different from what will happen given a plan and a limited set of resources.
The PM's job is to figure out how to get what needs to be done by that fixed
date with the resources they have - or get more - or renegotiate the date..

4) As mentioned above, constraints are generally perceived as limiting the
use of a critical path schedule. You will find many people who recommend
against their use. I use them only in a small set of circumstances. Just
because they exist doesn't mean you have to use them in a schedule. Try using
the deadline feature. It gives you what is effectively a soft constraint.Of
course, if there is bad logic in your schedule then that needs to be fixed as
well. But bad logic shouldn't be a reason for the heavy handed use of finish
constraints.

-Jack Dahlgren

















- Show quoted text -

Jack,

Thank your the response. I guess the major point with which I
disagree, is that I view many of our plans as "hybrids." For example,
I want the scheduling engine to figure out when things can be done for
the most part. However, there are a couple tasks in every plan which
actually do have real dates. When our database gets published to our
customers, that's a deadline we must meet. However, the tasks leading
up to that publishing can float around depending upon the resources we
have. Hence, I don't view that as a "heavy handed" use of finish
constraints.

Also, can you be a bit more clear on the allocation % of resources?
Why would the engine allocate a resource at 4000%, for example? Is
there a way to prevent it from changing my allocation of a resource?

Thanks again for your time thus far,

Mike

 

[Jack Dahlgren]

Use a deadline for the "real" date. You can then see if it is possible or not
given the current schedule. If your schedule is past the deadline then you
have a problem YOU need to address. Putting a constraint on that task so it
happens in your Microsoft Project schedule is not an appropriate response to
the issue.
If you do that then please play attention to the total slack for all the
tasks leading up to it. Negative slack indicates you are late already. If you
don't know what slack is or how it is calculated, then you are probably not
ready to use any sort of constraint in your schedule.

The scheduling engine does not assign resources. You do. Sometimes people
can change the duration of a task and the units (allocation) can shoot
upwards. If you have constraints in your schedule, project will do its best
to level, but if it runs into a constraint then resource allocation may spike
as tasks pile up against it. In either case it is an indication with a
problem with your schedule. Constraints make it much more difficult to level
resources and to troubleshoot when the results are not what you expect.

Constraints are for the most part artificial in nature. In your case they
represent a commitment that you have made. Your schedule (through
overallocation) is telling you that you will not meet that commitment. Why
would you choose to ignore what the schedule is telling you?

-Jack Dahlgren

 

[Mike]

Use a deadline for the "real" date. You can then see if it is possible ornot
given the current schedule. If your schedule is past the deadline then you
have a problem YOU need to address. Putting a constraint on that task so it
happens in your Microsoft Project schedule is not an appropriate responseto
the issue.
If you do that then please play attention to the total slack for all the
tasks leading up to it. Negative slack indicates you are late already. Ifyou
don't know what slack is or how it is calculated, then you are probably not
ready to use any sort of constraint in your schedule.

The scheduling engine does not assign resources. You do. Sometimes people
can change the duration of a task and the units (allocation) can shoot
upwards. If you have constraints in your schedule, project will do its best
to level, but if it runs into a constraint then resource allocation may spike
as tasks pile up against it. In either case it is an indication with a
problem with your schedule. Constraints make it much more difficult to level
resources and to troubleshoot when the results are not what you expect.

Constraints are for the most part artificial in nature. In your case they
represent a commitment that you have made. Your schedule (through
overallocation) is telling you that you will not meet that commitment. Why
would you choose to ignore what the schedule is telling you?

-Jack Dahlgren








- Show quoted text -

First off, it is very difficult to give an entire context of the
company and how we're using project in a usenet post. You'll have
to trust me on some level that I do know what slack time is, I do know
how to use project, and I'm trying to find the best method to get us
through what I see as a poor attempt at trying schedule-based
planning.

We are doing all scheduling/leveling via the Master Project, with all
sub-projects inserted into it. You are correct, we have scheduling
problems. The real issue is that the company is not mature enough (ie
- they don't want to dedicate the time) to having the constrainted
resources sit down with the PMs to resolve every scheduling issue from
the master plan.

If one of my projects had a dedicated team, it would be pretty
simple. However, because nearly every person is assigned to every
project in our list of projects, finding scheduling issues is an
ongoing nightmare. When you schedule/level the master plan, it might
schedule an hour meeting that, in reality, will take place tomorrow,
and push it into October. So the only response I have is to bump the
priority of that meeting to something high, or the scheduling engine
doesn't care when that hour meeting is really supposed to take place.
Unfortunately, playing the "reprioritize" game among 12,000 tasks in a
master plan with 30 projects isn't that fun. If the company had the
political will or the knowledge, we would sit down with the resource
managers and resources and work through every plan and task that might
cause an issue, but that will not happen here.

Hence, my position that we may, in the meantime, need to use
constraints on certain tasks that we know are key to delivery. In
that manner we would see immediately if our two DBA's are assigned to
200 hours of work in the same week, and figure it out now, rather than
stumble upon that fact the week before that date hits.

The other thing to keep in mind is that this attempt at schedule-based
planning was in place before I arrived. I am now trying to pull
myself out of a swamp of 30 project plans, none of which say anything
close to what the real schedule is. I don't have a lot of weight
here, so it's not exactly likely that I can start pulling plans out of
the master until the schedule looks right, and I don't have the
autonomy to recommend an alternate course of action.

I guess I'm curious if anyone else has any comments at all. While I
appreciate your replies (Jack), I'm not certain we're communicating
well regarding what I believe the problem to be. In a perfect world,
you are absolutely correct regarding the scheduling conflicts.
Unfortunately, the world in which I currently sit.. is going to keep
throwing me these scheduling conflicts, and I have to find a way to
make my plans useful in the wake of all of the conflicts that are
thrust upon me.

Kind regards,
Mike