Criticisms of PERT
The PERT method has been criticized because it is based upon assumptions that
sometimes yield results that are problematic. For example, it ignores human behavior and
assumes that whenever an activity is completed earlier than scheduled that succeeding
activities will start straight away—regardless of the fact that resources might not be available
or that people procrastinate. PERT assumes that activity durations are independent. But
whenever resources are transferred from one activity to another, the durations of both
activities are changed. In other words, activity durations are usually not independent: one’s
gain is another’s loss. PERT also assumes that three activity estimates are better than one.
Estimating three durations instead of one takes more work, although unless based upon good
historical data, the three are still guesses, which is not much of an improvement over a single
“best” guess. The advantage of the pessimistic estimate is that it removes the burden of having
to make a single estimate that cannot account for possible setbacks. Accuracy of estimates
often depends on experience.
Whenever a database can be formed based upon experience from similar activities from
previous projects, a “history” can be developed for each kind of activity that can be used to
estimate the times for future similar activities. In fact, reliance on good historical data for
estimating times makes the PERT method appropriate for projects that are somewhat
“repeatable” (and less so for the research and first-of-a-kind projects for which it was
originated). Because of this the PERT method tends to be used in construction and
standardized engineering projects, but seldom elsewhere. Despite criticism, PERT remains a
useful approach for analyzing the effect of time uncertainty on project schedules. Some of
PERT’s shortcomings are addressed by simulation.
Project Buffer and Feeding Buffers
But, you ask, what happens if activities get delayed? Won’t that delay the project? To
protect against delays, a project buffer (time contingency) is placed at the end of the project.
The date at the end of the buffer is the date to which the project manager commits to
completing the project. (Note: the project manager commits to the date for completing the
project, but people responsible for the activities in the project do not commit to anything; they
just try to complete their activities within their realistic, average time estimates.) Now you ask,
won’t adding a time buffer lengthen the project? The answer is no, because when the project
manager receives the “average” time estimates she cuts them in half! The rationale is that most
people submitting average time estimates build into them a contingency (i.e., they pad the
estimate) to give each activity a greater than 50 percent chance of being completed by that
time. Reducing the estimate by 50 percent removes that contingency. (It should be noted,
however, that when people are asked to provide “realistic” estimates, i.e., estimates that do not
include contingencies, which is what CCM prescribes, then the estimates are not cut in half.)
Eliminating contingency times from the estimates is okay because any needed contingency is
provided for by the project buffer.
To illustrate, look at Figure 7-17 where the durations everywhere have been cut in half
from Figure 7-16. The total number of days cut from the critical Path P–Q– R–Z, 16 days (4
6 4 2), becomes the project buffer. Note also in the figure the presence of a feeding buffer,
which is the sum of the number of days removed from the noncritical Path S–T, 12 days (2
10). In general, CCM calls for a single project buffer at the end of the critical path as well as
feeding buffers where every noncritical path feeds into the critical path. The feeding buffer is
intended to protect against delays in noncritical activities. While project buffers and feeding
buffers bear a resemblance to slack, they are not slack. Whereas with traditional methods
activities are scheduled as early as possible and slack time may be used to delay activities when
necessary, in CCM noncritical activities are started as late as possible, but with buffers. The
buffers belong to the project manager, and only she can allocate time from them, which
happens whenever an activity exceeds its estimated average duration. Since every activity has
only a 50 percent chance of exceeding its average time, the buffers provide more than enough
time to compensate for delayed activities. In fact, because the buffer is “owned” by the project
manager, its size can be reduced substantially for two reasons. The first is the mathematical
effect called aggregation, which in a project means that it is extremely unlikely that all activities
would experience bad luck and that many will finish ahead of the planned average time, te .
When the time usually allowed to “pad” each activity is cut from the activity and is instead
included in a single buffer at the project level, the size of the required project buffer ends up
being substantially less than the total padding removed from all the activities. The aggregation
effect—well known in risk management and the basis of the whole insurance industry—is
explained in the Appendix to this chapter.
