Critical Path

[Vincent Isoz]

Hi

I would like to know if there is a way in MS Project to differentiate de
Critical Path calculated with de CPM method and the critical path dependant
to the tasks defined with constraints "Must Start On" and "Must Finish On"

Thanks for your help

best regards

 

[Rod Gill]

Both are the same. if you set must constraints you change the critical path.
it is all the same calculation. CPM takes must constraints into account.

 

[davegb]

Both are the same. if you set must constraints you change the critical path.
it is all the same calculation. CPM takes must constraints into account.

--

Rod Gill
Project MVP
Visit www.msproject-systems.com for Project Companion Tools and more

Other than the "takes must", I agree with Rod completely.
Constraints often define the CP. That's one of the reasons most of us
advise people to minimize the use of constraints, among others.

 

[Vincent Isoz]

Ok thanks for your answer.

Other than the "takes must", I agree with Rod completely.
Constraints often define the CP. That's one of the reasons most of us
advise people to minimize the use of constraints, among others.

 

[Steve House [Project MVP]]

Careful with Must Start On or Must Finish On constraints. Those constraints
are not how deadlines are expressed. MSO or MFO means the task WILL take
place on those designated dates, engraved in granite, and will take place
then no matter what we do, or even IF we do anything. Such things are few
and far between in the real world - an eclipse of the sun, maybe, but not
much short of that. Most of the time when someone uses an MFO constraint
they're trying to say "You need to have it done by then or you're fired!"
and that's not what it means at all.

 

[davegb]

Careful with Must Start On or Must Finish On constraints. Those constraints
are not how deadlines are expressed. MSO or MFO means the task WILL take
place on those designated dates, engraved in granite, and will take place
then no matter what we do, or even IF we do anything. Such things are few
and far between in the real world - an eclipse of the sun, maybe, but not
much short of that. Most of the time when someone uses an MFO constraint
they're trying to say "You need to have it done by then or you're fired!"
and that's not what it means at all.

I have to disagree with you here, Steve. If my boss tells me "You need
to have it done by then or you're fired!", I'd put a MFO constraint on
it without question. These things are very subjective!

 

[Steve House [Project MVP]]

My issue is the constraint tells project where to place the task. A task
will finish whenever it finishes, not when we want it to and it's not simply
a matter of will power that determines it. I cannot simply declare that "XX
will happen on May 1st" and have my declaration be sufficient to make it so.
There are a lot of factors that control where it ends up. The project plan
is not a description of what we want - it is a model that predicts what
we're going to get. IMHO, it's primarily a tool for "what if" analysis to
predict where we're going to end up *if* we organize the work in such a way.
As such I don't want it to fib to me and tell me that we're going to hit our
deadlines even if I've organized the work in such as way as to make it
impossible to do so and that's what an MSO or MFO contraint does. It's a
command to Project to place the task on such and such a date and leave it
there no matter what. As a result, it will show us doing that task on time
even if it is absolutely impossible for it to really happen that way
according to the way we have organized the rest of the work.

In order for a task to finish on the date the boss has mandated that it must
finish, I have to do something concrete with the driving forces in order to
make it so. Project's job is to tell me whether or not my manipulations are
going to be succesful, not just reassure me they will be whether they
actually are going to be or not. Deadlines desribe when tasks ought to
finish, MFO constraints describe when they will finish and should only be
used when that is an accurate description of predefined physical reality.

Here's a simple experiment to illustrate my point. Create a project file
starting Monday May 1st. Give it three tasks - a start milestone, task X
with a 5 day duration, and a finish milestone. The boss has mandated we
finish by the end of
Friday the 5th so put a MFO constraint of 5pm, 5 May on the finish
milestone. Assign Joe at 100% to task X. So far so good. Now imagine
Joe's boss comes to us and says "Sorry, you can only have him 4 hours a day"
so we must edit his assignment to 50%. Now the task extends to 10 days but
what happens to the finish milestone? Not a thing! It still sits there on
the 5th, locked into position by the MFO constraint, still telling us we're
okay and are finishing right on time! But are we? Not on your life - the
predecessor task that should be driving the milestone's predicted finish
date is only half done and yet the milestone is happily promising the boss
that everything is just peachy. Obviously this is a project plan that has
no relationship whatsoever to objective reality and is totally useless as a
predictive planning model. For this to be a useful model we need to see
what actually happened to the finish milestone when we were forced to reduce
Joe's allocation - that's the only way we can see if any remedies we might
try to apply are going to be successul and the MFO constraint hides that
reality from us.

 

[davegb]

My issue is the constraint tells project where to place the task. A task
will finish whenever it finishes, not when we want it to and it's not simply
a matter of will power that determines it. I cannot simply declare that "XX
will happen on May 1st" and have my declaration be sufficient to make it so.
There are a lot of factors that control where it ends up. The project plan
is not a description of what we want - it is a model that predicts what
we're going to get. IMHO, it's primarily a tool for "what if" analysis to
predict where we're going to end up *if* we organize the work in such a way.
As such I don't want it to fib to me and tell me that we're going to hit our
deadlines even if I've organized the work in such as way as to make it
impossible to do so and that's what an MSO or MFO contraint does. It's a
command to Project to place the task on such and such a date and leave it
there no matter what. As a result, it will show us doing that task on time
even if it is absolutely impossible for it to really happen that way
according to the way we have organized the rest of the work.

In order for a task to finish on the date the boss has mandated that it must
finish, I have to do something concrete with the driving forces in order to
make it so. Project's job is to tell me whether or not my manipulations are
going to be succesful, not just reassure me they will be whether they
actually are going to be or not. Deadlines desribe when tasks ought to
finish, MFO constraints describe when they will finish and should only be
used when that is an accurate description of predefined physical reality.

Here's a simple experiment to illustrate my point. Create a project file
starting Monday May 1st. Give it three tasks - a start milestone, task X
with a 5 day duration, and a finish milestone. The boss has mandated we
finish by the end of
Friday the 5th so put a MFO constraint of 5pm, 5 May on the finish
milestone. Assign Joe at 100% to task X. So far so good. Now imagine
Joe's boss comes to us and says "Sorry, you can only have him 4 hours a day"
so we must edit his assignment to 50%. Now the task extends to 10 days but
what happens to the finish milestone? Not a thing! It still sits there on
the 5th, locked into position by the MFO constraint, still telling us we're
okay and are finishing right on time! But are we? Not on your life - the
predecessor task that should be driving the milestone's predicted finish
date is only half done and yet the milestone is happily promising the boss
that everything is just peachy. Obviously this is a project plan that has
no relationship whatsoever to objective reality and is totally useless as a
predictive planning model. For this to be a useful model we need to see
what actually happened to the finish milestone when we were forced to reduce
Joe's allocation - that's the only way we can see if any remedies we might
try to apply are going to be successul and the MFO constraint hides that
reality from us.

I think we just need to agree to disagree on this one Steve. We've been
through this before. You use MxO constraints only for eclipses, I'll
use it for when I think it's important to get it done by a given date.
And the posters benefit from hearing 2 points of view!

Have a nice weekend!

 

[Steve House [Project MVP]]

But Dave, when you use it like that, it shows you're hitting that date
whether you really will hit it or not. Shouldn't Project tell you in no
uncertain terms when you're in trouble, early enough for you to actually fix
the problem while it's still fixable? I think one of Project's greatest
values is to serve as a reality check to keep our wishful thinking under
control and what you're suggesting seriously hampers its ability to do that.
What's the problem with using the Deadline field to show the requirements,
with Project sending up a red flag when we're going to miss it, and letting
Project tell us how bad the problem is by showing the task on the date we'll
actually land on unless we do something to fix it? What you suggest is
tantamount to saying "If we're going to be late I don't want to know about
it!"

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

