Four Delay Analysis Methodologies You Need to Know
A lot has already been written about various delay analysis methodologies. The purpose of this article is to summarise the pros and cons of the most commonly accepted methodologies and highlight where they might best be used.
Regardless of the delay analysis methodology selected and whether it is mentioned in the SCL, the analysis should be based on common sense and substantiating evidence. As exemplified in the ruling of Justice Hammerschlag in White Constructions Pty Ltd v PBS Holdings Pty Ltd [2019] NSWSC 1166.
Delay analysis is the assessment of a causal event (the alleged delay) over time. The impact of the delay is measured against a program. The program(s) relied upon in the analysis depends on the delay analysis methodology selected.
Notwithstanding the delay analysis methodology selected, the delay(s) to be analysed must satisfy the three-part chain of causation, whereby:
A delay event / causal event has occurred;
Progress is delayed;
Completion is (or is likely to be) delayed.
As-planned Impacted
Almost as simple as as-planned v as-built. A prospective methodology that relies on impacting the originally planned sequence of works (‘the baseline’ plan) with the delay event(s). Ideally this program was approved commensurate with the commencement of the works.
Pros
Quick to produce;
Depending on the complexity of the program, easy to understand;
Demonstrates the criticality (the critical path) of the delay event(s) on the original, planned sequence;
Demonstrates causation;
Does not rely on as-built information, in case as-built information is not available;
Useful as a ‘litmus’ test, prior to a further, more detailed analysis.
Cons
The as-planned program rarely reflects what actually happened;
The analysis is hypothetical and prospective, therefore delay cannot be used to determine cost;
The baseline might contain errors;
Does not consider progress or concurrency;
Almost no judicial support. Refer: Great Eastern Hotel v Laing Construction Ltd [2005] EWHC 181.
Requires
An as-planned program with accurate logic links between activities and a critical path that reacts to change;
The baseline program should still be relevant at the time of the delay event i.e., nothing has significantly changed (other than the delaying events);
The quantification of the duration of the delay to be ‘spliced’ between the respective impacted program activities.
As-planned v As-built
A simplistic, retrospective methodology, which in its simplest form compares the as-built program to the planned (baseline) program. Usually used to substantiate ‘global’ claims, whereby the various heads of claim are not independently assessed, rather they are bundled into a single claim.
Pros
Quick to produce in its simplest form i.e., comparing the as-planned program to a single as-built;
Requires minimal program updates i.e., frequently updated programs are not available;
Easy to understand if the project is simple and there are very few delays;
The analysis can be broken down into ‘windows’ or time slices for clarity, such as the time-slice windows analysis methodology.
Cons
The baseline and as-built programs must be very similar;
Fails to consider concurrency in its simplest form;
The ‘as-built’ program is rarely dynamic with a historical critical path i.e., only start and finish dates are recorded;
Causation is generally inferred, not proven;
Some judicial support, especially in the form of a time-slice windows analysis (as-built program with critical path). Refer: V601 Developments Pty Ltd v Probuild Construction Pty Ltd [2021] VSC 846.
Requires
An accepted, simple as-planned program;
An as-built program that is very similar, in terms of key sequence, to the as-planned program. Does not need to be a program with a critical path, although much more convincing if it is;
A very convincing narrative or a variation of the methodology that uses time-slices and a critical path that has been determined contemporaneously.
Time Impact
A prospective analysis demonstrates the causality of the delaying event, at the time of the delaying event, using a current project program.
Pros
It demonstrates causation at the time of the delay;
Ideally used to demonstrate causation during the project;
Can be used to demonstrate delays (convincingly) after the completion of the project by retrospectively impacting the baseline program contemporaneous program updates;
Relies on established facts;
Best method of analysis during the project;
The chain of causation is satisfied;
Allows for changes to logic, durations and the critical path;
Progress and concurrency are considered.
Cons
Costly and slow to produce, especially if impacting the baseline retrospectively (post project completion);
Requires good supporting, contemporaneous records;
Being a prospective form of analysis, it might not demonstrate the precise, actual delay to completion;
Some concerns of its suitability in demonstrating delay after the fact when it is a prospective form of analysis.
Requires
Good as-built records;
Regularly updated programs accompanied by supporting change management documents;
Dynamic programs that are responsive to change i.e., a “real” as-built, not simply indicative start and finish dates of completed activities.
As-built but for
Also referred to as a “collapsed as-built”. The most difficult to prepare. The activities associated with the delay events (Fragnet) are removed from the updated as-built program. The impact of the respective delay event is established by determining the difference between the impact on critical key dates before and after the respective fragnet is removed.
Pros
Analyses the effect of delay(s) on actual completion;
Relies on verifiable as-built data;
Judicial acceptance;
Each delay is clearly identified in a descending chronological order;
Excellent for proving prolongation costs, as the period of each delay is known, and each will have their own specific associated costs;
Typically, only actual costs/damages can be claimed and this method links events to their actual contribution to prolongation.
Cons
Requires concise and documented as-built logic;
May require several iterations to demonstrate the employer and contractor delay events;
Looking ‘backwards’ at what happened can be confusing;
Difficult to produce, especially if a ‘running’ as-built program has not been maintained i.e., very difficult to define logic, when it is apparent that either the logic does not exist or records are not available to substantiate the changes to the logic in the as-built program.
Requires
A dynamic as-built CPM program that has been contemporaneously updated and the changes, including logic, documented;
Requires as-built logic that can be very difficult to prove after the fact.
Window Analysis
A window analysis is sometimes (erroneously) used to describe a time-impact analysis. Rather it means applying any method of delay analysis to several windows or time-slices between two dates rather than the whole of the works.
It can also mean a variation of the as-planned v as-built (time-slice window analysis), which uses an as-built critical path over several windows of time.
Back to News and Insights
Related News and
Insights from Accura
