Suppose you had to create planning estimates for ten tasks, and each task had a planning estimate with 68% reliability. For simplicity’s sake, let’s also suppose all ten tasks are normally distributed, have a standard deviation of 15, and the mean, median and mode are 50, and the range spans between 0 and 100. The 68% reliable planning estimate for each task is one deviation to the right of the mean, or, simply, 65. So, the project total would be 10 x 65 = 650 (hours, weeks, whatever).

If the first task finished in 50, and the planning estimate was 65, then your schedule (or budget, depending on what’s being estimated) has saved 15. That 15 can be used to offset a different, later task that finishes later than the planning estimate. But we expect that only 2 or 3 tasks will finish later than their planning estimates; most should finish on or before their planning estimates, since our planning estimates have 68% reliability.

Let’s simulate the ten tasks. I’ll use Palisade’s @Risk Excel add-in to obtain normally-distributed actuals for the ten tasks:

Of the ten simulated tasks, only one, task #4, exceeded the planning estimate. The project’s planning estimate for all ten tasks was 650; the actual ten tasks took only 505. So, there were ample other tasks besides task #4 (and #2, which had an actual result = planning estimate) that “covered” the late (over-budgeted) task #4.

We could simulate this hundreds of times and there would be very few instances where the project estimate of 650 would be exceeded by the sum of actual results for each of the ten tasks. You might be tempted to think that 32% of projects should fail their schedule and/or budget if each task in the project was only 68% reliable, but that isn’t correct. In fact, this theoretical project has a 99.9% probability that the actual results for all ten tasks will be equal to or less than the planning estimate of 650. If you’re not familiar with statistics, this is a surprising result. When tasks have planning estimates that are > 50% reliable, the project generates a buffer of sorts that can be used to offset the unlikely occurrence that a task will finish later than its planning estimate.

What I’m describing is a theoretical project — not a real one, though. In tomorrow’s post, I’ll touch on Parkinson’s Law, which explains why the theoretical project still has plenty of risk of exceeding its planned schedule and budget.