June 18th, 2009

Advanced PERT Estimation

Creating a PERT estimate for a single task is both easy and straightforward. Creating an estimate for a set of tasks is still easy, but requires a little bit of math. Combining PERT estimates for tasks is easy, but not as obvious. Roll up your sleeves and dive in.

PERT Estimate Refresher

When estimating how long it will take you to complete a task, you shouldn’t estimate with a single value like “four hours.” “Four hours” does not provide enough information. Estimates reflect that there is uncertainty, and that single value does not give you any insights into how uncertain your estimate is. Your estimate could be “four hours plus or minus one hour” or it could be “at least four hours, maybe as much as sixteen hours.”

A PERT estimate, as we showed in our earlier PERT estimation article represents a distribution of likely effort for a particular task. To create a PERT estimate, you create three values -

  1. The “best case” (shortest) amount of time it will take to complete the task.
  2. The most likely amount of time it will take to complete the task.
  3. The “worst case” (longest) amount of time it will take to complete the task.

A PERT estimate is presented in the form “Best Case / Most Likely Case / Worst Case.” If your estimate is “four plus or minus two hours” you would write 2/4/6 as a PERT estimate. Sharing “2/4/6″ as an estimate still doesn’t tell anyone else what you mean. A PERT estimate embodies some probability around completion time. You are precisely saying (for a 2/4/6 PERT estimate):

  1. There is a less than 1% chance that this task will take less than 2 hours.
  2. There is a 50% chance that this task will take less than 4 hours.
  3. There is a greater than 99% chance that this task will take less than 6 hours.

This explicit statement of probabilities represents a distribution of likely outcomes. Statisticians would phrase it in a confusing (but mathematically important) way. They would say “if we sampled a large population of people (like you) doing this task, no more than 1% of them would complete the task in under 2 hours, no more than 1% of them would spend more than 6 hours on this task, and half of the people would complete the task in under 4 hours.” For the purpose of estimation, you can ignore the statistic-speak and just look at the “odds” of how long it will take you to complete the task once.

[larger image]

If you were to create a histogram of thousands of executions of the task, it would look like the diagram above.  This is the traditional bell curve shape we are used to associating with a normal distribution, but it actually represents a PERT estimate.  A PERT estimate is a distribution of possible outcomes, based on a beta distribution.  Another way to look at a PERT estimate is in terms of cumulative probability of a task being completed.  The same data in the graph above, when presented as a cumulative distribution function (CDF) looks like the following:

[larger image]

Here’s the rub – you don’t really know if the beta distribution is the right one.  Primarily because you can’t precisely know the actual probabilities.  So, you have to pick a distribution function to represent those probabilities.  There is debate about the right distribution function to use for estimation – check out this great article for hard core stats guys.  Here’s a cautionary warning from their conclusions:

Although bias stemming from misspecified activity time probability models is rarely mentioned in introductory discussions, we have seen several instances of this bias in simple examples. First, and perhaps most important is the uncertainty as regards the underlying activity time probability models. The literature offers no less than five procedures for translating the subjective estimates (a,m,b) into specific β-distributions. As shown, the methods lead to distinct β-distributions, and the PERT approximation need not satisfactorily estimate any of them.

Essentially, they are saying “you can’t really know the right shape for a distribution curve of possible outcomes – so don’t get carried away.”  And they then go on to suggest using a simpler model than the beta distribution for estimation.  Their suggestion is to use a triangular distribution (looks like a triangle, instead of a bell curve), because the math is easy.  With spreadsheets, we can still do “easy” math with a better distribution

The beta distribution for a symmetrical PERT estimate looks very much like a normal distribution.  You can see this by comparing the cumulative distribution function of the PERT and normal models for this 2/4/6 example.

[larger image]

Based on this similarity in distribution, and the inherent uncertainty in what the shape of the distribution really looks like, there are some benefits to treating the PERT estimate (2/4/6) as a normal distribution where the high and low values represent +/- 3 sigma bounding.  This approximation provides us some benefits when aggregating individual task estimates into combined project estimates.

Continued on the next page…

Post to Twitter Post to Facebook

Pages: 1 2

Recommended Reading

Please Rate This Article!
Just Plain BadLameAverageGoodGreat (4 votes, average: 5.00 out of 5)
Loading ... Loading ...

6 Responses to “Advanced PERT Estimation”

  1. Rolf Goetz Says:

    Superb explanation! Thanks Scott

  2. Scott Sehlhorst Says:

    Thanks, Rolf!

  3. Planet Project: Humbling Exercise on Estimation Says:

    [...] Advanced PERT estimation (on Tyner Blain) [...]

  4. Planet Project: ProjectEstimation Says:

    [...] Advanced PERT estimation (on Tyner Blain) [...]

  5. Mike Burrows Says:

    Thanks Scott.

    If you’re doing iterative development you might find interesting the calculators (“Release Calculator” and “Wiggle Room Calculator”) that you can find in the sidebar of my website positiveincline.com. Tweet me (@asplake) if you find them interesting/useful or have suggestions for others.

    Mike

  6. Scott Sehlhorst Says:

    Hey, thanks Mike. Pretty neat calculators.

    Somewhere (or some-when) I wrote up an analysis of agile estimation, based on Mike Cohn’s work. Maybe an old blog article that I can’t find, but I think it was something for a client. The key element was that using velocity to manage / predict “rough estimates” based deliverability distinctly from detailed (PERT) estimates for tasks made sense, because you still get the feedback loop that removes uncertainty from the estimation process. Can’t find the write-up.

    Long story short, I think the calculator can come in handy for that ‘planning estimation’ phase.

Join The Discussion

Loaded Web - Global Blog & Business Directory