Negative Slack & Multiple Critical Paths

[MMMProject]

I have several critical paths showing in my project and believe it is due to
each of these tasks showing either zero slack or negative slack. My questions
are as follows:

a) Should there always be only 1 critical path? If there are multiple task
collections that are at zero or negative slack would these not produce a
critical path per collection?

b) What causes negative slack? Can you please specify the exact calculation
for Total Slack? I have a task that is fixed duration (90 days) but the work
is only 9 days and it is showing with a large negative slack. I would think
this would be true only if the work could not be completed by the task end
date, but this is not the case. If it matters, this task was not in the
original baseline.

 

[Jim Aksel]

One additional place to look is the Deadline column. If you find it there,
have Trevor send you the $10.
--
If this post was helpful, please consider rating it.

Jim

Visit http://project.mvps.org/ for FAQs and more information
about Microsoft Project

 

[Jim Aksel]

Then how about a Red Ant or a Crown Lager?

Jim's right. More than one CP is possible and Deadlines will cause negative
Total Slack.
When I first used them I thought they just put a convenient green arrow on
the Gantt Chart and a little warning in the Indicators, and I got a shock to
discover that they have an effect on he calculations.
Deadlines probably rates as a kind of Date Constraint, so no $10.
Check Tools, Options, Calculation to see if you have multiple CPs turned on
for "loose end" branches.

Trevor RabeyTrevor Rabey 0407213955 61 8 92729485 PERFECT PROJECT PLANNING
www.perfectproject.com.au

 

[Mike Glen]

Hi MMM,

Welcome to this Microsoft Project newsgroup

The others have answered all but one question on how slack is calculated.
You might like to have a look at my series on Microsoft Project in the
TechTrax ezine, particularly #1 and its reference to Network Analysis, at
this site: http://tinyurl.com/2xbhc or this:
http://pubs.logicalexpressions.com/Pub0009/LPMFrame.asp?CMD=ArticleSearch&AUTH=23
(Perhaps you'd care to rate the article before leaving the site,
Thanks.)

FAQs, companion products and other useful Project information can be seen at
this web address: <http://www.mvps.org/project/>

Hope this helps - please let us know how you get on

Mike Glen
MS Project MVP

 

[davegb]

Hi MMM,

Welcome to this Microsoft Project newsgroup

The others have answered all but one question on how slack is calculated.
You might like to have a look at my series on Microsoft Project in the
TechTrax ezine, particularly #1 and its reference to Network Analysis, at
this site:http://tinyurl.com/2xbhc or this:http://pubs.logicalexpressions.com/Pub0009/LPMFrame.asp?CMD=ArticleSe...
(Perhaps you'd care to rate the article before leaving the site,
Thanks.)

FAQs, companion products and other useful Project information can be seen at
this web address: <http://www.mvps.org/project/>

Hope this helps - please let us know how you get on

Mike Glen
MS Project MVP








- Show quoted text -

The calculation for Total Slack is: TS = LS - ES = LF - EF where LS =
Late Start, ES = Early Start, LF = Late Finish, EF = Early Finish.

Negative slack means you're trying to get 10 lbs of manure into a 5 lb
bag. The sum of the durations of the tasks along the Critical Path is
greater than the available schedule time between your Project Start
and Project Finish dates. This of course depends on having a
meaningful CP, which, as others have pointed out, can be tricky. The
biggest problem usually is constraints, particulary SNL, FNL, MSO and
MFO. I always start by scheduling without constraints, even if I know
I'll have some before I'm done. It's important to know if you
unconstrained schedule is at least somewhat realistic. If your
unconstrainded schedule finishes before on on your intended end date,
throw a party! It doesn't seem to happen very often. More likely, it
will finish later than you would like. How much later is important
information. If it's a 6 month schedule, and your unconstrained
schedule is a few days late, shouldn't be much of a problem to attack
the CP and make up those days. OTOH, if its a month late, there is
serious cause for concern. You're probably trying to do the
impossible. There is a limit to how much can be done in a given amount
of time. Back to the 10 lbs of manure in a 5 lb bag.

If you now enter the ending constraint into the schedule and try to
force it back, you'll see the negative slack. Bad news! Either way,
the problem is now defined. You know how bad it is. How you handle it
from here depends on your PM skills, your team, management, the client
and a dozen or so other factors. But it needs to be dealt with
somehow.

Hope this helps in your world.

 

[MMMProject]

Thank you for all your help. I still have the issue of multiple critical
paths, but am working through your suggestions.

