Adding risk events to the project schedule

‘Risk events’ are events that may, or may not, occur and that have an impact on the project schedule. Risk events are often described as threats if they have increase the risk of failing to meet targets, and opportunities if they reduce that risk.

Tamara provides a rich environment for describing risks (both threats and opportunities). The type of risk event that can be included in Tamara broadly fall into five categories:

1. A risk event resulting in one or more delays to a specific task (for example, material delivery is delayed, equipment must be repaired, or waiting for contractor to arrive)

2. Multiple but identical risk events independently producing the same potential delays to specific tasks (usually a risk that may apply to a set of identical tasks within a project, for example improper connection of the generator on a wind turbine, where there are many wind turbines being constructed in the project)

3. Risk events producing a change in productivity (which may affect many tasks. For example, having to switch to a less competent contractor could reduce productivity levels in several parts of a project)

4. Risk of extra work – sometimes called probabilistic branching (for example, rework of a design, reapplying for a permit)

5. Disruption risk events (risks that will cause a temporary halt to the whole project or some part of it. It causes the same delay to all applicable tasks that are active at the moment the risk event strikes. For example, an earthquake, fire, H&S inspection, or chemical spill that leads to the temporary shutdown of the whole or part of a construction site). Select one of the links to learn how each of these types of risk can be added to your schedule in Tamara.  

Modeling a risk event resulting in one or more delays to a specific task

Risk events attached to specific tasks are entered, removed and edited in the Task-specific Risk window, which is accessed by clicking the Task-Specific Risk button in the Project Overview tab:

This opens the following interface:

The table has the following fields:

• ID – an identification number provided automatically by Tamara. ID numbers apply to individual projects. If a risk is deleted, its ID number is not reused to avoid confusion with older models

• Risk description – a brief description to help identify the risk

• Expected frequency – either the probability (between 0 and 1) that the event will occur, if the risk could only occur once, or the expected frequency (greater than 0) if it could occur several times within the project

• Independent – check this box if the risk can occur in multiple places within the project schedule, but each occurrence is independent of any others – see explanation here

• Single Event – check this box if the risk can only occur once

• Delay duration – this is the number of working days of delay that will be experienced in the execution of this task if the risk event occurs. Tamara will automatically include the additional costs associated with any resources dedicated to the task:

  • Delay (min) – the minimum number of days that will be added to the task

  • Delay (most likely) – the most likely number of days that will be added to the task

  • Delay (high P90) – a high estimate of the possible number of days that will be added to the task. There is only a 10% chance that the delay would be longer (i.e. a 90% chance it will be less) should the risk occur

• Additional cost amounts – this is any extra cost that would be incurred if the risk event occurs, excluding the increased use of resources allocated to the task which are already accounted for. It is assumed that these extra costs are unrelated to the length of the delay (i.e. independent):

  • Cost (min) – the minimum additional cost if the risk occurs

  • Cost (most likely) – the most likely additional cost if the risk occurs

  • Cost (high P90) – a high estimate of the possible additional cost if the risk occurs. There is only a 10% chance that the cost would be greater (i.e. a 90% chance it will be less) if the risk occurs

• Include – check this box if the risk should be included in the schedule risk analysis. This is useful if one wants to simulate different scenarios in which some risks are included or exclude, or if the risk is provisional (i.e. we aren’t sure if there is a real issue yet)

Risks can also be imported from Pelican.

Simple example

Open the example model called Build a house that comes with Tamara. The base schedule looks as follows:

Two risks are to be added to this schedule:

Risk A: The selected builder rejects the initial offer, requiring a renegotiation of the contract. A 10% chance of this occurring, producing (min, most likely, max) = (5,10,20) days delay

Risk B: There are repeated mistakes made by the builder. On average, 3 mistakes are expected, and each one will independently result in (1,5,30) days delay.

These risks are added to the risk register, accessed by selecting the Risk Register icon from Tamara’s Task Overview menu:

Risk A, builder rejects offer, is a single event (i.e. it will only occur once, if at all). The 10% probability is entered in the Expected frequency field, and the minimum, most likely and maximum delays of (5,10,20) entered in their respective fields. The risk is live (i.e. still exists) so the Include? box is checked.

Risk B, mistakes by builder, is not a single event (i.e. several events can occur). The average number of expected events (3) is entered in the Expected Frequency field, and the minimum, most likely and maximum delays of (1,5,30) for a single mistake are entered in their respective fields. The risk is live (i.e. still exists) so the Include? box is checked.

These risks are now connected to the schedule by selecting them in the Risk Register column of the Main View window:

