Positive Total Slack Not Calculating off Deadline

P

Patrick D Orlando

Hello,

I am testing the use of MSP 2007 as my company transitions from 2003. I
just noticed that positive slack is not calculating properly off of deadlines
(ex: 8/26/09 Finish Date with an 8/30/09 deadline - Total Slack registers 0
days) Negative slack appears to work fine.

If I indent/outdent the task repeatedly it triggers the positive slack to
calculate as this time. Seems like a glitch, has anybody run into this
problem?

Thanks for the help,

Patrick
 
P

Patrick D Orlando

I also noticed that when I indent/outdent it was removing the relationship,
when there are no relationships or when I add relationships AFTER adding the
deadline the slack calculates properly.
 
R

Rob Schneider

Patrick said:
I also noticed that when I indent/outdent it was removing the relationship,
when there are no relationships or when I add relationships AFTER adding the
deadline the slack calculates properly.

Patrick,

I've not looked into replicating this on my machine (Project not at
hand) ... but you do have the lastest SP2 installed?
 
J

Jan De Messemaeker

Hi Patrick,

The positive slack from deadline seems to be a feature rather than a
glitch.
The reasoning is that a deadline after the task should not change the
critical path.

Not that I'm happy with that, I used to recommend this to calculate buffers.
So it's unfortunately back to the way we handled this in Project 1998 (where
deadlines did not exist): instead of using a deadline, add a Must start on
milestone after the task and link.That influences Total Slack BOTH
positively and negatively.

Hope this helps,

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
+32 495 300 620
For availability check:
http://users.online.be/prom-ade/Calendar.pdf
 
P

Patrick D Orlando

Thanks for your reply Rob,

I have not yet installed SP2 and will try now and see if this fixes the
problem. Fingers are crossed!!!

Patrick
 
S

Steve House

This is consistent with the formal definition of total slack as the amount
of time a task could be delayed without pushing back the project finish date
or finishing past a deadline, whichever is sooner. Consider a simple
sequence of 2 tasks linked FS leading up to a finish milestone calculated to
occur on 07 July. Those tasks are both critical and have zero slacktime.
Any delay to either of them will delay the finish past the current date of
07 July. Adding a deadline of 15 July to the finish does not change that -
it does not create slack time where none existed before. Even though you
may have a cushion before your drop-dead date, CPM still is focused on
getting the project done as far ahead of the deadline as possible.
 
R

Rob Schneider

Patrick said:
Thanks for your reply Rob,

I have not yet installed SP2 and will try now and see if this fixes the
problem. Fingers are crossed!!!

Patrick

Also see Jan and Steve's comments.
 
P

Patrick D Orlando

Thanks for your help Jan De Messemaeker,

Unfortunately that will not be acceptable to have artifically constrained
dates throughout the schedule for the purpose of slack calculations. Our
schedules get scrutinized by the DCMA 14 Pt Health Check Criteria and that
would cause violations.

It sounds like you agree with me in that deadline needs to calculate
positive slack when applicable, is there a process to get this change
incorporated my Microsoft?

Cheers,

Patrick
 
S

Steve House

Jumping in, as I indicated in my previous post, I must disagree. Slack is
computed against either the present end-date of the project or its required
end-date, whichever is earlier. Deadlines later than the presently
calculated end-date should not introduce any new additional slack time.
(Slack time is not the same thing as amount of time ahead of deadline, the
contingency or "cushion", you are presently scheduled to finish.) Only
deadlines earlier than the present end-date affect the slacktime
calculation, introducing negative slack into the picture.
 
J

Jan De Messemaeker

Hi,

That is certainly one fromal way to look at it.
The people who wrote Project 2000-2003 used a different definition which is
the one the poster (and I) preferred.
If 2007 is right, previous versions were wrong.
Theory of constraints is gaining a lot of ground as a PM method, and its
major theme is contingency (buffer)
Now that is becoming hard to come by with Project. Pity.

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
+32 495 300 620
For availability check:
http://users.online.be/prom-ade/Calendar.pdf
 
J

Jan De Messemaeker

Steve and all,

Especially consider the case of the final task in a project.
If that one has a deadleien beyond its finish date, in 2003 it had slack
Now it hasn't
The only way to show this contingency now is by using a MSO constrained
milestone.

OK, so that's what I tell people to do.

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
+32 495 300 620
For availability check:
http://users.online.be/prom-ade/Calendar.pdf
 
