Delay Analysis Methods Explained: As-Planned vs As-Built, Windows and Impacted Programmes

Every delay analyst has a favourite methodology. That preference is the first thing that goes wrong. Choosing a delay analysis methodology based on familiarity rather than fitness is like choosing a scalpel because you like the handle. The instrument must match the operation. In construction delay claims across the GCC, we see the same pattern repeatedly: a technically competent analyst applies a method that does not fit the available records, the contract requirements, or the nature of the delay. The analysis is internally consistent. It is also useless, because the foundation it rests on cannot bear the weight the tribunal places on it.

Why Delay Analysis Methodology Selection Determines Outcomes

The SCL Protocol, now the closest thing the industry has to an international standard for delay analysis, makes one position clear: no single methodology is inherently superior. Each method has conditions under which it is appropriate and conditions under which it is not. The choice depends on the quality and completeness of the programme records, the nature of the delays in question, and the requirements of the contract. This sounds reasonable in the abstract. In practice, it means the analyst must audit the evidence before selecting the tool, not after.

This is where most analyses go wrong. The analyst selects the method at the start of the engagement, often at proposal stage, before examining the contemporaneous programme records. The method is then applied to whatever records exist, regardless of whether those records can support it. The result is an analysis that looks rigorous on paper but collapses under cross-examination when the opposing expert asks a simple question: where is the baseline programme that underpins this analysis, and can you demonstrate that it was accepted by the Engineer.

As-Planned vs As-Built: Simple, Seductive, and Frequently Misapplied

The as-planned vs as-built method is the most intuitive approach to delay analysis. It compares the original planned programme with the actual sequence and timing of events. The difference between the two, mapped against identified delay events, forms the basis of the claim. It is easy to explain. It is easy to follow. It is the method most likely to be selected by contractors preparing claims without specialist delay analysis support.

The seduction of simplicity is its weakness. As-planned vs as-built is a retrospective method. It looks at the gap between what was planned and what happened, but it does not account for the dynamic reality of a live construction programme. It assumes the as-planned programme was achievable, that the logic and durations were realistic, and that the critical path at the start of the project remained the critical path throughout. On a 24-month infrastructure project in Qatar or Saudi Arabia, that assumption is almost never valid. The critical path shifts as work progresses, as resources are redeployed, as design information arrives out of sequence, and as access constraints evolve.

The evidence requirements for a credible as-planned vs as-built analysis are lower than for other methods, which is both its advantage and its vulnerability. The analyst needs the original baseline programme and a reliable record of actual dates. Daily reports, progress photographs, monthly reports, and completion certificates provide the as-built chronology. But the method offers no mechanism for testing whether the as-planned programme was reasonable. If the planned durations were optimistic, or the logic was flawed, or the resource assumptions were unrealistic, the entire gap between planned and actual completion is attributed to delay events that may not have been the true cause. Arbitral tribunals in the GCC have rejected as-planned vs as-built analyses on precisely this ground: the as-planned programme was aspirational rather than achievable, and the delay attributed to the employer was, in reality, float that the contractor never owned.

The common mistakes in applying this method are consistent. The first is using a tender programme rather than an accepted baseline. Under FIDIC, the programme submitted under Clause 8.3 and accepted by the Engineer is the contractual baseline. The tender programme, prepared before contract award, carries no contractual status and may have been prepared with different assumptions. The second mistake is failing to identify all delay events, including contractor-caused delays, and attributing the entire gap to employer risk events. An honest as-planned vs as-built analysis must account for the contractor's own delays, or the analysis will be challenged as one-sided. The third mistake is ignoring concurrent delays entirely, presenting the gap as if only one party caused it.

Window Analysis: Precision Through Segmentation

Window analysis, sometimes called the time slice method, divides the project duration into discrete periods and analyses the delay within each window separately. Each window typically corresponds to a programme update period, a monthly reporting cycle, or a period bookended by significant delay events. Within each window, the analyst compares the planned progress against actual progress and identifies the delay events that caused the variance.

