People often ask me, in all sorts of ways, which delay method they should use. I was even asked once which ones are “hot” right now. There is, alas, no stock exchange for delay analysis methods where one soars while another tanks; the right choice depends on the project facts and the data at hand. In principle, an analyst can use any method that fits the evidence or even create a new one.

That insight alone could have wrapped up this article neatly. But where’s the fun in that? No one likes a story without a few ifs and buts.

Think of hosting your in-laws for dinner. You could serve “Peking duck with yoghurt and anchovy dressing”, a bold but possibly unpleasant dish. If family peace is the goal, maybe it is wiser sticking to something from a reliable cookbook, which is widely accepted and less surprising. Delay analysis is similar: there are recognised, time-tested methods that keep everyone calm and the discussions productive.

There are only a few recognised ‘cookbooks’ when it comes to delay analysis. The most commonly referred ones are:

• AACE International (Association for the Advancement of Cost Engineering) details recommended practices favoured by courts and boards in North America.
• Society of Construction Law (SCL): the Delay and Disruption Protocol (2nd ed., 2017) offers practical guidance on what to use and when. The protocol is widely used in the UK, the Middle East and Asia Pacific.

Conveniently, both bodies broadly agree to the same families of methods. Choose from those, and it is less likely to go wrong.

Delay analysis methods fall into two timing -based categories: prospective and retrospective. Understanding which to apply is fundamental before choosing a method.

Prospective delay analysis methods

Prospective methods look at the world as it was when the delay hit and forecast what might happen next. Impacted-as-Planned (IAP) and its sometimes-mischievous cousin Time Impact Analysis (TIA) sit here.

In prospective delay analyses, the analyst inserts a fragnet (a small, logic-linked bundle of activities that represents the delay at hand) into the programme and observe if the relevant completion date moves. If it shifts, the movement is attributed to the fragnet and, by extension, to the delay event it represents.

The Good

• Prospective methods are great for predicting impacts while events are unfolding.
• Most standard form of contract require early notice; plus, a sense of how much time will be needed . Prospective methods help you avoid the “our ship that carries the steel sank; therefore, we suppose we’ll be a bit late” one-liner.
• Prospective methods are generally less complex and can be prepared quickly.

The Bad

• Forecasts are like weather apps: sometimes perfect, sometimes… not so much. Predicted and actual delays can diverge.
• They rely on a sound programme: sensible logic, calendars and proper status updates. If you put garbage in the oven, do not expect a tasty dish out.

The Ugly

• If the analyst only models the shiny fragment of their choice, the other (often less favourable) causes of delay can easily be masked.

Impacted-As-Planned (IAP)

In this analysis, an agreed baseline is impacted by a fragnet. The analysis is best utilised prior to commencement or early in the project for delays such as site access, design release, or procurement issues, and where minimal progress has occurred.

Time Impact Analysis (TIA)

The same concept as an IAP applies, except a TIA impacts a statused programme update showing actual progress up to its data date. Typically, a statused programme update is selected (or prepared) immediately before or as close as practicable to the delay event. The analysis is more reliable when the update mirrors site reality and no competing delays are omitted, whether intentionally or not.

Prospective methods shine during project delivery. Once the dust settles and the facts are known, tribunals generally prefer retrospective methods, unless the decision maker or the contract expressly calls for a prospective approach in dispute resolution. As someone wisely put it: why look into a crystal ball when you have the facts?

If you are still wondering why TIA is the sometimes-mischievous cousin, do not fret. This is not a Christopher Nolan movie, so we leave no questions unanswered. The mischief occurs when a TIA is used retrospectively: the analyst ‘steps back’ to stand at some past data date, hypothesises what the project team might have known at that time, and tries to fuse that guesswork with later project facts. If that sentence felt hard to read, imagine how hard it is to make such an analysis both reliable and accurate.

Retrospective delay analysis methods

Retrospective methods look back once the dust has settled and ask two plain questions: what actually happened, and what actually drove completion.

