Jeff, sometimes a response may be longer than absolutely required by your
question because you are not the only one who is reading it. When I respond
to a question, I try to address it to everyone who might be reading the
newsgroup and not just the instant poster, hence the inclusion of
information that you personally may already be aware of.
The problem is that the term "Critical Path" according to CPM (whose
principles MS Project is written to comply with as much as possible, as far
as I can tell ) has very precise technical definition that is far more
constrained than your use of the term. To the best of my knowledge it deals
*only* with the total duration of the project and has nothing to do with the
importance of deliverables. It is rightly applied only to tasks and
deliverables that lie on the single path out of all the parallel paths
through the project that has the longest duration. If the time on the
pathway to produce a particular deliverable is not a determinant of the
total project duration, that is, when the last step in completing a certain
deliverable has a float > 0, the deliverable does not lie on the critical
path and there is not such thing as a "critical path" leading to it. The
sole determinant of the critical path is that tasks on it have a float
greater than zero when referenced to the terminal milestone of the project.
I never said there are no critical paths leading to deliverables. Some of
the deliverables will lie on the longest path through the entire project and
others will not. Only the ones that lie on the project's critical path will
have a critical path leading to them. I suppose it would be theoretically
possible that a project could have several parallel paths between the start
and finish milestone that are *exactly* the same duration but it isn't very
likely in the real world.
Imagine completely independent deliverables A, B, and C each at the end of
paths that diverge from each other when the project begins (Start milestone
S) and never reconnect. 3 paths, S->A, S->B, S->C. Production of
deliverable A takes 5 days, B takes 10 days, and C takes 15 days. The
appearance of multiple critical paths, one leading to A, another to B, and a
third to C is an illusion because this model leaves out the mandatory 5th
task, the finish milestone F, which should be included with links going A->F
and B->F as well as C->F. So in fact, the 3 paths through the project are
S->A->F, S->B->F, and S->C->F and there is only 1 critical deliverable and 1
critical path in this project, S->C->F.
You say the deliverables are constrained to finish by the date the customer
needs it. Of course they are and nothing I said contradicts that or
suggests that you should ignore it or even publish a schedule that shows
finish dates anywhere except those mandatory dates - note the operative word
"publish". A key point I find is often missed is that a "constraint" in MS
Project DOES NOT refer to or model those contractual constraints on your
project. A constraint in MSP is something totally different and unrelated
to those contractual obligations. It's a limitation on what the calculating
engine is allowed to do - period. A "MFO" constraint means that Project
will lie to you and tell you everything is peachy and the milestone will
occur on the desired date *even when* it is absolutely and positively NOT
possible to make your deadline with the tasks planned out they way they are
in the present schedule. The MFO constraint is telling Project "I don't
care if I'm not really going to make it on time, put it on the Gantt chart
on that date anyway!" It means that Project will ALWAYS show that task on
its constraint date regardless of anything else in the project plan that
might try to drive it off of that date. Is that really what you want, or do
you want the software to tell you when there's a problem on the horizon with
enough lead time so you don't come up the day before the deadline date with
the milestone sitting right on it showing finishing right on time and
discover - surprise surprise - that there are really 6 more weeks of work to
do? I suggest it's far more useful if it gives you that information, by
telling you where the task milestone will actually land with the current
predecessor scheduling and show you how that relates to the deadline
established in your contracts, so you can revise the schedule in time to
actually make a difference and have a hope of meeting the deadlines. The
purpose of Project is not just to illustrate what your deadlines are, it's
to give you a predictive model that will respond to inputs of variables like
resource allocation, etc, so as to allow you to develop the optimum strategy
that will actually hit those deadlines. Simply declaring that you will
finish on a certain date does not make it so. To do that, Project has to be
able to freely calcualte so as to predict for you what the results will be
on the milestones IF you go with the schedule as currently modeled and what
will happen to them when you change something like how many widget polishers
are assigned to the polishing task. It won't do that for you if you tell it
not to by using MFO constraints.
--
Steve House [MVP]
MS Project Trainer/Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
An old friend of mine used to give me grief