The strength of window analysis is its granularity. By breaking the project into segments, the method captures the dynamic nature of the critical path. A delay event that was critical in month six may have been absorbed by float in month eight. Window analysis can demonstrate this progression in a way that a single as-planned vs as-built comparison cannot. The SCL Protocol identifies window analysis as generally more reliable than a simple as-planned vs as-built comparison because it reflects the evolving reality of the project.

The evidence requirements for window analysis are substantially higher. The analyst needs not just the baseline programme but programme updates at each window boundary. If the contractor maintained and submitted monthly programme updates that were reviewed by the Engineer, window analysis is the natural fit. If the contractor submitted one programme at the start and never updated it, window analysis becomes an exercise in reconstruction rather than analysis. The distinction matters. A window analysis built on contemporaneous programme updates carries significant evidential weight. A window analysis built on reconstructed programmes carries very little, because the opposing expert will challenge every assumption embedded in the reconstruction.

The common mistakes in window analysis are methodological rather than conceptual. The first is selecting window boundaries that are too wide. A six-month window on a two-year project produces three or four data points, which is insufficient granularity to isolate the impact of individual delay events. Monthly windows, aligned with the programme update cycle, are the norm for a reason. The second mistake is inconsistency in critical path identification across windows. The critical path must be assessed independently in each window based on the programme status at that point, not projected forward from the baseline. The third mistake is failing to reconcile the sum of window-by-window delays with the actual project delay. If the individual windows show 120 days of employer delay but the project was delayed by 90 days, the analysis has a credibility problem that the opposing expert will exploit.

Time Impact Analysis: The Gold Standard and Its Demands

Time impact analysis is the method most frequently endorsed by arbitral tribunals and the SCL Protocol as the most reliable prospective approach. The method inserts each delay event into the programme at the point it occurred and measures its impact on the critical path at that moment. It is a forward-looking analysis that replicates the decision-making context of the project as it unfolded. The result is a sequence of programme snapshots, each showing the state of the project before and after the delay event was introduced.

The evidential demands are the highest of any method. Time impact analysis requires a robust baseline programme with properly defined logic, realistic durations, and an identifiable critical path. It requires contemporaneous progress records sufficient to update the programme to the status immediately before each delay event. It requires that the delay events themselves be documented with start dates, end dates, and causal descriptions supported by site records, correspondence, and instructions. Without these records, time impact analysis is not a viable method. Attempting it without the underlying data produces an analysis that is theoretical rather than evidential.

Under FIDIC, the programme submitted and accepted under Clause 8.3 provides the baseline for time impact analysis. If the contractor failed to submit a programme, or the Engineer never accepted one, the analyst faces a foundational problem. The SCL Protocol addresses this by permitting the use of a reconstructed programme in certain circumstances, but the weight attached to a time impact analysis built on a reconstructed baseline is materially lower than one built on a contemporaneous, accepted programme. This is one of the reasons the contemporaneous records that make or break a delay claim extend well beyond daily diaries and site instructions. The programme itself, and the record of its submission, review, and acceptance, is among the most critical contemporaneous documents in any delay analysis.

The common mistakes in time impact analysis are the most consequential. The first is using a baseline programme that was never accepted by the Engineer, without disclosing that fact. The opposing expert will establish this within the first hour of examination. The second is failing to update the programme to its actual status before inserting each delay event. If the programme is not updated, the impact of the delay event is measured against a theoretical state rather than the actual state of the project, and the result is unreliable. The third mistake is cherry-picking delay events, inserting only employer-caused delays and omitting contractor-caused delays. A one-sided time impact analysis is transparent to any competent tribunal and damages the analyst's credibility on every other point in the claim.

Choosing the Method: Evidence First, Not Preference First

The decision framework is not about which method is theoretically best. It is about which method the available evidence can support. If the contractor maintained a robust baseline programme, submitted regular updates, and kept detailed progress records, time impact analysis is the strongest option. If the programme updates exist but the baseline is weak, window analysis may be more appropriate. If neither updated programmes nor a reliable baseline exists, as-planned vs as-built may be the only viable method, but the analyst must acknowledge its limitations rather than present it as definitive.