Looking at the simulation results, we see the duration of Select builder, which was originally 10 days but now has Risk A applied to it, has the following distribution:

There is a 90% chance it is still 10 days (Risk A doesn’t occur), but a 10% chance it lies somewhere between 15 and 28 days (equating to a delay of between 5 and 20 days).

The duration of Build house, which was originally 250 days but now has Risk B applied to it, has the following distribution:

It was estimated that the builder would make 3 mistakes on average, each producing a delay of (1,5,30) days. Internally, the actual number of mistakes was simulated by Tamara using a Poisson(3) distribution:

The Poisson distribution shows that there is about a 5% chance that no mistakes will be made, which is why the results show about a 5% chance of the task taking the original 250 days. Internally, Tamara used the following distribution to model the delay from a single mistake:

The mean of this distribution is 9.2 days, so on average (statistically) we would expect to have 3 * 9.2 = 27.6 days of delay, taking the total duration to 277.6 days, which you can see is about the center of gravity of the simulation results histogram.

Modeling multiple but identical risk events independently producing the same potential delays to specific tasks

Many projects involve repeating the same set of tasks multiple times. For example, the set of tasks could be:

• To build an overpass bridge (there may be several such bridges for a motorway or railway line construction project);

• To erect a wind turbine (there may be many wind turbines built for a wind farm construction project);

• To inspect pylons of a certain type (there will be many pylons to inspect for a complete transmission line refit project); or

• To install a pre-built bathroom (there may be two or more bathrooms for each floor of an office tower block construction project)

It is often the case that there are risks associated with such sets of tasks that similarly are repeatable. For example, each time a wind turbine is installed there might be a risk of the generator being faulty, or a crane failing, or connectors being fitted incorrectly, or bearings being misaligned. If one was building a farm of many turbines, such a risk event could happen to each turbine, or some, or none.

Tamara allows you to enter such a risk event a single time, rather than create a separate identical risk event for each place in the project it could occur. This reduces the work required to set up a schedule risk model and makes it very easy to adjust the probability or impact sizes since they are located in one single place.

In order to use this feature, one enters the risk event into the Task-Specific Risk table, and additionally checking the Independent box.

Risks can also be imported from Pelican.

Example

You can follow this example by loading the file ‘Three Towers’ from the examples folder. In the following project, three electric cable towers (pylons) are to be built and connected together:

For each task, the same specialist team is used so, for example, land excavation on Tower 2 starts after the excavation on Tower 1 finishes, etc.

This project represents a set of tasks repeated for each tower and therefore the construction of each tower shares duplicates of the same potential risks as the others.

We will add a risk that, when stability for a tower is tested, it fails with 60% probability and would then produce a delay of (40,45,55) days:

Now we link the risk to each Test stability task:

This means that there are three independent chances for this risk to occur, each with 60% probability. There is therefore only 40% * 40% * 40% = 6.4% chance that the risk does not occur at all. Without the risks included, the project duration was 53 days. The simulation result shows this not has only a 6.4% chance of occurring as expected:

You can also see three slightly overlapping distributions, representing whether the risk event occurs 1, 2, or 3 times.

Modeling the risk of a change in productivity

 

In the Productivity Risk Factor dialog, one can enter a risk event that affects productivity. For example:

You plan to use a particular experienced sub-contractor for completing some tasks in the project. However, it is estimated that there is a 30% probability that this sub-contractor is unavailable, in which case you will have to revert to a second sub-contractor who will take between 10% and 50% longer to complete the tasks, most likely 20%.

The risk is entered as follows:

You can add this productivity risk factor to a Work Type Category. Then, for each task to which that Work Type Category has been assigned, Tamara will simulate the risk event so that it occurs 30% of generated scenarios, and when it does occur adds between 10% and 50%, most likely 20% to the estimated duration of the tasks.

Modelling the risk of additional work

Tamara also includes the capability of adding new tasks to a schedule as a result of a risk event occurring, a technique often called probabilistic branching. This is illustrated with an example model called ‘Three towers with extra work’ that comes with Tamara.

In this example, there is a 20% probability that it will be necessary to obtain a permit from the local authority before beginning construction, which would take between 20 and 40, most likely 25 days.

We must first include the possible extra task(s) in the base schedule model, including all the antecedents and precedent logical links. It is best practice to set the duration to zero. For example, in MS Project, Task 2 Obtain permit has been added to the schedule:

MS Project interprets this as a milestone by default because of the zero duration, so we must . Note that Task 4 (Tower 1 Excavate land) has Obtain permit as its predecessor, so if Tamara changes the duration of Task 2 it will affect the rest of the schedule. After importing this model to Tamara, you need to define an Unplanned Work event by clicking the Unplanned Work button in the Task Overview tab:

