| Download a pdf copy of this help file here |
See also: Project risk analysis introduction, Project cost risk analysis, Model design introduction
Schedule risk analysis uses the same principles as cost risk analysis for modelling general uncertainty and risks and opportunities. However, it must also cope with the added complexity of modelling the interrelationships between the various tasks of a project. This section looks at the simple building blocks that typically make up a schedule risk analysis and then shows how these elements are combined to produce a realistic model.
A number of software tools allow the user to run Monte Carlo simulations on standard project planning applications like Microsoft Project and Open Plan. However, these products do not have the flexibility to model discrete risks and feedback loops, described below, which are common features of a real project.
The most flexible environment for project schedule modeling remains the spreadsheet and all of the examples below are illustrated in this format.
A project plan consists of a number of individual tasks. The start and finish dates of these tasks can be related in a number of ways:
One task cannot start until another has finished (the link is called finish-start or F-S). This is the most common type of linking in project planning models.
One task cannot start until another task has started (start-start or S-S).
One task cannot start until another has been partially completed (start-start + lag or S-S + x);
One task cannot finish until another has finished (finish-finish or F-F);
One task cannot finish until another is a certain way from finishing too (finish-finish-lag or F-F-x).
The
figure on the right shows
how these interrelationships are represented diagrammatically. In the
rest of this topic we will use the notation '(a, b,
c)' to denote a Triangle(a, b,
c) distribution. So: Lag(5,
6, 7) wks is a lag modelled by a Triangle(5, 6, 7) distribution in units
of weeks; Task 1(2, 4, 6) wks is a task (Task 1) with duration Triangle(2,
4, 6) distribution in units of weeks.
Figure
1: Example
model
Project_schedule_1 - a
project schedule model structure.
It is essential that a schedule risk model is set up to be as clear as possible, because it can easily become rather complex. The figure above illustrates a useful format, where all of the assumptions are immediately apparent.
More complex relationships involving several tasks can now be constructed. So far, bold lines have been used to indicate the links between tasks. Dashed lines are now introduced to illustrate links that may or may not occur (i.e. risks and opportunities). Risks and opportunities can be modelled in two ways: by modelling the additional impact on the task's duration should the risk occur, as shown in Figure 2, or by separately modelling the total durations of the task should the risk occur or not occur, as shown in Figure 3. In the example of Figure 2, Task 2 is expected to take (6, 7, 9) weeks but there is a 20% chance of a problem occurring that would extend the task's duration by (4, 6, 9) weeks. In Figure 3, Task 2 is estimated to take (6, 7, 9) weeks but there is a 20% chance that a particular risk will increase its duration to (10, 12, 15): there is also an opportunity, with about a 10% chance of occurring, that would reduce the duration to (5, 6, 8). The start of Task 3 is equal to a Discrete distribution of the finish dates of Task 2's possible scenarios.

Figure
2: Example
model
Project_schedule_2 - modeling
schedule risk as additional duration.

Figure 3: Example
model
Project_schedule_3 - modeling risk as alternative durations.
The most common multiple relationship between tasks in a project schedule is where one task cannot start until several others have finished, which is modelled using the MAX function.
In traditional project planning, the duration of each task is given a single-point estimate and an analysis is performed to determine the critical path, i.e. the tasks that are directly determining the duration of the project. In a project schedule risk analysis, the critical path will not usually run through the same line of tasks in every iteration of the model. It is therefore necessary to introduce a new concept: the critical index. The critical index is calculated for each task and gives the percentage of the iterations that that task lies on the critical path.
The critical index is determined by assigning a function to each task in the risk analysis model that generates a '1' if the task is on the critical path and a '0' if it is not. This function is nominated as an output and the mean of its result is then the critical index. It is often not necessary to calculate the critical index for every task. The structure of the schedule will usually mean that if one task is on the critical path, several others will be too, or that the critical index in one branch is one minus the critical index of another.
The figure below illustrates the sort of logic that one can usually apply to quickly determine critical indices. In this example, tasks A and J are always on the critical path, therefore CI(A) = CI(J) = 1
![]()

Task linking to determine critical index logic.
i.e. for this example, it is only necessary to determine p and q, and all of the other critical indices can be deduced.
p can be determined by writing the following function:
![]()
i.e. if the start of task J equals the end of task F, return a '1', otherwise return a '0'.
q can be determined by the following function:
![]()
i.e. if the start of task F equals the end of task E and the start of task J equals the end of task F, return a '1', otherwise return a '0'.
If the critical index is close to zero, reduction in the duration of the task is very unlikely to affect the project's duration. On the other hand, progressively larger values of the critical index indicate increasing influence over a project's duration. It therefore helps the project manager target those tasks for which she should attempt to reduce the duration or reschedule within the project plan, thus removing from the critical path.
If the individual task durations are nominated as outputs, along with the critical index functions, the analyst can look at the raw generated data and analyze in which situations each task is on the critical path. A conditional median analysis can be carried out, comparing the data subsets for the duration of each task from the iterations when the task is on the critical path against the entire data set of generated durations for that task. The higher the value of conditional median analysis index a associated with a task the greater the influence that task is having on extending the project's duration.
Read on: Duration of a project consisting of several inter-related tasks of uncertain duration