The Good

• Retrospective methods generally rely on the as-built data. Therefore, they are more factual and less fictional.
• The methods do not rely on software and therefore can be understood by wider audience and those unfamiliar with programming outputs.

The Bad

• Retrospective methods depend on the quality of the as-built data. If as-built data is poor or absent altogether, then it is difficult (or even impossible) to utilise them.
• If the initial plan differs significantly from reality, then some retrospective methods may not produce reliable results.
• Retrospective methods can be time consuming, especially in circumstances where as-built records are difficult to obtain.

The Ugly

• While the analysis is factual, the analyst’s experience and judgement still shape the flavour. As a result, the ‘taste’ of the analysis can differ significantly from one expert to another, depending on how they interpret the results.

Here are the most widely used retrospective delay analysis methods.

As-Planned versus As-Built (APAB)

APAB is the most commonly used method in a dispute settlement environment, whether it is an arbitration or litigation. In this analysis, a planned sequence and dates are compared against the as-built sequence and dates, then trace where reality diverged from the plan. This method especially becomes powerful when the project duration is divided into several windows, especially around important dates/events or when the critical path is suspected to shift.

APAB is a strong factual analysis that provides a clear narrative; easy to explain and understand, also highlights slippage periods clearly. The analysis requires reliable as-built data and a baseline programme to compare against.

APAB struggles when the plan and actual execution diverge substantially; if the baseline no longer reflects reality, comparison loses probative value.

Windows / Time-Slice Analysis

In this analysis, the project duration is divided into windows (often monthly, more detailed than APAB in that sense). For each window, the analyst takes the statused programme update at the start of that window, inputs the actuals and events for the period, re-schedules, and observes how the forecast finish and controlling path move. This produces a period-by-period causation map.

Time Slice Analysis is another strong retrospective analysis method, occasionally used in arbitration/litigation settings. Similar to APAB, it is also a factual method, however the main drawback is the requirement for robust, statused programme updates. Without this, the work becomes more labour-intensive and even unreliable. Further, errors or omissions in the programme’s logic can amplify disagreements between the parties.

Collapsed As-Built (But-for) Analysis

But-for analysis relies on a sound as-built model. The analyst then removes the specific delay events being tested and asks, but for those events, when would the project have finished?

But-for analysis is useful in limited circumstances, particularly for demonstrating whether a delay is or is not driving the project’s longest path. Its main handicap is logic quality: while project teams often curate logic links in the planned programme, few maintain those links as work progresses.

As a result, an as-built programme logic is often less robust than a baseline. Add to that the method’s counterfactual nature (remember, we are modelling hypothetical scenarios) and the output can become highly speculative. Used as the sole analysis in arbitration or litigation, a but-for tends to have the persuasive power of a simulation theorist: interesting, but near-impossible to prove.

Retrospective Longest Path Analysis

The last analysis method deserves mentioning is the Retrospective Longest Path. In this analysis, the analyst traces the actual controlling logic through key periods to determine what really drove project completion. The longest path identified this way is the actual critical path and it can be used to corroborate findings from other delay analyses methods.

Generally, entitlement is assessed by reference to the contemporaneous critical path, what was critical at the time, based on the information then available, rather than what later turned out to be critical with the benefit of hindsight. The decision maker’s task is to decide whether an EOT was properly due at the time, not to solve a twisty mystery after the fact. It would therefore be bold to rely on this method alone in arbitration or litigation.

Summary: Prospective methods shine while the storm rages; retrospective methods tell the story when the dust settles. Pick your analysis to suit the circumstances and the data you have; you cannot cook Peking duck without a duck. Common sense should sit at the heart of your analysis, and if your findings are too intricate to explain, you probably need to reconsider your method choice. Stick to well-known, widely accepted recipes and you are less likely to miss the mark. And if you are tempted to invent a brand-new dish, skip the yoghurt and anchovy dressing.