I would like the expert opinion on only ONE critical path. It seems to me
that there can be multiple critical paths if tasks have no slack. Please
confirm.

Thank you.

 

[Mike Glen]

It is unusual to have only a single critical path, most projects have some
parallelism somewhere in the network. If you worked through my reference to
Network Analysis, if the machining task's duration was estimated as 11
weeks, then the critical path would have gone through that task as well as
through cut and weld - 2 critical paths.


Mike Glen
Project MVP

 

[davegb]

Thank you for all your help. I still have the issue of multiple critical
paths, but am working through your suggestions.

I would like the expert opinion on only ONE critical path. It seems to me
that there can be multiple critical paths if tasks have no slack. Please
confirm.

Thank you.









- Show quoted text -

In addition to Mike's comment, I would add that while it is not
unusual to have multiple CPs, it is not good scheduling practice. I
would usually "fine tune" (read "fudge") the schedule to make one of
the CPs longer or shorter. Some will disagree with me. I was taught,
many years ago, by expert schedulers, that scheduling is a game of
probabilities. A schedule is a time-based simulation of your project,
and, as most simulations, is not 100% accurate.

Part of the reason we do CPM analysis is to help us priortize among
the many competing issues demanding the attention of the Project
Staff. Without some method of priortizing, projects quickly degenerate
into chaos. By using Total Slack as one factor (there are others to be
considered as well), it helps us to determine where to put our
resources and our energy on those tasks most likely to put off the end
date. The Critical Tasks are the ones most likely to do so, at least
in an analysis at this level. (More sophisticated schedule probability
analysis tools are available, just not in common use at this time.)
The tasks with very little TS are the next most likely. And so forth.
So CPM is, among other things, a prioritization tool.

If we have too many Critical Tasks, the probabilitiy of schedule
success is lower than if we have fewer Critical Tasks. As the number
of CTs go up, the probability of sucess decreases exponentially.
Multiple CPs decrease the probability of success. Since this is only a
simulation (something many practitioners of the art of scheduling have
long forgotten), it is ok for a knowledgeable scheduler to adjust the
model if s/he feels it is not accurately representing reality or
giving misleading results. It is not cast in concrete! I make
adjustments to a schedule at certain times, one of these being when I
see multiple CPs over a long portion of the project.

Hope this helps in your world.

 

[Steve House]

Exactly why I try to discourage people from using FNLT or MFO constraints to
express their objectives. In my book, constraints model physical realities
that impact the schedule - parts for Task X are on backorder until 01 Nov so
a SNET constraint of 01 Nov insures that's the earliest it will be scheduled
even if everything else in the project such as links and resource
availability says it could go earlier. Using a deadline instead of a FNLT
constraint shows you visually in the Gantt chart A) if you're meeting your
objectives; B) if not, clearly shows how bad the situation is; and C) allows
you to see at a glance how effective the corrective action you're
considering is likely to be - does the computed date of the finish move
closer or farther away when I change X? Using a constraint always results
in the Gantt chart showing the finish as happening as it you want it to even
when it's physically impossible for it to actually happen that way, and you
have to dig deaper by filtering for negative slacks etc to find the warning
signs of impending trouble.

 

[Steve House]

Good network design practices say that a project should have at the least a
start milestone and a finish milestone. (It's a shame MSP doesn't enforce
that practice.) All other tasks and milestones in the project must have at
least one predecessor and at least one successor. If a task has no activity
as its predecessor, the start milestone is the predecessor. If a task has
no activity as a successor, the finish milestone will be the successor. In
other words, no chains of tasks should be allowed to terminate anywhere
except on the finish milestone. This may result in multiple pathways
running between start and finish and of these, one and only one pathway will
be the longest. That's the classic definition of the critical path. In
that context, viewing multiple critical paths is really there to be used
when you have a consolidation master plan file consisting of a number of
embedded independent projects and you want to see all their critical paths
inidcated rather than just the path in the one project that happens to be
the longest.

Now if there are intermediate tasks or milestones in the project that have
deadlines associated with them and the schedule is such that they're missing
their deadlines, MSP also considers the tasks in the chain leading up to the
deadline to be critical and will turn them red as well when you say you want
to see the critical path. I tend to think of this as being a beneficial
artifact - in a sense these are critical tasks that don't lie on the
critical path. They are critical in the sense of having zero slack with
respect to the deadline even though they may still have positive slack with
respect to the overall project finish. Perhaps they don't fit the textbook
definition of "critical" or "critical path" but I think we'd agree that it's
still important to red-flag and monitor that chain of tasks - if it wasn't,
we wouldn't have put a deadline in there in the first place.