Simple method to work on Delays Time Impact Analysis

What is Time Impact Analysis?

Time Impact Analysis is a method of calculating the delay to a project based on the delay to project completion. It is normally associated with being a best practice method for assessing a single delay on the critical path of a project schedule that is in progress. The analysis looks to compare the schedule pre-delay to the schedule with the delay included. It looks to calculate the duration variance between the two schedules to provide the contractor with a basis for estimating the delay impact. Time Impact Analysis is best used to calculate delays looking forward rather than back, other methods such as As-Built But-For (ABBF) can be more accurate for calculating retrospective delay.

Process Steps In order to successfully identify the delay the following steps should be followed;

Determine the baseline schedule 

Determine As-Built data source 

Decide on the TIA date Model delay using fragnet 

Merge fragnet with schedule 

Update delay durations 

Review results 

Determine delay actuals 

Communicate

 Step 1: Determine the Baseline Schedule The first step in completing a TIA is to determine the correct baseline schedule to judge the delay against. Most construction contracts will contain clauses relating to the “agreed” or “confirmed” baseline, although this is often an implied rather than regimented factor. Whatever contract mechanics are in place the Contractor should look to determine the correct baseline to use for the analysis and to review the baseline to ensure it is reasonable for the project.

Step 2: Determine As-Built data source This would normally be the updated schedule but again contractually it is important to agree what schedule version to use. Contracts such as NEC determine the schedule as the “Accepted Programme”. The mechanics of which schedule to use will be determined usually by the contract in place. Once this has been agreed, assign the baseline from Step 1 to this project in P6.

Step 3: Decide on the TIA date This is the date you believe the delays commenced and the start date for your delay fragnet in the next few steps. This will normally be advised by the parties on site, for example; a TIA is being produced for the demolition of a building being delayed, the delay was due to the ball & crane not arriving on site, so the TIA fragnet start date would be the day the crane was planned to arrive as per the as built data source (from Step 2) Once agreed, some planners prefer to add this date as a milestone in the schedule to help the project stakeholders get a graphical representation of the TIA period.

Step 4(1): Model delay using fragnet At this stage we will look to model the delay according to the logic and duration decided by the project team. This is the basis for the claim. To do this create a copy of the schedule and enter the delay as a new activity/s and logically link to the successors on the critical path according to the build process. Do not reschedule yet – the purpose of the fragnet at this stage is to confirm the delay logic and relationship to the current programme for acceptance.

Step 4(2): Model delay using fragnet Once the fragnet has been entered and confirmed by the planner this will need communicating to the project team to allow them to comment on the logic and placement of the delay. Once all are in agreement and acceptance with the fragnet detail this will need to be kept aside ready for Step 5.

Step 5: Merge fragnet with current schedule Now the fragnet has been accepted by the project team it will need incorporating in to the current schedule. Going back to the current schedule take a new baseline to record the dates per-fragnet. This baseline is for records purposes and does not need assigning at this stage. Now using the accepted fragnet, enter the delay activities in to the current programme with the logic as agreed and link to the effected successors in the schedule. Now reduce the delay activities durations to zero days and re-schedule the project. The Project Completion date should still remain the same as the new activities have zero duration. As we assigned the baseline in Step 2 you can check this is the case by adding the baseline bars in the Gantt Chart or by adding the Variance – BL Project Finish Date column to the activity table (value should be zero)

Step 6: Update Delay Durations Now the fragnet has been entered it is time to enter the delay durations against the delay activities. To do this enter the duration against the activities in the original duration field this should then be mirrored in the remaining and at completion duration fields. Re-schedule and you will see the bars from the fragnet increase and the remaining activities push out moving the project completion date.

Step 7: Review Results Note the variance to the Project Completion milestone. This variance is important in calculating the cost impact when applying for damages, for example; delay causing another week on site is another week of paying for staff, prelims, road-closure, etc. The variance is also quantified in the Variance BL Project Finish Date column we added to the activity table earlier. It is important at this stage to ensure the impact on project completion is measured according to the contract terms. For example the contract may specify calendar days in which case the delay should also be communicated as calendar days and so on.

Step 8: Enter Delay Actuals The final step is to enter the Delay actual dates. If this is a calculation of an upcoming delay there will be no actual dates on the delay activities and the results from Step 7 should be communicated. If this is an ongoing delay the actual delay start date should come from the last schedule update. In order to enter these you will need to assess when the successor to the delay becomes critical. As you will remember from Critical Path Analysis the activity becomes critical at the late start date, so the delay start date will be the successor original late start date + 1day. Mark this date as the delay start date and reschedule. For more information on Critical Path Analysis see; http://www.slideshare.net/AdamGarnham/guide-to-the-critical-path-and-critical- path-analysis

Step 9: Communicate the TIA Now you can communicate the completed TIA to the project and commercial teams ready for a cost analysis process to take place. As well as displaying the Gantt Chart, the following columns can also be helpful in communicating the delays; BL Project Start – the original planned start date for activities BL Project Finish – the original planned finish date for activities Start – the new start date with the delay included Finish – the new finish date with the delay included Actual Start – the actual start date with the delay included Actual Finish – the actual finish date with the delay included Variance – BL Project Finish Date – the variance in Finish dates between the original planned finish and the delay included finish.