Total slack not correct

[Michele]

First of all, nice to meet u all.
I have a project scheduled from the start date.
I have a number of tasks that generate a critical path.
I create another task called, just for example, "y", with no relationship
with any of the other tasks but with the constraint equal to "As late as
possible".(The duration of the project is anyway longer than the duration of
the single "y" task)
It's correct and my logic accept the fact that microsoft project indicates
me that the task "y" is critical.
But the problem is:
I set for the task "y" an actual start date that is earlier than that one
programmed by project at the beginning using the constraint "As late as
possible".(But not earlier than the start date of the project)
I would expect that project indicated me that "y" task was not anymore a
critical task.
What i mean is that if I start a task before than its last possible beginning
it's clear for me that i can delay that activity for a certain amount of
time withouth delaying the date of the end of the project.
If i change the constraint for "Y" task to "As soon as possible" things
work logically and the amount of total slack is greater than 0 but if leave
"As late as possible" i have total slack that is equal to 0.
Thanks in advice for helping me in understanding where i am wrong.
Michele

 

[Gérard Ducouret]

Hello Michele,
You are not wrong!
MS Project consider this ALAP constraint as a hard constraint which forbids
the task from slipping.That's not correct ;-(

Gérard Ducouret

 

[John]

First of all, nice to meet u all.
I have a project scheduled from the start date.
I have a number of tasks that generate a critical path.
I create another task called, just for example, "y", with no relationship
with any of the other tasks but with the constraint equal to "As late as
possible".(The duration of the project is anyway longer than the duration of
the single "y" task)
It's correct and my logic accept the fact that microsoft project indicates
me that the task "y" is critical.
But the problem is:
I set for the task "y" an actual start date that is earlier than that one
programmed by project at the beginning using the constraint "As late as
possible".(But not earlier than the start date of the project)
I would expect that project indicated me that "y" task was not anymore a
critical task.
What i mean is that if I start a task before than its last possible beginning
it's clear for me that i can delay that activity for a certain amount of
time withouth delaying the date of the end of the project.
If i change the constraint for "Y" task to "As soon as possible" things
work logically and the amount of total slack is greater than 0 but if leave
"As late as possible" i have total slack that is equal to 0.
Thanks in advice for helping me in understanding where i am wrong.
Michele

Michele,
I understand your confusion. What you assume does seem to make sense but
then Project works under a set of rules and sometimes the logic behind
those rules is non-intuitive and difficult to accept or understand.
Let's see if I can shed some light on the subject.

In Project, critical path is of course defined by the Total Slack. The
"trip point", if you will, is user definable under
Tools/Options/Calculation tab. Total Slack in Project is calculated as
the lesser of: Late Start minus Early Start or Late Finish minus Early
Finish. However, if the task finish date happens to be at the end of the
project, or is in a series of tasks that bump up against the end of the
project (as would be caused by a constraint of "as-late-as-possible"),
then it will also be on the critical path.

Even if an Actual Start date puts the task completion well ahead of the
project finish, the constraint, "as-late-as-possible" will cause the
early and late start and finish to be equal because..... the early and
late start dates are fixed by the Actual Start and the early and late
finish dates are fixed by the constraint.

Hope this helps.
John
Project MVP

 

[Michele]

Thanks a lot for answering me.
Even if u explained me the technical aspect that causes early and late
finish to be equal (fact that was yet in my mind) i think i'm still convinced
that it's not correct.
I try to explain you better why, in my opinion, it's so:
In the first approach of making a project i could have had the need to do a
task with constraint "as late as possible" so that i could have finished that
activitie at the end of the project and not later or before.
In the real situation, for any kind of reason, i actually started that task
before than i predicted at the beginning, so, if that was the situation, it's
clear that, regarding this task, i must have an amount of total slack because
i must know that i can delay this activitie, having had started it earlier
than predicted.
I think this project behaviour is not correct and microsoft should change
it, i mean Project gives a wrong information about that task because it's not
critical, i can delay it for a certain amount of time without any effect on
the project end date or any of other project aspect.
Thanks a lot for reading me.
Michele




"John" ha scritto:

 

[Michele]

I'm happy my logic is shared by other people like you.
I hope that someone at Microsoft will read this point and do something about
that.
Thanks really a lot.
Michele

"Gérard Ducouret" ha scritto:

 

[John]

Hello Michele,
You are not wrong!
MS Project consider this ALAP constraint as a hard constraint which forbids
the task from slipping.That's not correct ;-(

Gérard Ducouret

Gerard,
I respectfully disagree. I believe Michele's logic is flawed, not
Project's calculation. See my last post to her.

John

 

[John]

Thanks a lot for answering me.
Even if u explained me the technical aspect that causes early and late
finish to be equal (fact that was yet in my mind) i think i'm still convinced
that it's not correct.
I try to explain you better why, in my opinion, it's so:
In the first approach of making a project i could have had the need to do a
task with constraint "as late as possible" so that i could have finished that
activitie at the end of the project and not later or before.
In the real situation, for any kind of reason, i actually started that task
before than i predicted at the beginning, so, if that was the situation, it's
clear that, regarding this task, i must have an amount of total slack because
i must know that i can delay this activitie, having had started it earlier
than predicted.
I think this project behaviour is not correct and microsoft should change
it, i mean Project gives a wrong information about that task because it's not
critical, i can delay it for a certain amount of time without any effect on
the project end date or any of other project aspect.
Thanks a lot for reading me.
Michele




