Challenge:

Due to the unpredictable nature of construction, it is difficult for a construction schedule to take into account factors such as weather conditions, supply chain disruptions, labor shortages, unforeseen site conditions, and even natural variability in productivity. These uncertainties require the need to include contingency within the schedule to account for potential delays and ensure the project remains on track.

Solution:

Construction teams commonly model risk and uncertainty directly into the schedule, acknowledging that almost no activity will adhere precisely to its prescribed duration. ALICE offers several ways to model risk, either to meet contractual requirements around risk management or proactively simulate variability to assess the robustness of a schedule. In this article, you will learn how to:

• Use Time Risk Allowance (TRA), or Contingency, to manage risk
• Model TRA at the task-level, as an allowance before a milestone, or as a LOE task
• Model TRA as a percentage or a fixed amount
• Build TRA formulas depending on your goals

In the UK under NEC contracts, it is often a contractual requirement to explicitly show TRA in the schedule.

Note: The terms Time Risk Allowance (TRA) and Contingency will be used interchangeably throughout.

How ALICE is Different from Other Tools:

TRA is often added to a schedule to create contingency before key milestones. Adding contingency before key milestones can help increase the likelihood of a quantitative schedule risk analysis (QSRA).

Without diving fully into the shortcomings of QSRA, it is worth noting that in a QSRA, the logic is all treated as hard logic. This means the schedule is static while a hypothetical risk event occurs, effectively pushing the schedule and all its logic to the right (delay). In reality, projects that face risk will adapt their plan as they go in order to recover and manage risk, e.g. adding resources, changing sequencing, working overtime, etc. Simulating different ways to react to risks events can be quickly and efficiently modeled in ALICE through the Explore page (what if scenario functionality). The significant advantage of modeling risk in ALICE is that you are able to respond to risks by resequencing, as opposed to the fixed logic in a traditional QSRA. This can often result in a ‘free’ recovery from a risk by resequencing alone, as opposed to adding more resources, overtimes, etc.

How to Model TRA in ALICE:

Time risk allowance (TRA) is used to explicitly delineate contingency in a schedule. Often it is represented in tasks called “time risk allowance,” “TRA,” or it is a user defined field that delineates the amount of TRA assigned to each activity. 

Examples:

• Excavation: 
  • Total duration: 12 days
  • Breakout: 10 days for the activity, 2 days for TRA (defined in user defined field)
  • How it looks in ALICE: Planned Duration Formula for Excavation = 10 + TRA, where TRA is a UDF = 2.
• Alternatively you may see two separate activities with a finish-to-start relationship:
  • Activity #1: Excavation: 10 days
  • Activity #2: TRA: 2 days
  • How it looks in ALICE: Excavation (10 days) → FS → TRA (2 days)
• Another option is to have all the TRA summed together in large chunks before key milestones or solely before the final completion milestone.
  • How it looks in ALICE: TRA (200 days) → FS → Final Completion Milestone

Step 1:

First, decide on your objective:

1. How much TRA do you want to have - is it a fixed amount or a percentage of a duration?
2. Where in the schedule do you want to have it - embedded at task level or one large allowance?

If TRA = percentage of a duration AND is embedded at the task level, go to Step 2.

If TRA = fixed amount AND embedded at the task level, go to Step 3.

If TRA = flexible amount AND embedded as a large allowance, go to Step 4.

Step 2: TRA as a percentage of a task’s duration, applied at task level 

1. Create a production rate:
   • TRA_Percentage: this is the percentage of TRA you would like for tasks. You can make multiple rates for different types of tasks
2. Create UDFs: 
   • TRA_Duration: this is the duration of TRA for each task calculated as a percentage of the the task duration (e.g. 10% TRA on a 20 day task = 2 days)
   • We can make this input a formula where

   • TRA_Duration = task duration x (TRA_Percentage/100)

3. Update the Planned Duration formula
4. Add the TRA_Duration to the Planned Duration formula to ensure the TRA duration is embedded at task level. For example:

   • Planned Duration = (duration calculation or fixed duration) + TRA_Duration

   • This can be added to all or selected activities

To take this a step further, scenarios can be run by altering the TRA. For example, changing the TRA percentage to see the impact on the end date, as well as auto calculating the total TRA for the project. 

Here are all examples of the different formulas you can use to calculate your Planned Duration:

Planned Duration = Task Duration + TRA_duration
Planned Duration = Task Duration + (Task Duration x TRA_Percentage/100)
Planned Duration = Task Duration (1 + TRA_Percentage/100)
where Task Duration = Parametric Duration Calculation or Fixed Value Duration

Step 3: Fixed amount of TRA, in an allowance, applied at task level, before a specific milestone or before a specific activity

1. Create an activity called TRA and set a fixed duration, link logic appropriately in the schedule.
2. Schedule the plan and see the impact of the TRA on the succeeding activities or milestones.
3. ‘Isolate the path’ to the TRA activity and focus on parameterizing activities preceding the TRA.
4. A more advanced alternative would be to make the milestone succeeding the TRA activity “start on or before”. In this method, the ALICE algorithm will emphasize having the milestone start on the specified start date.

Step 4: Flexible amount of TRA, in an allowance, before a specific milestone

1. Similar to Step 3, with your activity called TRA, change the task type to a “level of effort” task (LOE task). Link it between activities and the key milestone where you want to show the TRA. This LOE task will stretch between the preceding activities and the milestone and is a dynamic way to quantify TRA.

Note: If the succeeding activities or milestones are not constrained, the LOE task will collapse to zero.