Delay Analysis Methods Explained for Project Teams

Delay analysis is often presented as a specialist technical exercise carried out by planners and experts after the project is already in dispute. That is too late. Project teams should understand the main delay analysis methods during delivery, because the choice of method affects programme updates, record keeping, notices, mitigation decisions and claim strategy.

No delay analysis method is universally correct. The appropriate method depends on the contract, purpose of the assessment, timing of the analysis, quality of programmes, availability of progress updates, reliability of records, complexity of the project and nature of the delay events. The Society of Construction Law Delay and Disruption Protocol emphasises transparency of information and methodology in dealing with delay and disruption matters. In practice, the credibility of a delay analysis depends as much on the honesty and quality of the underlying records as on the label attached to the method.

The first distinction is timing. A prospective analysis assesses likely future delay based on information available at the time. This is common when a delay event arises during the project and the parties need to decide whether an extension of time should be granted. A retrospective analysis looks back after actual progress is known. This may be necessary when the project is complete or when earlier assessments were not carried out properly.

Prospective analysis is useful for administration. Retrospective analysis is often necessary for dispute resolution. Problems arise when parties confuse the two. A prospective assessment may later prove inaccurate because the project was mitigated, resequenced or delayed by other events. That does not necessarily mean the original assessment was unreasonable. Conversely, a retrospective analysis must not pretend that later knowledge was available at the time.

Impacted as-planned analysis inserts delay events into the original planned programme to calculate theoretical impact. It can be simple to understand and may be useful where the project has not started, where the baseline is robust, or where the contract specifically supports such an approach. However, it is often criticised because it may ignore actual progress, actual sequencing, mitigation, contractor delay and changed project logic.

This method is vulnerable on live or completed projects if the baseline quickly became unrealistic. A claim based only on impacted as-planned analysis can look artificial where the real project evolved differently.

Time impact analysis usually inserts a delay event into an updated programme at the point immediately before the event, then assesses its effect on completion. This can be a strong method for prospective EOT assessment, particularly where regular, reliable updates exist. It aligns with the idea that delay should be assessed against the project status at the time the event occurred.

The weakness is data quality. If updates are unreliable, logic is manipulated, progress is not properly recorded, or the update immediately before the event is missing, the analysis becomes contested. Time impact analysis also requires transparency: the analyst should show the update used, the fragnet inserted, the assumptions made and the resulting critical path effect.

As-planned versus as-built analysis compares the planned sequence with the actual sequence. It can be helpful where detailed updates are unavailable but actual records are strong. It may show broad delay patterns, changed sequencing and actual completion impact.

Its limitation is causation. The fact that an activity finished later than planned does not by itself prove why it finished late. The method must be supported by records explaining the reasons for variance. Otherwise, it becomes a comparison of dates rather than a delay analysis.

Windows analysis divides the project into periods, often aligned with monthly updates, and assesses critical path movement within each window. It can be powerful because it recognises that the critical path changes over time. It can also identify when delay was caused by different events in different periods.

This method is often suitable for complex projects with regular updates. It requires more work, more judgement and more data discipline than simpler methods. It is also vulnerable if updates were not prepared honestly or consistently during the project.

Collapsed as-built analysis removes delay events from the as-built programme to assess what completion would have been without those events. It is commonly used retrospectively and can be useful where the actual sequence is clear. It is also highly sensitive to logic assumptions. If the as-built programme is artificially constructed, the conclusions may be challenged.

The method should follow the project facts, not the desired result. A strong delay analysis explains why the selected method is appropriate. It also explains limitations. If programme data is imperfect, the analyst should say so and support the conclusion with other records.

Key selection questions include:

• Is the analysis prospective or retrospective?
• Are reliable baseline and update programmes available?
• Did the critical path change significantly?
• Are actual progress records complete?
• Is the claim event-specific or cumulative?
• Is the project complete?
• Does the contract specify or imply a method?
• Will the method be understandable to decision-makers?

Delay analysis begins long before the expert is appointed. Project teams should maintain approved baselines, regular updates, narrative reports, logic explanations, progress photographs, daily reports, resource records, change logs, access records and mitigation records. A project that cannot explain its schedule during delivery will struggle to explain it convincingly in a claim.