Meaning of total slack in a project scheduled from end date

[Michele]

I have a project scheduled from the end 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.
Even if this behaviour is different(and rightly logic) in a project
scheduled from the start date, i can accept the fact that, no matter what
constraint i give to task "y" between the two possibilities "As soon as
possible" or "As late as possible", the task "y" is not considered critical
by microsoft project.(The duration of the project is anyway longer than the
duration of the single "y" task)
My problem is:
If i set for the task "y" an actual start date the task "y" becomes critical
no matter what actual start date or what constraint betwenn "As soon as
possible" or "As late as possible" i give it. (I put an actual start date in
the possible range of the critical path, not making it end after the end date
of the project).
It's for me logic that early and late start dates are fixed by the Actual
Start date but i really can't undertsand why the early and late finish dates
are always the same, no matter if i give the task "As soon as possible" or
"As late as possible" constraint, causing the task "Y" to be always critical.
If things worked like they work in a project scheduled from the start date
and about what i wrote in one of my previous question(Object: "Total slack
not correct", Date: 11/13/2005), i would expect that if i gave "As late as
possible" constraint to task "y" than project would force the early and late
finish dates to be the same(like it, infact, does) but if i gave "As soon as
possible" constraint to task "y" than project wouldn't force the early and
late
finish dates to be the same(like he, instead, does) or i even would expect
the opposite.
Anyway, again and more than how it happens in a project scheduled from the
start date i can't understand why project indicates me that a task is
critical when the fact that i delay it won't have any consequences on the end
date of the project or on any other aspect of the project.
What i mean is that if, at the beginning, i scheduled the task "y" to start
"As soon as possible" but , in facts, the task "y" actually starts later i
would expect that project told me that the total slack amount of "y" was not
0 and the same if the initial constraint of "y" was "As late as possible",
that is in both cases my task "y" is not absolutely critical, i can delay it
untill it reaches the end date of the project.
Thanks in advice for helping me in understanding.
Michele

 

[John]

I have a project scheduled from the end 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.
Even if this behaviour is different(and rightly logic) in a project
scheduled from the start date, i can accept the fact that, no matter what
constraint i give to task "y" between the two possibilities "As soon as
possible" or "As late as possible", the task "y" is not considered critical
by microsoft project.(The duration of the project is anyway longer than the
duration of the single "y" task)
My problem is:
If i set for the task "y" an actual start date the task "y" becomes critical
no matter what actual start date or what constraint betwenn "As soon as
possible" or "As late as possible" i give it. (I put an actual start date in
the possible range of the critical path, not making it end after the end date
of the project).
It's for me logic that early and late start dates are fixed by the Actual
Start date but i really can't undertsand why the early and late finish dates
are always the same, no matter if i give the task "As soon as possible" or
"As late as possible" constraint, causing the task "Y" to be always critical.
If things worked like they work in a project scheduled from the start date
and about what i wrote in one of my previous question(Object: "Total slack
not correct", Date: 11/13/2005), i would expect that if i gave "As late as
possible" constraint to task "y" than project would force the early and late
finish dates to be the same(like it, infact, does) but if i gave "As soon as
possible" constraint to task "y" than project wouldn't force the early and
late
finish dates to be the same(like he, instead, does) or i even would expect
the opposite.
Anyway, again and more than how it happens in a project scheduled from the
start date i can't understand why project indicates me that a task is
critical when the fact that i delay it won't have any consequences on the end
date of the project or on any other aspect of the project.
What i mean is that if, at the beginning, i scheduled the task "y" to start
"As soon as possible" but , in facts, the task "y" actually starts later i
would expect that project told me that the total slack amount of "y" was not
0 and the same if the initial constraint of "y" was "As late as possible",
that is in both cases my task "y" is not absolutely critical, i can delay it
untill it reaches the end date of the project.
Thanks in advice for helping me in understanding.
Michele

Michele,
I never schedule in reverse (i.e. Project is scheduled from the finish
date) so I had to do a little research and analysis to answer this
question. And scheduling in reverse is counter-intuitive to the way we
humans think about time - the future is open but the past is fixed.
Anyway, after my analysis here's the best explanation I can come up with.

When a project is scheduled from the start date, Total Slack is measured
to the finish date. However, when a project is scheduled from the finish
date, Total Slack is measured from the start date. At least that's the
way I think about it and it seems to make sense. Given that, if a
reverse scheduled task has an Actual Start date, the Early Start and
Late Start are fixed. But unlike a forward scheduled task, the Early
Finish and Late Finish are also "fixed" by the task duration, regardless
of the constraint type because there is no Start Slack and Finish Slack
is "held" by the Duration.

If someone else has a better or more clear explanation, feel free to
join the thread.

My recommendation. If possible avoid reverse scheduling unless you are
willing to "think backwards" and can grasp a full understanding of how
reverse scheduling changes some of the concepts (e.g. slack) in a
schedule plan. It is kind of like putting links or assigning resources
to Summary Lines. Yes, Project allows it, but it requires a whole new
depth of understanding.

Hope this helps.
John
Project MVP

 

[Michele]

John, thanks a lot for reading me again.
I am used to “think backwards†as u said , seen that my company works on
projects that need to be finished in a fixed end date.
The erp software my company uses for producing its automatic machineries is
implemented to “think backwardsâ€, that is exploding all the required
needs(hours and materials) from an end date that is fixed on the contract and
because of that i think that my mind is enough structured to “think
backwardsâ€.
I agree with you regarding the fact that, logically, in a project scheduled
from the end date total slack should be measured from the start
date(calculated by the critical path) but it’s not what(maybe only formally,
because i think that practically it does) Microsoft Project does, i try to
explain why:
Take my example regarding my question; when i initially created the task
“yâ€(and not yet associated to it an actual start date) the situation of total
and free slack in the next two cases was this way:
If i give to task “y†the constraint “As soon as possible†than the amounts
of free and total slack are identical and they are greater than 0, if i give
to task “y†the constraint “As late as possible†the amount of free slack is
0 and the amount of total slack is greater than 0 and equal to that one the
task “y†had when it had constraint “As soon as possibleâ€.
So, seen the above example, it’s clear for me the meaning of total slack in
the mind of Project programmers in a project scheduled from the end date:
Total slack is the amount of time i can delay a task or i can start earlier a
task untill it reaches respectively the end date of the project and the start
date of the project(respectively if it has a constraint that is “As soon as
possible†or a constraint that is “As late as possibleâ€).
I think that this is the wrong point: In one of the two above cases the task
“y†should be considered critical by Project(like it happens in a project
scheduled from a start date, where the task “y†becomes critical if it has a
constraint “As late as possible†and not critical if it has a constraint of
“As soon as possibleâ€) , i.e. with total slack equal to 0, like Microsoft
itself said in this link
http://office.microsoft.com/en-us/assistance/HA010211731033.aspx about the
definitions of a critical task, that is that Project should consider task “yâ€
crititical when it has a constraint equal to “As soon as possible†and the
project is scheduled from an end date.
If project acted this way, that is if task “y†was considered critical if
associated to “As soon as possible†constraint, than it would have a logical
sense the fact that Project, no matter what constraint task “y†has between
“As soon as possible†or “As late as possibleâ€, considers task “y†always
critical when i associate it an actual start date and i explain why i think
so:
In this case the definition of a critical task in a project scheduled from
the end would be only one of the two above and in particular this: : Total
slack is the amount of time i can start earlier a task untill it reaches the
start date of the project(calculated by the critical path).
So it’s clear that if the definition of a critical task was the one above
and a task has an actual start date no matter what constraint i give it i
cannot start the task earlier so the task will be always critical.
I realize that many people could think that this aspect is very marginal but
i think, instead, that it would clarify a lot the ideas of people that need
to plan backwards.
I do think that Microsoft should change this behaviour of Project, making
become a task with constraint “As soon as possible†in a project scheduled
from the end date critical even without associating it an actual start date,
because it would help people that are not so useful to think backward and to
plann a project from the end to understand things that, in effects, are very
simple.
Anyway it’s always reccomended that, once someone planned a project from an
end date and obtained, through the critical path, the date of the beginning
of the project, he/she converts it into a project planned from the start
date, keeping great attention in converting, where necessary, all the
constraints.(From the default “As late as possible†to the default “As soon a
spossibleâ€), so that all slacks will assume a commonly most accepted
meaning.(As u told me John,our time doesn’t flow, in reality, from present to
past, but in the opposite way…but i like to think not conventionally, because
what u do, in effects, when you plan a project from an end date is converting
the naturally flowing of time going from a future date to a previous date and
if u think about it ,total slack does assume a very logical meaning)
I really hope i was enough clear and specially that you John and other
people could agree with me.
Really thanks you John and to anyone who will add his/her comments.
Michele


"John" ha scritto:

 

[Steve House [Project MVP]]

Just my 2 cents - the fact that a project has a fixed date by which it must
be finished DOES NOT mean it should be scheduled backwards from the finish
date IMHO. That finish date is an objective that is very very important to
hit. But the project will actually finish when the work is actually
completed, whether it is before, on, or after the required date. When one
builds a plan, one trys to create the most efficient schedule one can have.
When you build that plan based on the assumption you'll start on some
selected date, the projected finish will be calculated either before, on or
after the required date. If it's before the deadline, great. If it's on
the deadline, we should do some work to move it forward to give us a bit of
a cushion to absorb problems. If it's AFTER the deadline we have to do a
LOT of work to bring it forward far enough. But in each case, the first
function of MSP is to predict when things will end IF we organize the work
and assign the resources in a certain way - if that doesn't work to meet our
objectives we need to reorganize the work or alter the resource assignments.
One of the drawbacks of scheduling backwards from the finish is that it
schedules things with no cushion - it tells you the LATEST dates things can
start in order for the project to finish on the required end date. But if
something goes wrong - and something ALWAYS goes wrong - you've already used
up all your "wiggle room" and the inevitable consequence is a late finish.

 

[Michele]

Really thank you Steve for reading me.
I totally agree with your general arguments.
Anyway the point of my initial question was related to a more specific
aspect, if you want, a marginal aspect, but, as i told before, an aspect
that Microsoft should consider to improve so that Project would be a better
product(even if little better).
Thanks a lot anyway for your answer
Best regards
Michele

"Steve House [Project MVP]" ha scritto: