The SCL’s Delay and Disruption Protocol" , Episode 5
Contemporaneous analysis of delay
If the good practice as recommended by SCL for the program
and records has been followed during the construction process, the well
prepared documents can then be used to perform an efficient “Delay Analysis”.
At every Employer Risk Event occurring during construction,
the contractor should submit to the CA a sub-network (also known as “ Fragnet”)
showing the impact of that Employer Risk Event occurred or expected to occur by
inserting it into the latest Updated program linking to the nearest activity before
the incident for its consideration.
The CA should consider and give its opinion to reach agreement for every events, (e.g., a design change, an instruction for suspension of work, etc) for whether the employer is responsible for the delay or not, the events actually impact on the Critical path or not, or there is a need to modify the logic link in the Updated program to be more sensible before inserting the sub-network or not. These should be negotiated and agreed with reasons supporting by detailed evidences. If a 3rd party is required to an opinion for the impact, it should be done and close soonest for every case. Do not let conflicts on many cases continue with “wait and see” approach to the end of the project. But it should be concluded and agreed that the event will affect the contract completion date and require time extension or not, then adjusts the programme with EOT granted as an agreed revised programme. The revised programme will be further used to monitor the progress of the work by the parties. (By said practices, it will decrease the disputes from retrospective claims and thus decrease later lawsuit cases.)
The contractor should also include the Fragnet of its Contractor Risk Event, (if any). However, the SCL provides a principle that in case of concurrent delay, i.e. there is delay from both parties, regardless of whether both parties’ delay may occur simultaneously or not occur simultaneously but causes an effect in the same period, the extension of time (EOT) entitled from longer Employer’s delay event will not be deducted by shorter Contractor‘s delay event, (it is understood that, on the contrary, if the Contractor’s delay event is longer than the Employer’s, then the contractor is not entitled to any EOT).
Delay Analysis
An analyzing of the Fragnet's impact is called a "Delay Analysis," a process that would not have been done efficiently without a logic linked baseline program. The baseline programme also has to be approved by the parties to be used as an Accepted program and Updated programmes that the contractor records progress and actual data (e.g., actual start date, remaining duration, actual finish date etc.) into them on each report cutoff date. On the absence of these documents, there are no evidences for using to find a reasonable mutual agreement. Disagreement that happens again and again by claims with real suffer but without sufficient substantiation, is a project risk that will lead to a large project dispute.
The CA should consider and give its opinion to reach agreement for every events, (e.g., a design change, an instruction for suspension of work, etc) for whether the employer is responsible for the delay or not, the events actually impact on the Critical path or not, or there is a need to modify the logic link in the Updated program to be more sensible before inserting the sub-network or not. These should be negotiated and agreed with reasons supporting by detailed evidences. If a 3rd party is required to an opinion for the impact, it should be done and close soonest for every case. Do not let conflicts on many cases continue with “wait and see” approach to the end of the project. But it should be concluded and agreed that the event will affect the contract completion date and require time extension or not, then adjusts the programme with EOT granted as an agreed revised programme. The revised programme will be further used to monitor the progress of the work by the parties. (By said practices, it will decrease the disputes from retrospective claims and thus decrease later lawsuit cases.)
The contractor should also include the Fragnet of its Contractor Risk Event, (if any). However, the SCL provides a principle that in case of concurrent delay, i.e. there is delay from both parties, regardless of whether both parties’ delay may occur simultaneously or not occur simultaneously but causes an effect in the same period, the extension of time (EOT) entitled from longer Employer’s delay event will not be deducted by shorter Contractor‘s delay event, (it is understood that, on the contrary, if the Contractor’s delay event is longer than the Employer’s, then the contractor is not entitled to any EOT).
Delay Analysis
An analyzing of the Fragnet's impact is called a "Delay Analysis," a process that would not have been done efficiently without a logic linked baseline program. The baseline programme also has to be approved by the parties to be used as an Accepted program and Updated programmes that the contractor records progress and actual data (e.g., actual start date, remaining duration, actual finish date etc.) into them on each report cutoff date. On the absence of these documents, there are no evidences for using to find a reasonable mutual agreement. Disagreement that happens again and again by claims with real suffer but without sufficient substantiation, is a project risk that will lead to a large project dispute.
In international construction contracts, an EOT Clause is
usually provided. The EOT clause identifies the causes and/or events that give
right to get time extension and determines the roles and responsibilities of
the parties on the time extension process that all parties must adhere to. The
clause also includes the right of a party to consider the EOT or not, when the
other party fails to comply with what prescribed in this clause.
Different methods of delay analysis
SCL introduces 6 methods of delay analysis. To choose which method for the analysis depends on the availability of programme and project records that are sufficient to support the method’s requirement. All methods can be summarized as follows:-
1. Impacted As-Planned Analysis
This method requires sub-networks to be inserted into the logic linked baseline programme and calculates the CPM to see the impact on the new construction completion date known as “the Prospective impact”. The baseline program should be considered as its duration and sequences of activities linked are realistic and reasonable which can be approved as an Accepted Program. This method has a restriction that it does not consider actual progress or any changes from the baseline that are really happened. The Impacted As-Planned method is, therefore, suitable for a delay analysis when the delay events took place at the early phase of the construction.
2.Time Impact Analysis
This method requires sub-networks to be inserted into the Updated programme and calculates the CPM to see the impact on the new construction completion date known as “the Prospective impact”. This method considers actual progress and any changes from the baseline when the delay events are really happened. The Time Impact method is, therefore, suitable for delay analysis carried out by the time the delay event occur during construction, i.e. a contemporaneous analysis of delay. This method supports on closing the EOT deal for every delay events without “wait and see” approach during the ongoing project which is a good practice that SCL recommends.
3.Time Slice Analysis
This method requires Updated Programmes that reflect the progress status of the project at various Time Slices, which are usually updated at the end of each month to show critical delays in critical paths. The critical delays may increase at the end of each month and show the effects from their causes that can be summarized in each window.
4. As Planned vs. As built windows
This method divides the project period in spanning Updated Programmes into several windows over a period of time coverage between key dates or Milestones, then finds out causes of critical delays in each window by comparing key dates or milestones in each Updated programme versions that slipped from the Accepted (baseline) program.
5.Retrospective Longest Path Analysis
This method looks at the as-Built critical path retrospectively by tracing backwards from the construction completion date in the detailed as-built program through the longest path to find out the causes of critical delays in each window by comparing key dates or milestones in each Updated programme versions that slipped from the Accepted (baseline) program.
6.Collapsed As-Built (or but-for) Analysis
This method extracts the delay events incorporated in the detailed logic as-built program for a hypothesis that if there were no delay events inserted, what would happen to the actual program. Therefore, with this method, no baseline program is needed. Very few contractors keeps maintain Updated programmes versions up-to-date with actual data until the end of the project to get a final as-built program. If this is the case and this method has to be used to analyze, the analyst itself will need to prepare a detailed logic as-built program from information available which usually takes a lot of time. The analyst then pulls out delay events sub-networks in order to get the earlier completion date collapsed backwards. This will make it possible to calculate the net impact caused by those delay events.
In addition to the above, there are also other methods that SCL has mentioned, but just the method names without explanation in detail. This includes project wide as-planned vs. as built projects (which is not by windows), time chainage analysis (suitable for linear construction), line of balance analysis, resource curve analysis, and value-added analysis.
Different methods of delay analysis
SCL introduces 6 methods of delay analysis. To choose which method for the analysis depends on the availability of programme and project records that are sufficient to support the method’s requirement. All methods can be summarized as follows:-
1. Impacted As-Planned Analysis
This method requires sub-networks to be inserted into the logic linked baseline programme and calculates the CPM to see the impact on the new construction completion date known as “the Prospective impact”. The baseline program should be considered as its duration and sequences of activities linked are realistic and reasonable which can be approved as an Accepted Program. This method has a restriction that it does not consider actual progress or any changes from the baseline that are really happened. The Impacted As-Planned method is, therefore, suitable for a delay analysis when the delay events took place at the early phase of the construction.
2.Time Impact Analysis
This method requires sub-networks to be inserted into the Updated programme and calculates the CPM to see the impact on the new construction completion date known as “the Prospective impact”. This method considers actual progress and any changes from the baseline when the delay events are really happened. The Time Impact method is, therefore, suitable for delay analysis carried out by the time the delay event occur during construction, i.e. a contemporaneous analysis of delay. This method supports on closing the EOT deal for every delay events without “wait and see” approach during the ongoing project which is a good practice that SCL recommends.
3.Time Slice Analysis
This method requires Updated Programmes that reflect the progress status of the project at various Time Slices, which are usually updated at the end of each month to show critical delays in critical paths. The critical delays may increase at the end of each month and show the effects from their causes that can be summarized in each window.
4. As Planned vs. As built windows
This method divides the project period in spanning Updated Programmes into several windows over a period of time coverage between key dates or Milestones, then finds out causes of critical delays in each window by comparing key dates or milestones in each Updated programme versions that slipped from the Accepted (baseline) program.
5.Retrospective Longest Path Analysis
This method looks at the as-Built critical path retrospectively by tracing backwards from the construction completion date in the detailed as-built program through the longest path to find out the causes of critical delays in each window by comparing key dates or milestones in each Updated programme versions that slipped from the Accepted (baseline) program.
6.Collapsed As-Built (or but-for) Analysis
This method extracts the delay events incorporated in the detailed logic as-built program for a hypothesis that if there were no delay events inserted, what would happen to the actual program. Therefore, with this method, no baseline program is needed. Very few contractors keeps maintain Updated programmes versions up-to-date with actual data until the end of the project to get a final as-built program. If this is the case and this method has to be used to analyze, the analyst itself will need to prepare a detailed logic as-built program from information available which usually takes a lot of time. The analyst then pulls out delay events sub-networks in order to get the earlier completion date collapsed backwards. This will make it possible to calculate the net impact caused by those delay events.
In addition to the above, there are also other methods that SCL has mentioned, but just the method names without explanation in detail. This includes project wide as-planned vs. as built projects (which is not by windows), time chainage analysis (suitable for linear construction), line of balance analysis, resource curve analysis, and value-added analysis.
In the next episode, we will discuss another interesting of SCL's D&D Protocol Guidance Part B - Guidance on Core Principles, namely “Disruption Analysis”, which may not be familiar by the construction industry in the country like Thailand. If interested. Please follow…..
References and Credits:
