## PERT = Program Evaluation Review Technique

PERT is a technique for providing definitive estimates of how long it will take to complete tasks. We often estimate, or scope, the amount of time it will take us to complete a task or tasks. PERT allows us to provide not only an estimate, but a measure of *how good the estimate is*. Good estimates are a critical element in any software planning strategy. In this post, we will present an introduction to using PERT, explain how it works and how to interpret PERT estimates.

## Multiple estimates

Imagine we’ve been asked to predict how long it will take us to go to the store and get some vanilla ice cream. “It depends,” we think. If the traffic is light, and there is a short line at the checkout counter, 15 minutes. If traffic is average and we have to wait behind several people at the checkout line, 30 minutes. If there’s an accident on the way and traffic is backed up, it could take an hour.

We may not realize it, but we just created a PERT estimate.

## Definition of PERT

A PERT estimate uses three estimates for any given task, to provide both an expected duration for the task and an understanding of how much we might be off in our estimate. To create a PERT estimate, we first create three seperate estimates of the time it will take to complete the task.

- Optimistic, or best-case scenario. 15 minutes to get ice cream, if
*everything*goes right. - Likely scenario. 30 minutes is how long we think it will probably take to get the ice cream.
- Pessimistic, or worst-case scenario. 60 minutes if everything bad that could reasonably happen happens.

Next, we combine these estimates to create a single number that best predicts how long it will take. We create a weighted-average of the three values, but we count the “likely” estimate as being four-times more likely than either the optimistic or pessimistic estimate. This represents the *mean* estimate.

mean = (optimistic + (4 * likely) + pessimistic) / 6

The PERT *mean* estimate for our ice cream delivery is (15 + (4 * 30) + 60) / 6 = 32.5 minutes. We often see PERT estimates documented as all three values, 15/30/60.

## Basic PERT interpretation

A PERT estimate includes an approximation of standard deviation (stdev) based on the optimistic and pessimistic values. Stdev provides us with insight into the shape of the probability curve represented by the estimates.

stdev = (pessimistic – optimistic) / 6

The PERT stdev for our ice cream delivery is (60 – 15) / 6 = 7.5 minutes.

The PERT estimate is a representation of a beta distribution. The math is pretty complex, and applying it to a single estimate can give us a false sense of precision. Remember that the numbers we put together in the first place are our best guesses, so doing more precise math on rough estimates doesn’t give us a more precise PERT estimate, just more math.

The beta distribution is very similar to a normal distribution (the familiar bell curve), when it is balanced. This similarity is used to simplify the application of PERT. The standard simplification in using PERT is to treat estimates as if they represented the following probabilities:

- Optimistic: 5% of the time we will complete our task in less than the optimistic time estimate.
- Likely: 50% of the time we will complete our task in less time than the likely time estimate.
- Pessimistic: 95% of the time we will complete our task in less than the pessimistic time estimate.

## More advanced PERT analyses

What happens when we want to combine several PERT estimates for our project? Imagine we had to make two trips to buy ice cream, and we want an estimate of how much total time it would take.

Here’s the wrong solution. Add the two PERT estimates. 15/30/60 + 15/30/60 = 30/60/120 with a mean of 65 minutes and a stdev of 15 minutes. This would say that there is a 90% chance that we will spend between 30 and 120 minutes getting ice cream.

Again, without much math, there’s an intuitive reason why this is wrong. We are not taking into account the likelihood that our two trips will take different amounts of time. If we hit bad traffic in one trip, that doesn’t mean we are likely to hit it on the second trip as well. If there is 1 chance in 20 that we hit out pessimistic estimate, then there is only 1 chance in 400 that it would happen twice. So really, there is a 99.5% chance that we would have between 30 and 120 minutes of total travel. We can narrow down this estimate a lot.

To combine the two estimates, we combine the underlying probability distributions that they represent. With the PERT approximations, we would do this as follows:

- The combined mean is the sum of the two old means. 32.5 + 32.5 = 65 minutes.
- The combined stdev is the square root of the sum of the squares of the two old stdevs. SQRT(7.5^2 + 7.5^2) = 10.6.
- The combined optimistic estimate is the mean minus ( 3 * stdev). Optimistic = 65 – (3 * 10.6) = 33 minutes.
- The combined pessimistic estimate is the mean plus (3 * stdev). Pessimistic = 65 + (3 * 10.6) = 97 minutes.
- Our combined PERT estimate is 33/65/97 with a mean of 65 minutes and a stdev of 10.6 minutes.

This combined window is more narrow than the “just double everything” approach, and reflects that the law of averages will eventually narrow down the interval for our estimate – because some tasks take longer than estimated, and some take less time. It all averages out in the end, as long as the estimates are good to begin with.

## Beyond PERT

** **

- One question that always comes up when planning is how you created your estimates.
- Managing releases with timeboxes.
- Updating an existing release schedule with requirements changes.

## Summary

We have enough information to know how to create a PERT estimate for a single task. We also know how to combine those PERT estimates to provide a multi-task estimate. There is a lot more we could cover, such as showing the impact of this statistical technique on critical path analysis, or incorporating an approximation of the correlation of estimates (if this task takes longer than estimated, then that task will probably take longer than we estimated). That’s too much detail for this introductory article – just know that it’s out there. What we cover here represents what the vast majority of project managers understand about PERT (and maybe a bit more).

– – –

Check out the index of the *Foundation Series* posts which will be updated whenever new posts are added.