P

Patrick D Orlando

Steve,

Good to hear your feedback... While I understand your theory, understanding
when your schedule can slip (and how far) and not impact contractual
milestones is essential to the critical path methodology. Without the
ability to see positive slack you are missing the big picture on where you
can reallocate resources based upon available slack/schedule margin.

Without the slack calculating properly user would have to define calculation
fields to manually calculate these values which is undesireable.

Also - according to your interpretation the CPLI metric would be useless,
there would be no condition where the index would be >1.0.

Regards,

Patrick
 
S

Steve House

Oh I'm not saying one shouldn't have a quantifiable buffer, far from it.
I'm just not so sure it should be rolled into the slack time calculations.
The finish date referenced in CPM is the date calculated for the project
finish during the forward pass and makes no reference to later deadlines.
 
S

Steve House

How about simply insuring the deadline date is referenced with a symbol
defined in the Gantt bar styles? And if you want a numerical indicator of
the buffer, insert a calculated field of deadline minus early finish. Why
would you ever want to position a milestone in the schedule so it appears to
be ocurring on any date other than the one where it actually is most likely
to fall as driven by its predecessors?
 
R

Rod Gill

I have a macro that runs on project open that sets the Start no earlier than
date constraint for a task "End of File" to 5d after a Summary Task that is
the last to finish. In this way all tasks (except for "End of File") now
have slack. I add deadlines to all critical deliverables and my critical
path now flows through "important" task sequences and not necessarily the
last ones to finish.

For example, a schedule for a shut down often has preparation tasks that
must finish before the shut, but any slack before the must start on date of
the shut start renders the critical preparation tasks not critical. A
deadline on the last preparation Task now produces a critical path for
preparation. The shut tasks themselves are obviously critical, but they show
as none critical if there are any "tidy up after the shut" activities. A
deadline for the last shut task makes shut tasks critical

No deadline on tidy up tasks leaves them non-critical! I now report on
what's important which in this case is not necessarily the shortest path
thru the schedule.

There are other ways to achieve this, but the Filter Tasks With Deadlines
provides a magic exception report for time based progress.
--

Rod Gill
Microsoft MVP for Project

Author of the only book on Project VBA, see:
http://www.projectvbabook.com
 
J

Jan De Messemaeker

Because, Steve, I'm not interested (exageration..) in a critical path.
When things get critical it's usually too late.
I'm interested to know how much time I got left, and when I have to deliver.
Greetings,
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
+32 495 300 620
For availability check:
http://users.online.be/prom-ade/Calendar.pdf
 
S

Steve House

I want to know the critical path at all times because a: that's where the
opportunity is located; and b: because that's where the risk is
concentrated. Opportunity in the sense that if we're missing deadlines the
critical path is where we have leverage to exercise control and bring it
back on schedule. Risk, in the sense that if something is interfering with
a task's progress - resources fall ill or resign, parts on backorder, etc -
I need to worry more about tasks on the critical path than tasks off of it.
I know how much time is left and when I have to deliver, all I have to do is
look at a calendar. What I want is a tool that helps me predict outcomes of
the controls I can influence such as whether taking Joe off of A and putting
him on B make the project finish earlier or later? The question is not what
date do we need to hit; the question is how should I deploy Joe to best
achieve it. That's why I never want to see fixed dates in the plan unless
they're modeling a physical certainty set by an external force - the parts
for this task won't arrive before 15 July, that sort of thing. Fixing dates
makes it a nice documentation tool and schedule illustrator but it
completely cripples its usefullness as a predictor of outcomes because it
can no longer freely calculate the consequences of changes I might make to
workflow and resource deployment.
 
J

Jan De Messemaeker

Hi,

Total Slack is the one because it shows the available buffer for each task.
And a contractual due date may well be more important than a calculated
finish date..
Greetings,
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
+32 495 300 620
For availability check:
http://users.online.be/prom-ade/Calendar.pdf
 
S

Steve House

I don't doubt that a contracted due date is more important, in fact I'd
agree that it almost always is. But I still maintain that Project is best
used as a calculating tool to help you figure out exactly how you have to
organize the workflow and deploy the resources in order to create a plan
that will actually be able to meet that contractual due date. The
calculated end date is important because that's a valid predicition of the
date you're going to get with the plan as you have it presently structured.
Without knowing that date there's nothing to compare.
 
Top