Entering explicit slack into a plan

[Clive]

Say I want to put slack into my plan - overall 10%.

And say I want that to be 10% on the duration of each task (I am
assuming that 10% slack per task results in 10% slack / tolerance of
duration overall - that may not be true)

Every task has a target end date. I added, say, 5 days slack to make a
tolerable end date.

Say the expected end date for a task slips 2 days later than the target
end date. What tools are available in MS-Project so that in the plan
the slack gets "consumed" i.e in this situation the task is 2 days late
finishing but we are left with 3 days slack. The "tolerable" end date
does not slip until I have consumed the explicit 5 days slack.

Thanks

Clive

 

[Mike Glen]

Hi Clive,

Welcome to this Microsoft Project newsgroup

If you add 10 % to each Duration you don't need to identify any slack. As
Work is done, you enter the Actual Work and the Remaining Work. Then
Schedule uncompleted work to restart from the Status Date, to push forward
all the subsequent dates. If the task is finished early, then the entering
of zero in Remaining Work will pull tasks back. You could use Deadline
dates for each task which will give you an Indicator when exceeded. All
this assumes you haven't entered any Start or Finish dates for each task as
that will cause unwanted constraints.

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

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

Mike Glen
MS Project MVP
See http://tinyurl.com/2xbhc for Project Tutorials

 

[Clive]

Hi

I worked out a way to do what I wanted - but it is very clumsy

Say task A is the one I want to add slack to. And task B is the one
that needs to follow Task A

I calculate my required slack, say 10 days, and create a new task S of
this duration

I then put in the following dependencies

A > S > C

I then FIX the dates of S

I then CHANGE the dependencies to become

S > C
A > C

The effect of this is that C doesn't change its start date because it
is driven off tasks S th edates of which have become fixed.

I then baseline the plan - the only purpose of this is to make visual
when milestones have slipped by looking at the Tracking Gantt

Now if task A slips anything LESS than 10 days, then B does NOT slip
its start date because B is dependent on a FIXED task S.

However, if A slips completion by GREATER than the slip in task S, then
C will slip its start because of the dependency A > C. This will be
visible in the Tracking Gantt.

So I can put in explicit slack, S, and allow it to be "Consumed" by
task A and I become aware when the slack is all used up.

The judgement is that the greater number of such slack tasks I put in
down at task level I can detect slippage quite early - but it is a lot
of work to add this slack. However, putting this slack at the summary
task level is a reasonable compromise - but I might miss slippage until
it becomes fairly large. I only want to worry when the slip exceeds my
slack.


Clive

 

[Mike Glen]

Hi Clive,

I can see where you're going, but what happens if A finishes earlier than
planned? You would then have a gap before C starts, because it is driven by
the completion of S. You have thus lost flexibility by inserting
constraints (assuming a must start on constraint for S).

Or have I mis-read you?


Mike Glen
Project MVP

 

[Jan De Messemaeker]

Hi Clive,

I can only recommend reading E. Goldratt's book on Project Management - The
critical chain.
I hope that after reaqding it, you will be just as convinced as I am that
you do NOT add buffers to each task.
You just work with the total slack on the project - too long to explain,
your should really ra the book.

Hope this helps,

 

[Clive]

I see what you mean - it would cause me to delay the start of the next
task.

But wouldn't this also happen if I had a task A planned to take 5 days
and completed in 2? I would have to manually edit the task A duration
from 5 down to 2 - and set its completion to 100% - then see the impact
on other dates of other tasks against their baseline dates.

 

[Mike Glen]

Hi Clive,

Welcome to this Microsoft Project newsgroup

Yes of course - that 's what the PM does - updates the project. However,
don't use 100% complete, use Actual Work and Remaining Work. You might like
to have a look at my series on Microsoft Project in the TechTrax ezine,
particularly #23 on Tracking, 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

 

[Steve House [MVP]]

Slack and a buffer are two different things. Slack is the amount of time a
task finish *could* be delayed before it affects something downstream. A
buffer is how much allowance for potential delays you're building into the
schedule - in other words, a built-in inefficiency. Seems like you're doing
the latter - saying the Task "A" should be allowed to absorb up to 10 days
of delay in finishing before it starts to affect the scheduled start of Task
"B." But why? If task "A" finishes on time, you now have to advance B's
start by 10 days ahead of where everyone on the team expected to start
according to the published schedule, the resources having to juggle around
the earlier start at the last minute. Seems like it is far better to
estimate the required work for each task as accurately as possible and
create a plan based on that assumption. The place for continencies is in
the promised delivery, on the order of "our plan predicts we'll finish 01
Sept so we'll add 2 weeks to that and tell the client we expect to finish by
15 Sept."