Critical Chain 3

Thursday, September 20th, 2007

I’ve been discussing Eli Goldratt’s third business novel, Critical Chain, and established project management techniques, like PERT.

One subtle issue with charting the critical path of a project is that the individual task estimates, which start out as distributions — defined by optimistic, most likely, and pessimistic estimates — get boiled down to one-dimensional expected numbers.

This lets us define a critical path, but — for simplicity and clarity’s sake — it ignores the potential for other paths to become critical.

Let’s say we add up all the variances along our critical path — Tasks A, C, and F, in our example — and they’re fairly small, so that our critical path has a duration of 7 ± 1 days. From that we might assume that our project has a 98-percent chance of finishing in 9 days — but what we’ve calculated is the chance that the original critical path will finish in 9 days.

What if the non-critical path along Tasks B and E takes 6 ± 2 days? We only have a 93-percent chance of finishing that path in 9 days.

Perhaps that seems academic in our toy problem, but real projects with many dependencies can demonstrate an alarming cascade effect, where every task seems to be waiting for something else to get done.

Returning to our toy problem, what happens if we replace Task A with three identical tasks, Tasks A1, A2, and A3? Our PERT analysis does not change at all, but clearly the fact that they average three days each does not mean that the dependent Task C gets to start after three days. It has to wait for the slow-poke.

Another academic complaint about PERT analysis is that it uses beta distributions, which may or may not reflect the actual distributions, and that it assumes that those beta distributions are numerous enough to sum to a fairly normal distribution, via the central limit theorem.

Less academic is the concern that the task durations are not independent. If it takes longer than planned to design a component, that might very well imply that it will take longer to develop a prototype, to produce it, to test it, etc. If that’s the case, then pooling all the safeties into one buffer at the end won’t reduce the total safety needed — but it should still reduce the threats from Student syndrome and Parkinson’s Law.

A bigger issue still is that people are notoriously bad at estimating task durations, and they are notoriously overconfident in their ability to estimate. The optimistic and pessimistic estimates are supposed to book-end a range that covers almost all possibilities — 99 percent — but far more than one percent of tasks fall outside those estimated ranges.

Leave a Reply