My issue is the constraint tells project where to place the task. A task
will finish whenever it finishes, not when we want it to and it's not
simply
a matter of will power that determines it. I cannot simply declare that
"XX
will happen on May 1st" and have my declaration be sufficient to make it
so.
There are a lot of factors that control where it ends up. The project
plan
is not a description of what we want - it is a model that predicts what
we're going to get. IMHO, it's primarily a tool for "what if" analysis
to
predict where we're going to end up *if* we organize the work in such a
way.
As such I don't want it to fib to me and tell me that we're going to hit
our
deadlines even if I've organized the work in such as way as to make it
impossible to do so and that's what an MSO or MFO contraint does. It's a
command to Project to place the task on such and such a date and leave it
there no matter what. As a result, it will show us doing that task on
time
even if it is absolutely impossible for it to really happen that way
according to the way we have organized the rest of the work.

In order for a task to finish on the date the boss has mandated that it
must
finish, I have to do something concrete with the driving forces in order
to
make it so. Project's job is to tell me whether or not my manipulations
are
going to be succesful, not just reassure me they will be whether they
actually are going to be or not. Deadlines desribe when tasks ought to
finish, MFO constraints describe when they will finish and should only be
used when that is an accurate description of predefined physical reality.

Here's a simple experiment to illustrate my point. Create a project file
starting Monday May 1st. Give it three tasks - a start milestone, task X
with a 5 day duration, and a finish milestone. The boss has mandated we
finish by the end of
Friday the 5th so put a MFO constraint of 5pm, 5 May on the finish
milestone. Assign Joe at 100% to task X. So far so good. Now imagine
Joe's boss comes to us and says "Sorry, you can only have him 4 hours a
day"
so we must edit his assignment to 50%. Now the task extends to 10 days
but
what happens to the finish milestone? Not a thing! It still sits there
on
the 5th, locked into position by the MFO constraint, still telling us
we're
okay and are finishing right on time! But are we? Not on your life -
the
predecessor task that should be driving the milestone's predicted finish
date is only half done and yet the milestone is happily promising the
boss
that everything is just peachy. Obviously this is a project plan that
has
no relationship whatsoever to objective reality and is totally useless as
a
predictive planning model. For this to be a useful model we need to see
what actually happened to the finish milestone when we were forced to
reduce
Joe's allocation - that's the only way we can see if any remedies we
might
try to apply are going to be successul and the MFO constraint hides that
reality from us.

I think we just need to agree to disagree on this one Steve. We've been
through this before. You use MxO constraints only for eclipses, I'll
use it for when I think it's important to get it done by a given date.
And the posters benefit from hearing 2 points of view!

Have a nice weekend!

Steve House [Project MVP] wrote:
Careful with Must Start On or Must Finish On constraints. Those
constraints
are not how deadlines are expressed. MSO or MFO means the task WILL
take
place on those designated dates, engraved in granite, and will take
place
then no matter what we do, or even IF we do anything. Such things are
few
and far between in the real world - an eclipse of the sun, maybe, but
not
much short of that. Most of the time when someone uses an MFO
constraint
they're trying to say "You need to have it done by then or you're
fired!"
and that's not what it means at all.

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I have to disagree with you here, Steve. If my boss tells me "You need
to have it done by then or you're fired!", I'd put a MFO constraint on
it without question. These things are very subjective!


Hi

I would like to know if there is a way in MS Project to
differentiate
de
Critical Path calculated with de CPM method and the critical path
dependant
to the tasks defined with constraints "Must Start On" and "Must
Finish
On"

Thanks for your help

best regards

 

[davegb]

But Dave, when you use it like that, it shows you're hitting that date
whether you really will hit it or not. Shouldn't Project tell you in no
uncertain terms when you're in trouble, early enough for you to actually fix
the problem while it's still fixable? I think one of Project's greatest
values is to serve as a reality check to keep our wishful thinking under
control and what you're suggesting seriously hampers its ability to do that.
What's the problem with using the Deadline field to show the requirements,
with Project sending up a red flag when we're going to miss it, and letting
Project tell us how bad the problem is by showing the task on the date we'll
actually land on unless we do something to fix it? What you suggest is
tantamount to saying "If we're going to be late I don't want to know about
it!"

