Schedule Risk Analysis
Project plans are of course about the future, and everything about the future has some uncertainty associated with it. When a task’s duration is estimated to be 5 days it is accepted that this will probably not turn out to be precisely true. There may be a small amount of uncertainty or a large amount, but there is definitely some and that’s where schedule risk analysis comes in.
As a result of this uncertainty about task durations, any estimate of project completion is just that, an estimate. It will be valid only to the extent that the estimates of task durations turn out to be true. Since there are generally many tasks, it is almost certain that many of them will take less time than estimated while others will take more time than estimated.
So, in reality the project finish is likely not to be as projected by a deterministic CPM or PERT but to be somewhere in a range of dates that might be spread symmetrically around that estimate. (Actually it is worse than that. As discussed later, using deterministic estimates also introduces bias so that these estimates tend to be systematically optimistic.)
Schedule Risk Analysis is a technique which recognizes this uncertainty by replacing the deterministic duration for each task by a distribution representing the range of likely durations. Analytic methods exist to process probability distributions in simple cases, but project networks are typically too complicated for these to be applicable.
The solution is to use Monte Carlo simulation. This is a bit like simulating a real life event by throwing dice except that it is done on a computer. Computers can generate what are called pseudo-random numbers. These are not truly random, in that they can be reproduced if one knows the generating mechanism, but absent that knowledge they pass sophisticated statistical tests designed to identify any non-randomness. Using these pseudo-random numbers, one can generate samples from any desired distribution, and these are used in Monte Carlo simulation to simulate physical systems over a large number of randomly generated scenarios.
Monte Carlo simulation has applications in many areas. In the context of a project network, Monte Carlo simulation:
- takes a sample from the user-defined distribution for each task duration;
- does a CPM analysis based on these sampled durations;
- stores the results of this time analysis (generally in a summary form like a histogram); and
- repeats steps 1 through 3 several hundred or thousand times.
At the end of this process it can produce histograms representing the probability distributions of any calculated result of interest, which generally include early and late start and finish dates, free and total floats, and cost for each task.
As a result, the estimated project finish date and other important milestones are represented by probability distributions rather than single-point estimates. Instead of predicting that the project will be completed on a certain date – a prediction which will almost certainly be proved wrong – one can make more realistic predictions such as “there is a 90% chance that the project will be completed by May 31st.”
But perhaps the most important reason for doing risk analysis is the bias mentioned earlier, which means that the single-point estimate of project completion made by deterministic CPM or PERT is often not even within the range represented by the probability distribution produced by risk analysis. The reason for this is a phenomenon called merge bias.
Merge bias occurs whenever two or more paths converge in a network and the uncertainty about their durations is such that any of them might turn out to be critical. To illustrate merge bias, consider a task which has just two predecessors which run in parallel. Suppose that each could take anything from 1 to 6 days with equal probability. And suppose further that they will not take fractions of a day. (This may sound rather contrived, and it is. However, it allows the point to be made by analogy with the throwing of dice and without getting involved in a lot of calculus.)
The expected duration of each of the individual tasks is of course 3.5 ( 1+2+3+4+5+6 all divided by 6). But what is the expected time for them both to be complete? The following table shows all 36 possible outcomes for the pair of tasks, which can be simulated by throwing two dice. (So, for example, if the first task takes 5 days and the second only 3 days, the time taken for them both to be completed, 5 days, can be looked up in the table.
|
|
|
|
|
|
|
1 | 1 | 2 | 3 | 4 | 5 | 6 |
2 | 2 | 2 | 3 | 4 | 5 | 6 |
3 | 3 | 3 | 3 | 4 | 5 | 6 |
4 | 4 | 4 | 4 | 4 | 5 | 6 |
5 | 5 | 5 | 5 | 5 | 5 | 6 |
6 | 6 | 6 | 6 | 6 | 6 | 6 |
Of the 36 possibilities, only one has 1 as the maximum while no less than 11 have 6 as the maximum. So with just two parallel paths it can be seen that the time it takes for both of the tasks to be complete is likely to be longer than the deterministic estimate of 3.5 days. If we do the math we find that the expected value is actually almost 4.5 days. With 3 parallel tasks, the expected value is almost 5 days, and with 5 tasks it is about 5.4 days. And with 10 it is 5.8 days. (Clearly it will converge on 6 days as the number of parallel paths becomes very large.)
Another way to look at this is to restate Murphy’s law, less pessimistically than Murphy:
If there are many things which could go wrong then at least one of them will.
And in a project network with parallel paths, only one path needs to “go wrong” to delay the project completion. (In this context “go wrong” just means to take longer than expected. This does not necessarily imply that a mistake was made, but could just be the result of the inevitable uncertainty involved in the original estimate.) This is merge bias.