This opens the following window, where you click Add, enter a description and a probability of occurrence, and then Save:

You can add more, and delete, unplanned work risk events by clicking the appropriate buttons. The table has the following fields:

• ID – an identification number provided automatically by Tamara. If a risk existence is deleted, its ID number is not reused

• Risk description – a brief description to help identify the risk

• Probability – the probability (between 0 and 1) that the risk event will occur

• Include? – check this box if the risk event should be included in the schedule risk analysis. This is useful if one wants to simulate different scenarios in which some risks are included or exclude, or if the risk is provisional (i.e. we aren’t sure if there is a real issue yet)

Then we connect the Unplanned Work event to the schedule, by selecting the event from those listed in the Unplanned Work field for the Obtain permit task:

Finally, we need to specify what the duration will be when this event occurs, by selecting the corresponding cell in the Work Amount Uncertainty column, choose Custom, and enter the duration the task will take in days (a percentage variation from Base will not work since this is zero). Negative values are not allowed since they would break the logic of the base schedule:

 

During a simulation, Tamara will randomly generate scenarios in which the unplanned work event occurs (with the probability defined) or does not occur. In a random sample where the unplanned work event occurs, all tasks connected to that particular unplanned work event will be simulated to occur together. In a random sample where the unplanned work event does not occur, the schedule dependency logic is maintained but the connected tasks are given a duration of zero. You can attach multiple unplanned work events to a single task, in which case the task will take a non-zero value if at least one of the risk existence events is simulated to occur.

In the worked example, the distribution of the duration for the Obtain permit task looks as follows:

There is an 80% probability it is zero (i.e. the risk event did not occur), and the remaining 20% is spread between 20 and 40 days. This results in a project completion date as follows:

 

The example model ‘Commercial Construction’ illustrates another application of the risk existence method.

Modeling disruption risk events

Disruption risk events temporarily stop all activity across the whole project, or across a section of the project. Disruption risks are connected to moments in time, not to individual tasks. In other words, whether these disruption risk events occur or not does not depend on which tasks are currently active in the project. Examples are:

• Partial site shutdown due to earthquake, strike, or security breach;

• Entire project postponement due to legal dispute or funding issue;

• All contractor work halted due to discovery of illegal workers; or

• Construction work halted pending H&S investigation of an accident

Tamara allows you to incorporate the occurrence of such risks using the Disruption table, which has the following fields: 

• ID – an identification number provided automatically by Tamara. ID numbers apply to individual projects. If a risk is deleted, its ID number is not reused to avoid confusion with older models

• Risk description – a brief description to help identify the risk

• Frequency –either the expected frequency of the number of risk events that may occur during the defined period if the risk event is repeatable (Single Event parameter is not ticked). For example, a strike or an earthquake may occur more than once, but a building collapse cannot; or the probability of an unrepeatable risk event occurring (Single Event parameter is ticked), e.g. a building collapse.

• Single Event – ticking this box means that the risk can occur only once

• Overlap – ticking this box means that if the risk event is repeatable, a second event can occur while one is still suffering from the delay caused by the first event

• Delay (min) – the minimum number of days that the project or sub-project will be suspended

• Delay (most likely) – the most likely number of days that the project or sub-project will be suspended

• Delay (high P90) – a high estimate of the possible number of days that the project or sub-project will be suspended. There is only a 10% chance that the delay would be longer (i.e. a 90% chance it will be less) should the risk occur

• Start – the starting date of the defined period

• Finish – the finish date of the defined period

• Calendar – the calendar against which the delays will be added. Any tasks that share this calendar and are active at the moment a suspension risk event occurs will be delayed by the same amount of time

• Include? – check this box if the suspension risk should be included in the schedule risk analysis. This is useful if one wants to simulate different scenarios in which some risks are included or exclude, or if the risk is provisional (i.e. one isn’t sure if this is a real issue yet)

Risks can also be imported from Pelican.

The example model Construction project example includes some disruption risks:

The first three suspension risks are storms that could occur between May and July each year of the project. They don’t overlap as one storm must finish before another starts, and there are expected to be on average 4 storms within the May to July window each year.

The Earthquake suspension risk is expected to occur twice over nearly 2.5 years, with delays of 0-10 days. The delays can overlap – meaning that whilst one is recovering from the effects of a first earthquake, a second could occur.

Finally, the contractor quitting suspension risk has a 5% chance of occurring, can only happen once (single event) – which also means that whether the overlap parameter is checked or not is irrelevant – and will cause a delay to the whole project of 30-80 days if it occurs.