"John" ha scritto:

Michele,
I understand your logic but it has a flaw. I believe Project is handling
your task properly by applying its rules to what is actually an
inconsistent set of data. Consider the following arguments.

When a project plan is first laid out, the structure of that plan is
based on the best information available at the time. As the plan is
executed, initial assumptions are likely to change and that is exactly
the situation you have described. For example, let's say a task has an
estimated Start date of Wed, 11/16/05. The resource assigned to the task
actually starts on Mon, 11/14/05 and the schedule manager enters that
date in the Actual Start field. Should the estimated Start date of
11/16/05 still remain? Of course not because that was only an estimate
and reality has taken its place. Another example. Let's say for some
reason a task was given a "must-start-on" constraint of 11/30/05 but the
resources assigned to it started on 11/15/05. Is the constraint still
valid? Of course not. The same applies to your case. Your original plan
had a task with a "as-late-as-possible" so you could, as you say, finish
the task at the end of the project. However, you started the task early
and assuming the duration did not change, the task will finish earlier
than originally planned. So, is the constraint still valid? No.

Project plans are dynamic and they require updating and maintenance.
When constraints are included in a plan, the project manager needs to
understand how those constraints affect performance to the plan. As the
plan is executed, a continuous assessment needs to be performed to
ensure the plan remains valid.

Hope this helps.

John
Project MVP

 

[Michele]

John, really thank you for your patience.
I totally agree with your arguments about reconsidering constraints as the
project goes in progress.
So it's clear ,in my case, that i need to change my constraint in "As soon
as possible" because my initial constraint "As late as possible" is, in
facts, no more valid, even if i can divide my activitie to make it end with
the end of the project.
Anyway to give a further logic to this behaviour i found that if i create a
task that has a duration of 0 days and i give it as many predecessors(With
end-start relation)as how many tasks i have in my project, and so i give it
even "y" task as a predecessor, and if i have the related option activated in
tools, project divides my "y" task so that the amount of total slack has a
real meaning.(But only if other than putting an actual start date i put also
actual work hour).
Changing my constraint in "As soon as possible" i'm still able to see my
true amount of total slack, so i can accept riconsidering my constraints if
this gives me correct data of total slack, so i can consider your answer as a
positive and solving my problem answer but please John read my other question
that has , as its object, "Meaning of total slack in a project scheduled from
end date", where no matter what constarints i give to task i can't see the
correct amount of total slack.
Thanks a lot in advice.
Michele
"John" ha scritto:

 

[Gérard Ducouret]

Gerard,
I respectfully disagree. I believe Michele's logic is flawed, not
Project's calculation. See my last post to her.

John

John,

You said: "So, is the constraint still valid? No. "
If you either remove the ALAP constraint or if you let it as it is, this
task which has an Actual Start on Monday 11/14/05 instead of the scheduled
Wed 11/16/05, could last two days more, without any impact on the Finish
date of the project. Is not it the very definition of a slack?
Sincerely yours,

Gérard

 

[John]

John,

You said: "So, is the constraint still valid? No. "
If you either remove the ALAP constraint or if you let it as it is, this
task which has an Actual Start on Monday 11/14/05 instead of the scheduled
Wed 11/16/05, could last two days more, without any impact on the Finish
date of the project. Is not it the very definition of a slack?
Sincerely yours,

Gérard

Gerard,
I agree with the concept - there is clearly slack in the example.
However, as we find out by changing the constraint from
"as-late-as-possible" to "as-soon-as-possible" on a task that has
started, the rules of Project say the task is critical (first case) or
not (second case). Based on that and on further reading of all the
variables Project includes in the Total Slack/Critical path algorithm,
the type of constraint on the task has a real impact.

My point is the following. For a task that has an Actual Start date, is
the validity of a constraint still valid? I say no. The same holds true
for predecessor to a task that has an Actual Start date - it is no
longer valid. Except in the latter case there is no real impact for
leaving the predecessor intact. That isn't the case with a constraint.

I didn't make the rules, I'm just trying to interpret them.

John

 

[Michele]

As Microsoft correctly gives great importance to what users of their
softwares think about them and about their ideas to improve them, i think
that if there are any kind of rule in a specific software that doesn't match
logic of most of the people or that is clearly wrong(like i think it is in
this specific case) Microsoft itself has the primary interest to change that
rule and i really hope that this will be done, because Microsoft Project
would become better.
Anyway knowing how a software works avoids you to make mistakes, so now that
i found this specific case i know that, waiting for a Microsoft patch to
solve the problem, i will go on threating this specific case changing the
constraint to "As soon as possible" so that i will see what is true, that is
that the task is not critical and has an amount of total slack.
Best regards
Michele

"John" ha scritto:

 

[Steve House [Project MVP]]

One wrinkle here is Project doesn't do quite what I would expect regardling
the placement of tasks viz a vie ASAP and ALAP when scheduling backwards.
Try this simple one task project scheduled from a finish date of, say, 16
Dec, the sole task set to 5 days duration. The default scheduling for the
task is ALAP and so it is set to begin 12 Dec. Now in the advance tab of
the task information change the constraint to ASAP. What I would expect to
happen is that it moves to start tomorrow, the first available worktime
after the current date, "As Soon As Possible" but that's not what happens.
Instead, it remains starting on 12 Dec. If however I add another task that
is 10 days duration that new task begins 05 Dec and now the first task moves
so that it also starts 05 Dec and picks up 5 days slack. Now add a third,
10-day, task linked as a sucessor to the second. Now tasks 1 and 2 are both
pushed back to begin on 21 Nov.

What is happening is that Project is looking at the longest chain of tasks
and calculating back from the end date to find the latest possible start
date. Then any ASAP tasks are started ASAP after that calculated start
date. In my third example, task A is non-critical, B & C are critical.

 

[John]

As Microsoft correctly gives great importance to what users of their
softwares think about them and about their ideas to improve them, i think
that if there are any kind of rule in a specific software that doesn't match
logic of most of the people or that is clearly wrong(like i think it is in
this specific case) Microsoft itself has the primary interest to change that
rule and i really hope that this will be done, because Microsoft Project
would become better.
Anyway knowing how a software works avoids you to make mistakes, so now that
i found this specific case i know that, waiting for a Microsoft patch to
solve the problem, i will go on threating this specific case changing the
constraint to "As soon as possible" so that i will see what is true, that is
that the task is not critical and has an amount of total slack.
Best regards
Michele

Michele,
No disrespect but if most people believe something does not make it
correct. In this case invalid data, (i.e. a constraint that is no longer
valid), should not be required to produce valid results.

Not to belabor the point. I suppose Microsoft could change the algorithm
so that once a task is started, constraints are automatically ignored. I
have no problem with that but please realize, software is patched only
if it has a flat out error (not the case here) or updated if a
sufficient quantity of users request a particular feature. I don't
recall seeing this issue brought up before however I'm certainly not the
one who makes decisions as to what should be added, deleted or changed
in Project.

John
Project MVP

 

[Michele]

Steve, thank you fo participating to the discussion.
What you would expect in your example is not correct.
What you describe is the normal and logic behaviour of a project scheduled
from an end date, where you have to reverse all the reasonings you apply in
scheduling a project from a start date.
What is not correct, in my opinion, in your example is the fact that
Microsoft Project indicates the first task that you created(task A) as not
critical, that is with a certain amount of total slack.
I explained the reason i think that's not correct(And the so the reason the
task "A" should be indicated by Project as critical task) in these link:
http://support.microsoft.com/newsgr...a-a526-4400-8337-a6c7fcf7f625&sloc=it&sloc=it
http://support.microsoft.com/newsgr...9-4615-48cd-968d-79194dd3bac7&sloc=it&sloc=it
Best regards
Michele


"Steve House [Project MVP]" ha scritto:

 

[Michele]

John thank you again for your perseverance in participating to the
discussion, i really appreciate it.
What i apply to my arguments are the principles of pure formal logic
mathematics.
I'm not saying that i have an opinion about my original question, i'm just
saying that pure formal logic(if u consider mathematics a science and many
don't because they assume that it is founded upon a faith(natural
numbers..)))demonstrates that task "y", as Gerard said before than me, has,
by definition, a total amount greater than 0 no matter what constraint you
give it between "As soon as possible" or "As late as possible".
Anyway, as i said before,knowing how a software works avoids you to make
mistakes.
Said that i agree with you that this can be considered not a big problem and
maybe very few users of Project will need to change this behaviour.
Really thank you.
Michele

 

[John]

John thank you again for your perseverance in participating to the
discussion, i really appreciate it.
What i apply to my arguments are the principles of pure formal logic
mathematics.
I'm not saying that i have an opinion about my original question, i'm just
saying that pure formal logic(if u consider mathematics a science and many
don't because they assume that it is founded upon a faith(natural
numbers..)))demonstrates that task "y", as Gerard said before than me, has,
by definition, a total amount greater than 0 no matter what constraint you
give it between "As soon as possible" or "As late as possible".
Anyway, as i said before,knowing how a software works avoids you to make
mistakes.
Said that i agree with you that this can be considered not a big problem and
maybe very few users of Project will need to change this behaviour.
Really thank you.
Michele

Michele,
You're welcome. This was the first time I actually dug deeply into the
issue of how Project calculates Total Slack. I always use forward
scheduling and rarely use constraints. I am also in the habit of
periodically reviewing my schedules to remove invalid data (e.g. links
that are no longer valid, etc.).

Project does most things very well but like any software application
there are always quirks. Maybe they are put there by developers just to
keep the users "on their toes"

John
Project MVP

 

[Michele]

Your habit is surely the best way to approach and to manage a project even
because, like u say, no software can't aviod us to use our minds.
I totally agree with you.
Best regards
Michele

"John" ha scritto: