Retrospective delay analysis

There are 5 main delay analysis techniques:

• as-planned v as-built;
• as-planned impacted;
• collapsed as-built;
• windows analysis;
• time impact analysis.

The as-planned v as-built is a simple comparison between the planned programme and the as-built programme. It is therefore a simple graphical comparison between what was planned to happen and what in the event actually did happen.

The as-planned impacted method operates by adding or 'impacting' the claimed delaying events onto the planned programme. By adjusting the programme to take account of the effect of these events a revised programme is produced indicating their impact.

The collapsed as-built involves removing the claimed delaying events from the as-built programme causing it to become shorter or to 'collapse'. The aim is to produce a programme that reflects what would have happened 'but for' the effects of the delaying events.

Windows analysis breaks the works into discrete periods of time or 'windows'. By utilising contemporaneous progress information the status of the progress achieved in each window can be determined and explanations sought.

Time impact analysis is similar to the windows analysis but rather than looking at delays within defined windows of time, the actual timing and duration of the delaying event forms the period for analysis.

Which technique should be used will be dependent on many factors including whether the delays are being considered during the course of the works 'prospectively' or retrospectively; the terms of the contract; the information available; the nature of the work; and the amount in dispute.

All of these techniques attract a certain amount of criticism and it is likely that they will produce differing results. With the exception of the as-planned v as-built, the above methods rely on the technique known as critical path analysis which brings with it problems associated with the need for certainty and possible theoretical and deterministic results. The use of critical path based software often results in the delay analyst concentrating more on the manipulation of the software and generation of voluminous programme charts than a review of the factual evidence.

Whichever method is used to analyse delay it must be robust and produce a result that accords with common sense and the factual evidence.