Free Slack calculation?

[G Lykos]

Don't understand the calculation results that I'm seeing. Have a task with
a Must Start On date that ties down its front end which cascades
finish/start into another task starting a good month after the first
completes (due to other tasks that also feed into that task and keep it
pushed out). The MSO task shows zero free slack, which is not true in that
it can delay a lot before running up against the successor.

Believe I'm also seeing where several unconstrained tasks (beyond logical
linkages to other tasks) cascading into a common ASAP successor are all
showing zero free slack even though not all of them butt up against the
successor in time.

What is the algorithm being followed?

Thanks,
George

 

[Jan De Messemaeker]

An MSO task cannot be delayed.
I learned in school that in English, the word MUST is very compelling, no
dicussion, it MUST be done there and then.
How then could it be delayed?

 

[G Lykos]

How could it be delayed, you ask? You change the MSO constraint date. And
the concept and book calculation of free slack has squat to do with it.

Do you know what is the MS Project calculation algorithm is, including
nuances, or better yet, where it is published??

Thanks again,
George

 

[Steve House [Project MVP]]

When you enter a MSO constraint my assumption is that is a model of physical
reality - if it were possible by any means whatsoever for that change it
would not be constrained - it goes far beyond the whim of the project
manager or his senior management, it is something like an eclipse of the
moon that will happen as described by the constraint date no matter what,
engraved in granite. If you CAN change your mind and delay it by changing
the date, than that date is not a legitimate MSO constraint date to begin
with and should never have been there in the first place.

 

[davegb]

When you enter a MSO constraint my assumption is that is a model of physical
reality - if it were possible by any means whatsoever for that change it
would not be constrained - it goes far beyond the whim of the project
manager or his senior management, it is something like an eclipse of the
moon that will happen as described by the constraint date no matter what,
engraved in granite. If you CAN change your mind and delay it by changing
the date, than that date is not a legitimate MSO constraint date to begin
with and should never have been there in the first place.

I have to respectfully disagree with Steve here. I can see myself (not
Steve), planning an event. I decide to set the date for the event on
Oct 1, 2006, using an MSO constraint. As far as I'm concerned, it has
to occur on that date. I create a schedule and a scope and my project
plan.
Upon further planning, I decide that I don't have enough time to
prepare for the event next Oct 1. I change the MSO contraint to....
whatever. And I might even change it again. Of course, there comes a
point when changing that date becomes extremely expensive and may cause
the event not to occur at all. Once the announcements have gone out,
it's pretty hard for such a date to change, but I've seen it happen
even then. To me, an MSO is just a hard date that shouldn't be sent or
changed arbitrarily or capriciously. But it can be changed by
circumstances.
To quote Eisenhower, "Plans are meaningless, planning is everything".
It's just our best guess at the date for something important to happen,
probably something which will determine the timing for many other
things to occur. According to the plan, it must occur at a certain
date. Nature, and even some people, can change it if they decide to.
IT'S JUST A DATE ON A PIECE OF PAPER. Or on a computer screen.
That being said, according to MS Project, a task with an MSO constraint
has no slack because it HAS to occur on the set date. I guess it
doesn't matter much whether I agree with this decision or not, it's in
the algorithm. You can let MS know you don't like their choice, but
that's about it. You could also use some other software that doesn't
have this particular fluke.
Hope this helps in your world.

 

[Steve House [Project MVP]]

Perhaps the root of our different view on this is that I tend to think of
ALL constraints, no matter what type, as generally modeling factors that
influence the project's schedule but are outside the control of the project
manager or planner. So if having a float in the Macy's Parade is a part of
your advertising campaign project, the date that will occur is
non-negotiable, completely outside of your control, and so legitimately a
MSO constraint - your float is either ready to roll when the parade starts
or that part of your project won't happen at all. There are exceptions of
course but that's my basic rule of thumb.

 

[davegb]

Perhaps the root of our different view on this is that I tend to think of
ALL constraints, no matter what type, as generally modeling factors that
influence the project's schedule but are outside the control of the project
manager or planner. So if having a float in the Macy's Parade is a part of
your advertising campaign project, the date that will occur is
non-negotiable, completely outside of your control, and so legitimately a
MSO constraint - your float is either ready to roll when the parade starts
or that part of your project won't happen at all. There are exceptions of
course but that's my basic rule of thumb.

I agree,Steve, it's a fundamental difference in how we view the
schedule. I see constraints as a tool within Project, no more or less.
If I want something to occur on a given date, or before or after a
date, I use a constraint. As I see it, I have just as much right to set
constraints as does Macy's! Of course, experience has taught me to use
this particular tool judiciously. In my section on Constraints in my
Project classes, the First Rule of using constraints is to use them
sparingly, which is preceded by a discussion of how they can interfere
with CPM scheduling.
YMMV.

 

[Steve House [Project MVP]]

Ahh HAH! Anothger crucial difference, then, is that for the most part I
don't see project planning as a process of defining when you want things to
occur at all. I *want* to finish the project in a certain time frame and
within a certain budget. Planning, to my thinking, is mostly a process of
DISCOVERY of when things *need* to occur in order to meet those objectives
most efficiently. I don't decide we should fix the fidgets on the 15th of
November, I run the numbers and find out that in order to complete in
accordance with our firm's business objectives we NEED to fix the fidgets
starting no later than the 15th of November. Neither my nor Senior
Management's desires have anything to do with it except we both want to
attain the final objective within a certain time constraint. My job is to
discover how it can be done and that is driven more by the physical
requirements inherent in the nature of the work and the number and
capabilities of the resources than by anything else. My decisions about
when things ought to occur has little if any influence over when they can
occur and virtually no influence at all over when they need to occur if we
are to meet our objectives.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Perhaps the root of our different view on this is that I tend to think of
ALL constraints, no matter what type, as generally modeling factors that
influence the project's schedule but are outside the control of the
project
manager or planner. So if having a float in the Macy's Parade is a part
of
your advertising campaign project, the date that will occur is
non-negotiable, completely outside of your control, and so legitimately a
MSO constraint - your float is either ready to roll when the parade
starts
or that part of your project won't happen at all. There are exceptions
of
course but that's my basic rule of thumb.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve House [Project MVP] wrote:
When you enter a MSO constraint my assumption is that is a model of
physical
reality - if it were possible by any means whatsoever for that change
it
would not be constrained - it goes far beyond the whim of the project
manager or his senior management, it is something like an eclipse of
the
moon that will happen as described by the constraint date no matter
what,
engraved in granite. If you CAN change your mind and delay it by
changing
the date, than that date is not a legitimate MSO constraint date to
begin
with and should never have been there in the first place.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I have to respectfully disagree with Steve here. I can see myself (not
Steve), planning an event. I decide to set the date for the event on
Oct 1, 2006, using an MSO constraint. As far as I'm concerned, it has
to occur on that date. I create a schedule and a scope and my project
plan.
Upon further planning, I decide that I don't have enough time to
prepare for the event next Oct 1. I change the MSO contraint to....
whatever. And I might even change it again. Of course, there comes a
point when changing that date becomes extremely expensive and may cause
the event not to occur at all. Once the announcements have gone out,
it's pretty hard for such a date to change, but I've seen it happen
even then. To me, an MSO is just a hard date that shouldn't be sent or
changed arbitrarily or capriciously. But it can be changed by
circumstances.
To quote Eisenhower, "Plans are meaningless, planning is everything".
It's just our best guess at the date for something important to happen,
probably something which will determine the timing for many other
things to occur. According to the plan, it must occur at a certain
date. Nature, and even some people, can change it if they decide to.
IT'S JUST A DATE ON A PIECE OF PAPER. Or on a computer screen.
That being said, according to MS Project, a task with an MSO constraint
has no slack because it HAS to occur on the set date. I guess it
doesn't matter much whether I agree with this decision or not, it's in
the algorithm. You can let MS know you don't like their choice, but
that's about it. You could also use some other software that doesn't
have this particular fluke.
Hope this helps in your world.

I agree,Steve, it's a fundamental difference in how we view the
schedule. I see constraints as a tool within Project, no more or less.
If I want something to occur on a given date, or before or after a
date, I use a constraint. As I see it, I have just as much right to set
constraints as does Macy's! Of course, experience has taught me to use
this particular tool judiciously. In my section on Constraints in my
Project classes, the First Rule of using constraints is to use them
sparingly, which is preceded by a discussion of how they can interfere
with CPM scheduling.
YMMV.

 

[davegb]

Ahh HAH! Anothger crucial difference, then, is that for the most part I
don't see project planning as a process of defining when you want things to
occur at all. I *want* to finish the project in a certain time frame and
within a certain budget. Planning, to my thinking, is mostly a process of
DISCOVERY of when things *need* to occur in order to meet those objectives
most efficiently. I don't decide we should fix the fidgets on the 15th of
November, I run the numbers and find out that in order to complete in
accordance with our firm's business objectives we NEED to fix the fidgets
starting no later than the 15th of November. Neither my nor Senior
Management's desires have anything to do with it except we both want to
attain the final objective within a certain time constraint. My job is to
discover how it can be done and that is driven more by the physical
requirements inherent in the nature of the work and the number and
capabilities of the resources than by anything else. My decisions about
when things ought to occur has little if any influence over when they can
occur and virtually no influence at all over when they need to occur if we
are to meet our objectives.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Perhaps the root of our different view on this is that I tend to think of
ALL constraints, no matter what type, as generally modeling factors that
influence the project's schedule but are outside the control of the
project
manager or planner. So if having a float in the Macy's Parade is a part
of
your advertising campaign project, the date that will occur is
non-negotiable, completely outside of your control, and so legitimately a
MSO constraint - your float is either ready to roll when the parade
starts
or that part of your project won't happen at all. There are exceptions
of
course but that's my basic rule of thumb.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



Steve House [Project MVP] wrote:
When you enter a MSO constraint my assumption is that is a model of
physical
reality - if it were possible by any means whatsoever for that change
it
would not be constrained - it goes far beyond the whim of the project
manager or his senior management, it is something like an eclipse of
the
moon that will happen as described by the constraint date no matter
what,
engraved in granite. If you CAN change your mind and delay it by
changing
the date, than that date is not a legitimate MSO constraint date to
begin
with and should never have been there in the first place.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


I have to respectfully disagree with Steve here. I can see myself (not
Steve), planning an event. I decide to set the date for the event on
Oct 1, 2006, using an MSO constraint. As far as I'm concerned, it has
to occur on that date. I create a schedule and a scope and my project
plan.
Upon further planning, I decide that I don't have enough time to
prepare for the event next Oct 1. I change the MSO contraint to....
whatever. And I might even change it again. Of course, there comes a
point when changing that date becomes extremely expensive and may cause
the event not to occur at all. Once the announcements have gone out,
it's pretty hard for such a date to change, but I've seen it happen
even then. To me, an MSO is just a hard date that shouldn't be sent or
changed arbitrarily or capriciously. But it can be changed by
circumstances.
To quote Eisenhower, "Plans are meaningless, planning is everything".
It's just our best guess at the date for something important to happen,
probably something which will determine the timing for many other
things to occur. According to the plan, it must occur at a certain
date. Nature, and even some people, can change it if they decide to.
IT'S JUST A DATE ON A PIECE OF PAPER. Or on a computer screen.
That being said, according to MS Project, a task with an MSO constraint
has no slack because it HAS to occur on the set date. I guess it
doesn't matter much whether I agree with this decision or not, it's in
the algorithm. You can let MS know you don't like their choice, but
that's about it. You could also use some other software that doesn't
have this particular fluke.
Hope this helps in your world.

I agree,Steve, it's a fundamental difference in how we view the
schedule. I see constraints as a tool within Project, no more or less.
If I want something to occur on a given date, or before or after a
date, I use a constraint. As I see it, I have just as much right to set
constraints as does Macy's! Of course, experience has taught me to use
this particular tool judiciously. In my section on Constraints in my
Project classes, the First Rule of using constraints is to use them
sparingly, which is preceded by a discussion of how they can interfere
with CPM scheduling.
YMMV.

Glad to have given you an "Ah-ha" moment, Steve!

Anothger crucial difference, then, is that for the most part I
don't see project planning as a process of defining when you want things to
occur at all. I *want* to finish the project in a certain time frame and
within a certain budget.

I find these 2 statements contradictory and confusing. Which is it? Is
the want encircled in asterisks less powerful than the unencumbered
want? Or the other way around? In your planning methodology allow for
your "wants" or not?

Planning, to my thinking, is mostly a process of
DISCOVERY of when things *need* to occur in order to meet those objectives
most efficiently.

Kind of like the sculptor cuts away the marble that isn't part of the
final product, huh? An old art cliche, probably with some truth. But I
seriously doubt if Michaelangelo didn't have the David in mind when he
made that first chip! Certainly, anyone who tries to control all of the
variables in a project, including when every task starts and finishes,
is in trouble. Nonetheless, I believe that I'm smarter than MS Project.
It's a tool in my hand. It may show me that task 31 should start of
Sept 5 rather than the first, based on dependencies. But it can't know
all the factors which might make that not a viable date. That's up to
me. I have the responsibility to know what can and can't happen in the
real world.
It's easy to forget that Project is basically a SIMULATION of the real
world. It's merely a computer program trying to duplicate the realities
of the timing of a project. IT'S NOT THE PROJECT. To effectively apply
any simulator, you have to understand both the capabilities and
LIMITATIONS of that simulator.
Your explanation sounds as though you've subjugated your good judgement
to the superior judgement of a program. I doubt this is really true. I
hope not. I've seen this happen, and it's just as much of a disaster as
the overcontrolling I mentioned above. (From what I know of you Steve,
I doubt you really do this.)
For example, at one point in the planning of the Denver International
Airport project, the planned opening date for the new airport was Dec.
18th! I can't imagine anyone stupid enough to try to start up a system
as complex as an entire international airport during one of it's peak
periods. Total insanity! Can you picture the snafu that would have
occured had it actually opened one week before Christmas? (Luckily, it
got rescheduled by circumstances!) Of course, whatever scheduling
software was used would have had no problem in setting that date.
That's where a human brain should have over-ridden the software and
postponed the date until early January.
MS Project, or any other software for that matter, is not a substitute
for using the human brain. Nothing on earth comes close, at this time,
to being able to account for numerous variables and make a reasonable
decision about anything, including project schedules. To me, Project
remains, and always will remain, a tool. I believe that my hand should
be sensitive to the feedback the tool gives me, but I'm ultimately
responsible for a useful final product.