Deadlines and Total Slack Connection

[Trevor Rabey]

I had understood that setting deadlines did nothing more than put the little
arrow in the Gantt Chart and raise a warning in the Indicators field, but
now a new discovery.
But Tasks overdue on deadlines, and their Predecessors, end up with negative
Total Slack.
Negative Total Slack usually arises from Date Constraints (the HELP says
so), such as nailed down finish milestones, so it is pretty hard to find a
cause of Negative Total Slack when there are no Date Constraints but it is
being caused by Deadlines.
Nowhere in the HELP for Total Slack or Deadlines does this connection get a
mention, and this is not very pure CPM.
Negative TS is very difficult to interpret and best avoided, right?
Also, the explanation for the meaning of TS in the help, that it means
something ie the time that has to be saved to be on time, is almost useless
as diagnostic or optimisation information.

Trevor

 

[DavidC]

Hi,

A deadline means that this is the date that the task to which the deadline
is applied must be finished by. So if the schedule you have developed menas
that the task cannot be completed by the date of the deadline then there is
insufficient time which reflects in negative slack.

You are correct a schedule should not have negative slack. Think of oday
slack means that the schedule will be completed on time and no time to spare,
1 day slack, means that the schedule can finish one day before the end of the
project or there is opportunity for the schedule to slip by one day. The
opposite then is negative slack, when all the time has been used plus some
more. It is the "some more' time that needs to be addressed.

An example of using a deadline would be in maintenance schedules. In this
situation the operations will have a date for the plant to be back in
production ( a deadline). By having the final task as "Plant back on line"
and assigning a deadline date, then Project will idenitfy if the tasks and
applied resources can be completed within the overall time frame. If they
cannot, then you will see negative slack. If there is say 1 day negative
slack, then the schedule needs to be reduced in overall time by one day.
This is achieved either by changing duration of the tasks or more
appropriately, assign additionaol resources if more resources will reduce the
task duration.

Hope this helps

Regards

DavidC

 

[Steve House]

A deadline behaves exactly as a FNLT constraint behaves when the
Tools/Options/Schedule entry "Tasks always honor their constraint dates" is
disabled - slack time for the task and its predecessors is calculated as if
the task had a fixed date of the deadline date associated with it but it
allows the Gantt chart scheduled date to reflect the actual date that will
be obtained if the plan is worked as presently structured. The little green
arrow on the graphic is the least important thing a deadline gets you. The
problem with using constraints instead of deadlines and disabling the "honor
dates" option is that the "honor dates" setting is global and while turning
it off allows MSP to predict the actual finish that will be obtained, in the
process you also disable obedience to SNET constraints and some tasks will
move earlier than it really is possible for them to occur (and with the
result that the calculated finish is now predicted on the invalid earlier
start dates).

This is why Jan and I go around and around - he seems to think I advocate
having the schedule ignore deadlines and contractual requirements when
nothing could be farther from the truth. I simply maintain it's more useful
for the schedule to predict what you're really going to than it is for it to
simply document what it is you need to get. If the two don't match, you
have to change the actual schedule staffing and workflow until it does (or
if that's not possible, go back to senior management with concrete data as
to why the requirments must be changed and update your resume if they refuse
to budge). FNLT constraints certainly clearly document your requirements but
so do Deadlines. The constraints, however, do nothing to help you predict
whether or not you're going to be successful in achieving those requirements
unless you pour over the schedule looking for negative slacks, nor if you're
missing your targets do they do much to help you figure out just how bad the
situation is or where you can best attack the problem to fix it.

I maintain the MSP is primarily a tool to help you determine exactly which
detailed plan out of all the different possible plans will be most able to
meet the project's time and budget objectives. To do that it needs to be
allowed to predict the varying results that will be obtained if you were to
adopt alternative workflow structures. Using deadlines instead of FNLT
constraints give you the best way to accomplish that. And when tracking
progress, if delays etc early on in the project will cause the finish to
violate its required date, the "missed deadline" red flag will immediately
tell you that the XX day delay in the start of task Q is causing you to miss
the required finish by YY days and you better do something about it while
you can and it also tells you what the date will be where you now WILL
finish if you ignore the warning.

If the schedule with FNLT constraints says you'll finish on time 01
September but Project calculates you'll finish 15 October when you remove
the constraints, my money is that if you try to actually do the project
according to the constrained schedule, you will actually finish later than
the schedule calls for and after the dust settles you'll find your real
finish obtained to be a heck of a lot closer to 15 October than it is to 01
September.

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


..