The SCL Protocol recommends that the analyst explain why the chosen method was selected and why alternative methods were not. This is not a formality. Tribunals expect the analyst to demonstrate that the method was chosen because it fits the evidence, not because it produces the most favourable result. The reasons why so many EOT claims get rejected often include methodology selection that does not match the available records. The methodology is challenged, the analysis is discredited, and the substantive delay events are never properly considered.

The Mistakes That Lose Claims

Across dozens of delay analyses reviewed in CALIM's practice, the mistakes that cause analyses to fail under scrutiny follow a predictable pattern. The first is selecting the method before auditing the records. The second is applying the method without acknowledging its limitations in the specific context. The third is presenting a one-sided analysis that ignores contractor-caused delays. The fourth is failing to reconcile the analytical result with the actual project delay. The fifth, and perhaps the most damaging, is treating the delay analysis as an advocacy exercise rather than an expert exercise. A delay analysis that reads like a submission rather than an opinion will be treated as one by the tribunal, and its evidential weight will be adjusted accordingly.

CALIM selects the delay analysis methodology after auditing the contemporaneous records, not before. The method is matched to the evidence, the contract, and the forum. The analysis accounts for all delay events, regardless of which party caused them. The result is a delay analysis that withstands cross-examination because it was built to inform the tribunal, not to persuade it.

The method that fits the evidence is the method that wins the claim.

Frequently Asked Questions

What is the difference between as-planned vs as-built and window analysis?

As-planned vs as-built compares the original programme with the actual completion in a single comparison across the entire project duration. Window analysis divides the project into discrete time periods and analyses the delay within each period separately, capturing how the critical path evolved over time. Window analysis is generally more reliable because it reflects the dynamic nature of construction programmes, but it requires programme updates at each window boundary to be credible.

When should I use time impact analysis instead of other methods?

Time impact analysis is appropriate when the contractor maintained a robust baseline programme that was accepted by the Engineer, kept regular programme updates reflecting actual progress, and has contemporaneous records documenting each delay event with sufficient detail to model its impact. If these records do not exist, time impact analysis should not be attempted, because the analysis will rest on assumptions rather than evidence and will be vulnerable to challenge.

What does the SCL Protocol say about choosing a delay analysis method?

The SCL Protocol states that no single methodology is inherently superior and that the choice depends on the circumstances of the project, including the quality of programme records, the nature of the delays, and the contractual requirements. The Protocol recommends that the analyst explain why the chosen method was selected and why alternatives were not adopted. It identifies time impact analysis and window analysis as generally more reliable than simple as-planned vs as-built, provided the evidential foundation supports their use.

What is the most common mistake in delay analysis?

The most common mistake is selecting the methodology before auditing the available evidence. An analyst who commits to time impact analysis at proposal stage and then discovers that the baseline programme was never accepted by the Engineer has a foundational problem that no amount of analytical rigour can overcome. The second most common mistake is presenting a one-sided analysis that attributes all delay to the employer and ignores contractor-caused delays, which destroys credibility before the substantive issues are even considered.

Can I change the delay analysis method after starting the analysis?

Yes, and in some cases the analyst should. If the evidential audit reveals that the records cannot support the originally selected method, continuing with that method produces an analysis that will not withstand scrutiny. The SCL Protocol does not require the analyst to commit to a method at the outset. It requires the analyst to select and justify the method that best fits the circumstances. Changing methods after an honest assessment of the evidence is a sign of rigour, not indecision.

Note: This article provides general guidance on delay analysis methodology selection and application under FIDIC contracts and the SCL Protocol. The specific methodology appropriate to any delay claim depends on the contract terms, the available records, the nature of the delays, and the requirements of the dispute forum. Contractors should engage a qualified delay analyst to assess their specific circumstances before committing to a methodology.