Page 133 - Untitled-1

112 PRACTICAL SCHEDULING

• Your project has a low priority, or weak support from the sponsors.
• Key decision points. These would include design reviews, funding reviews,

permitting reviews, or anything that can bring the project to a temporary
halt while waiting for authorization to proceed.

Experience has shown that there is a high potential for delays in these situa-
tions. Yet we would not want to allow for such delays by adding time to the asso-
ciated task durations. We lose identification of why the task duration was
increased and by how much. Instead, it looks like we are allowing the extra time
to do the work, and (due to Parkinson’s Law) we end up taking the allotted
time, rather than leaving it for the purpose for which we added the contingency
in the first place.

The better idea is to add a dummy task at each of these potential delay points.
The task should describe the purpose of the delay allowance and be set at a dura-
tion that recognizes the potential situation, without adding a ridiculous amount of
slop to the schedule. An alternate method is to add a finish-to-start lag.

Then there is the issue of shared contingency buffers. I really like the idea of
shared contingency, whether using CCPM or traditional tools. There is nothing to
stop you from taking a string of tasks, squeezing the contingency out of the indi-
vidual task estimates, and creating a dummy task at the end of the string to hold
the sum of the contingencies. Using Goldratt’s approach, I would reduce the sum
of the individual contingencies by 50 percent.

For example, our expressway project has the following series of tasks associ-
ated with erection of the guardrail: Lay out and mark the location, Make holes for
the support posts, Place the posts, Attach and fasten the guardrails, Paint them,
Complete the landscaping. Each of these tasks has a most likely duration of 4
days, but the schedule shows them as 6-day tasks (with 50% contingency allowed
for each task). As an option, consider reducing the duration on each task to 4
days, and placing a dummy contingency task at the end, with a duration of 6 days.
The overall duration of the string of tasks is reduced from 36 days to 30 days (24
days for the 6 tasks plus 6 days for contingency). Psychologically, we needed the
2-day adder to feel comfortable with any single task, but the 6 days for the series
of tasks is within a reasonable comfort range.

With the task durations set at 4 days, we keep the pressure on to perform to
the most likely duration. The buffer task (contingency) causes the task to be
scheduled early enough to allow for reasonable slippage (even if using the ALAP
mode). If any of the tasks do slip, the amount of the slippage is removed from the
buffer. This retains the overall timing for the chain (until all contingency is ex-
hausted). By reviewing and managing the buffers, we can keep an eye on the con-
tingency situation. Admittedly, these concepts of buffer management come from