You're absolutely right, Steve.

My issue is the constraint tells project where to place the task. A task
will finish whenever it finishes, not when we want it to and it's not
simply
a matter of will power that determines it. I cannot simply declare that
"XX
will happen on May 1st" and have my declaration be sufficient to make it
so.
There are a lot of factors that control where it ends up. The project
plan
is not a description of what we want - it is a model that predicts what
we're going to get. IMHO, it's primarily a tool for "what if" analysis
to
predict where we're going to end up *if* we organize the work in such a
way.
As such I don't want it to fib to me and tell me that we're going to hit
our
deadlines even if I've organized the work in such as way as to make it
impossible to do so and that's what an MSO or MFO contraint does. It's a
command to Project to place the task on such and such a date and leave it
there no matter what. As a result, it will show us doing that task on
time
even if it is absolutely impossible for it to really happen that way
according to the way we have organized the rest of the work.

In order for a task to finish on the date the boss has mandated that it
must
finish, I have to do something concrete with the driving forces in order
to
make it so. Project's job is to tell me whether or not my manipulations
are
going to be succesful, not just reassure me they will be whether they
actually are going to be or not. Deadlines desribe when tasks ought to
finish, MFO constraints describe when they will finish and should only be
used when that is an accurate description of predefined physical reality.

Here's a simple experiment to illustrate my point. Create a project file
starting Monday May 1st. Give it three tasks - a start milestone, task X
with a 5 day duration, and a finish milestone. The boss has mandated we
finish by the end of
Friday the 5th so put a MFO constraint of 5pm, 5 May on the finish
milestone. Assign Joe at 100% to task X. So far so good. Now imagine
Joe's boss comes to us and says "Sorry, you can only have him 4 hours a
day"
so we must edit his assignment to 50%. Now the task extends to 10 days
but
what happens to the finish milestone? Not a thing! It still sits there
on
the 5th, locked into position by the MFO constraint, still telling us
we're
okay and are finishing right on time! But are we? Not on your life -
the
predecessor task that should be driving the milestone's predicted finish
date is only half done and yet the milestone is happily promising the
boss
that everything is just peachy. Obviously this is a project plan that
has
no relationship whatsoever to objective reality and is totally useless as
a
predictive planning model. For this to be a useful model we need to see
what actually happened to the finish milestone when we were forced to
reduce
Joe's allocation - that's the only way we can see if any remedies we
might
try to apply are going to be successul and the MFO constraint hides that
reality from us.

I think we just need to agree to disagree on this one Steve. We've been
through this before. You use MxO constraints only for eclipses, I'll
use it for when I think it's important to get it done by a given date.
And the posters benefit from hearing 2 points of view!

Have a nice weekend!

Steve House [Project MVP] wrote:
Careful with Must Start On or Must Finish On constraints. Those
constraints
are not how deadlines are expressed. MSO or MFO means the task WILL
take
place on those designated dates, engraved in granite, and will take
place
then no matter what we do, or even IF we do anything. Such things are
few
and far between in the real world - an eclipse of the sun, maybe, but
not
much short of that. Most of the time when someone uses an MFO
constraint
they're trying to say "You need to have it done by then or you're
fired!"
and that's not what it means at all.

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I have to disagree with you here, Steve. If my boss tells me "You need
to have it done by then or you're fired!", I'd put a MFO constraint on
it without question. These things are very subjective!


Hi

I would like to know if there is a way in MS Project to
differentiate
de
Critical Path calculated with de CPM method and the critical path
dependant
to the tasks defined with constraints "Must Start On" and "Must
Finish
On"

Thanks for your help

best regards