Delay Analysis Methods in Construction: A Practical Guide

Every extension of time claim, every liquidated damages defence, and every delay dispute that ends up in adjudication comes down to one question: whose delay was it, and did it actually push the completion date back? Answering that question properly is what delay analysis construction professionals are trained to do, and getting it wrong is one of the most expensive mistakes a project can make.

This is not an academic exercise. On a £20m project running six months late, the difference between a robust windows analysis and a crude as-planned versus as-built comparison can be worth hundreds of thousands of pounds in liquidated damages, prolongation costs, or both. Contract administrators, adjudicators, and tribunals expect the analysis to be methodologically sound, not just directionally convincing.

This guide walks through the delay analysis methods set out in the Society of Construction Law Delay and Disruption Protocol (the SCL Protocol) - the closest thing the UK construction industry has to a common standard. We cover as-planned versus as-built, impacted as-planned, time impact analysis, collapsed as-built, and the two windows techniques, along with the record-keeping and concurrency issues that determine whether any of them will hold up.

Whether you are a quantity surveyor preparing an extension of time submission, a commercial manager defending against a liquidated damages deduction, or simply trying to understand what your delay expert is telling you, by the end of this article you will know which method fits which situation and why choosing correctly matters as much as running the numbers correctly.

• Prospective methods (time impact analysis) are used during the works to agree extensions of time in real time
• Retrospective methods (windows analysis, collapsed as-built) are used after completion when a dispute has crystallised
• The method chosen should match the contract's extension of time mechanism and the quality of records available
• Concurrent delay - where a contractor delay and an employer delay run at the same time - is the single biggest complicating factor in any analysis
• Contemporaneous records, not reconstructed narratives, are what make any method credible

Why Delay Analysis Matters on Every Project

Delay analysis sits at the intersection of programme management, contract administration, and dispute resolution. Under both JCT and NEC forms, a contractor's entitlement to an extension of time depends on proving that a specific event caused a specific, measurable delay to the completion date - not simply that the project finished late. Under NEC4, this is handled through compensation events assessed against the Accepted Programme; under JCT, it is handled through the relevant events and relevant matters mechanism in clause 2.26 onwards of the Standard Building Contract.

Without a defensible delay analysis, an employer has no reliable basis for deducting liquidated damages, and a contractor has no reliable basis for recovering prolongation costs or resisting those deductions. The analysis is what turns a dispute about opinions into a dispute about evidence.

The cost of getting it wrong

Poorly executed delay analysis is a recurring feature of failed claims. Analyses that rely on a simple narrative of events, that fail to test the critical path, or that ignore concurrent delay routinely collapse under cross-examination or adjudicator scrutiny. The SCL Protocol was created precisely because inconsistent, ad hoc approaches to delay analysis were driving unnecessary disputes and unpredictable outcomes across the industry.

For a QS or commercial manager, understanding these methods is not optional specialist knowledge - it directly affects how you build your monthly records, how you draft extension of time notices, and how confident you can be when a dispute is heading toward adjudication.

The SCL Delay and Disruption Protocol: The Industry Standard

First published in 2002 and substantially revised in its second edition (February 2017), the SCL Delay and Disruption Protocol is produced by the Society of Construction Law to provide practical, principle-based guidance on delay, disruption, and the assessment of time and money claims. It is not a contract document and has no binding legal status in the UK, but it is widely referenced by delay experts, adjudicators, and the courts as a benchmark for good practice.

The second edition deliberately moved away from recommending a single preferred method. Instead, it sets out 22 Core Principles and identifies the factors that should drive method selection: the purpose of the analysis, the terms of the contract, the value of the dispute, the time and resources available, and - critically - the quality and availability of programme and progress records. It also formally added two windows-based techniques that had become common in practice but were not covered in the first edition.

Prospective vs retrospective analysis

The Protocol draws a fundamental distinction that shapes every method choice: prospective analysis looks forward from the point a delay event occurs, using the programme as it stood at that time to predict the effect on completion. Retrospective analysis looks backward after the event (often after project completion) and uses as-built records to establish what actually happened. Prospective methods suit real-time extension of time assessment; retrospective methods suit post-completion disputes and litigation, where the full as-built picture is available.

• Prospective: assessed at or near the time of the delay event, using contemporaneous programme data (e.g. Time Impact Analysis)
• Retrospective: assessed after the event or after completion, using as-built records (e.g. Windows Analysis, Collapsed As-Built)
• Contract clauses often dictate which approach applies - NEC4's compensation event mechanism is inherently prospective

The Six SCL Protocol Delay Analysis Methods

1. Impacted As-Planned Analysis

This is the simplest and most theoretical method. Delay events are inserted directly into the original as-planned baseline programme, one after another, to see how the theoretical completion date shifts. It requires no as-built data at all - only the baseline programme and a list of delay events with their durations.

Its simplicity is also its weakness. Because it ignores everything that actually happened on site - re-sequencing, acceleration, concurrent progress, changes to the critical path - it is now regarded as the least reliable of the six methods and is rarely accepted on its own in a contested claim. It can still be useful for a very early, indicative assessment when as-built records simply do not yet exist.

2. Time Impact Analysis (TIA)

Time Impact Analysis is widely regarded as the most theoretically robust prospective method and is the technique most commonly required under NEC4's compensation event provisions. A delay event is inserted into an updated programme that reflects actual progress up to the point the event occurred, and the software recalculates the effect on the critical path and completion date.

Because TIA is run close to the time of the event, using a programme that reflects genuine progress, it produces a far more reliable result than impacted as-planned analysis. Its main drawback is resource intensity - it requires an accurate, regularly updated programme and a fresh 'impacted' analysis for every event, which can be onerous on projects with dozens of change events.

3. As-Planned versus As-Built Analysis

This method compares the planned dates for activities on the baseline programme against the actual dates they started and finished, identifying which activities on the critical or near-critical path slipped and by how much. It is intuitive, quick to produce, and easy for a non-expert to understand - which is why it remains popular for straightforward claims.

Its major limitation is that it does not properly identify the critical path as it evolved through the project, and it struggles badly with concurrent delay. It can show that completion slipped by twelve weeks without establishing which weeks were caused by the employer, which by the contractor, and which were genuinely concurrent. For anything beyond a simple, low-value dispute, it is usually treated as a starting point rather than a conclusive analysis.

4. Time Slice Windows Analysis

This is generally regarded as the most rigorous retrospective method and is the preferred technique for complex, high-value disputes. The project duration is divided into consecutive time windows - often monthly - and, for each window, the analyst uses the actual contemporaneous programme update (or reconstructs one) to identify the critical path and measure how much delay accrued during that period, and why.

Because it identifies the critical path afresh in every window, it correctly captures changes in the critical path over the life of the project and handles concurrent delay far more credibly than as-planned versus as-built. The trade-off is that it depends entirely on the existence of good-quality, regularly updated programmes throughout the project - something many contractors simply do not maintain.

5. As-Planned versus As-Built Windows Analysis

A variant of windows analysis for situations where contemporaneous programme updates were not kept, or were unreliable. Rather than relying on period-by-period programme updates, the analyst uses as-built data and a logic-linked model to establish critical path progress within each window. It delivers many of the benefits of time slice windows analysis without demanding a complete set of contemporaneous updates, making it a practical compromise on projects with patchy record-keeping.

6. Collapsed As-Built Analysis

Also known as the 'but-for' method, this technique takes the fully logic-linked as-built programme and subtracts (or 'collapses') the delay events attributable to one party to see what the completion date would have been 'but for' those delays. It requires no baseline programme at all, which makes it valuable when no reliable original programme survives.

Its major weakness is that constructing a fully logic-linked as-built programme after the fact is a subjective and labour-intensive exercise, and small changes in assumed logic can produce very different results. It is powerful when done well but vulnerable to challenge on the reasonableness of the logic applied.

Choosing the Right Method for Your Situation

Method selection is rarely a free choice - it is constrained by the contract, the timing of the analysis, the money at stake, and, above all, the quality of the records available. The SCL Protocol's own guidance is that the method should be proportionate to the value and complexity of the dispute, and should use the best evidence realistically available rather than the theoretically ideal evidence that does not exist.

• Real-time extension of time assessment on an NEC contract: use Time Impact Analysis, tied to compensation event notifications
• Post-completion dispute with good contemporaneous programme updates: use Time Slice Windows Analysis
• Post-completion dispute with poor or missing programme updates: use As-Planned v As-Built Windows Analysis or Collapsed As-Built
• Low-value, straightforward dispute with a handful of delay events: As-Planned v As-Built may be proportionate
• No reliable baseline programme survives at all: Collapsed As-Built is often the only realistic option
• Adjudication with tight timescales: favour the method your records can support quickly and defensibly, not the most sophisticated one on paper

Concurrent Delay: The Hardest Problem in Delay Analysis

Concurrent delay occurs when two or more delay events - typically one caused by the employer (or a matter for which the employer bears risk) and one caused by the contractor - are both operating on the critical path at the same time, each independently sufficient to cause the same period of delay. It is the single issue most likely to turn a delay analysis into a genuine legal dispute.

The SCL Protocol's Core Principle 10 states that where a contractor delay to completion occurs concurrently with an employer delay to completion, the contractor's concurrent delay should not reduce any extension of time due as a result of the employer delay. In other words, under the Protocol's approach, true concurrency does not automatically defeat the contractor's entitlement to time - though it typically does affect entitlement to prolongation costs for that period.

In practice, genuine concurrency - two events independently causing delay to the same days on the critical path - is rarer than parties often claim. Many disputes involve delays that merely overlap in time without both being truly critical, which is a different and much simpler situation. Distinguishing true concurrency from mere overlap requires a critical path analysis, not just a calendar comparison, which is exactly why the choice of underlying method matters so much.

• True concurrency requires both delay events to independently affect the critical path for the same period
• The English courts have generally followed the Protocol's approach (see Walter Lilly & Co Ltd v Mackay [2012])
• Contract amendments increasingly attempt to reallocate concurrent delay risk - always check the particular conditions before applying the default position
• Prolongation costs during a period of concurrent delay are usually treated differently from the time extension itself

Records: The Evidence That Makes Any Method Credible

No delay analysis method, however sophisticated, can compensate for poor records. The SCL Protocol's Appendix B sets out the categories of record that should be maintained throughout a project specifically to support delay and disruption analysis, and experienced QSs build their record-keeping discipline around this list from day one, not retrospectively when a dispute has already started.

Records every project should maintain

• Baseline programme and every subsequent revision, each clearly dated and version-controlled
• Monthly (or more frequent) progress updates showing actual start and finish dates for each activity
• Site diaries and daily records covering labour, plant, weather, and access
• Instructions, variations, and correspondence relating to changes, linked to specific programme activities
• Minutes of progress meetings, particularly where delay causes are discussed
• Photographic and drone survey records showing physical progress at regular intervals
• As-built records including delivery dockets, inspection records, and commissioning data

The practical reality on most projects is that these records exist in fragments across different systems - the programme lives in Asta or P6, correspondence lives in email, site records live in a site diary or a construction management platform. Part of preparing for a credible delay analysis is simply pulling these fragments into a single, chronologically ordered evidence base before the analyst starts work, because the analysis is only as good as the records underneath it.

Running the Analysis: A Practical Sequence

Regardless of which method is chosen, most credible delay analyses follow a broadly similar sequence, and understanding this sequence helps a QS anticipate what an expert (or the other side's expert) will need.

• Establish and validate the baseline programme - confirm it was realistic, properly logic-linked, and genuinely represents the original plan
• Identify and evidence each delay event, with dates, duration, and cause supported by contemporaneous records
• Determine the critical path at the relevant point(s) in time - this is the technical core of the analysis and the step most often done badly
• Apply the chosen method to isolate the delay effect of each event (or window) on the completion date
• Test for concurrency at each period where more than one delay event was live
• Reconcile the analysis output against the actual as-built completion date - a good analysis should explain the full gap between planned and actual completion, not just part of it
• Document the analysis methodology and assumptions transparently, so it can be tested and, ideally, replicated by the other side

Frequently Asked Questions

What is delay analysis in construction?

Delay analysis is the process of examining a construction project's programme and supporting records to identify the cause, extent, and effect of delays, and to determine which party is contractually responsible. It underpins extension of time claims, liquidated damages defences, and prolongation cost claims.

What is the most reliable delay analysis method?

There is no single 'most reliable' method for every situation, but Time Slice Windows Analysis is generally regarded as the most rigorous retrospective method because it re-establishes the critical path in every time window, and Time Impact Analysis is the most widely accepted prospective method for real-time extension of time assessment.

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

As-planned versus as-built simply compares the original baseline dates to the actual dates activities occurred, without re-establishing the critical path over time. Windows analysis breaks the project into shorter periods and re-establishes the critical path within each window, which captures how the critical path shifted during the project and handles concurrent delay far more reliably.

What is concurrent delay in construction?

Concurrent delay occurs when a contractor-caused delay event and an employer-caused (or employer-risk) delay event both independently affect the critical path during the same period. Under the SCL Protocol's default position, genuine concurrent delay does not reduce the contractor's entitlement to an extension of time, though it usually does affect entitlement to prolongation costs for that period.

Is the SCL Delay and Disruption Protocol legally binding?

No. The SCL Protocol is a guidance document produced by the Society of Construction Law, not a contract or a statute. It has no automatic legal force, but it is widely referred to by delay experts, adjudicators, and the English courts as a benchmark for good practice in delay analysis.

Which delay analysis method does NEC4 require?

NEC4 does not mandate a specific SCL method by name, but its compensation event mechanism - assessing the effect of an event against the Accepted Programme at or near the time it occurs - is inherently prospective and aligns closely with the principles of Time Impact Analysis.

What records do I need to support a delay analysis?

At minimum: the baseline programme and all revisions, regular progress updates, site diaries, instructions and variations linked to programme activities, meeting minutes, and photographic or survey evidence of progress. The SCL Protocol's Appendix B sets out the full recommended list.

Final Thoughts

Delay analysis is not primarily a scheduling exercise - it is an evidential one. The method you choose signals to the other side, and to any adjudicator or tribunal, how seriously you have engaged with the facts of the delay. Choosing a sophisticated method you cannot properly support with records is worse than choosing a simpler method you can fully evidence.

For most UK commercial teams, the practical takeaway is to build record-keeping discipline into the project from day one - regular, dated programme updates and a properly maintained delay event log will keep every method on the table when a dispute eventually arises, rather than forcing you into the weakest option because nothing else survives.

If you are heading into an extension of time negotiation or a dispute, get a delay analysis specialist involved early. The choice of method, made correctly at the outset, shapes the entire trajectory of the claim - and is far cheaper to get right the first time than to redo under pressure six weeks before an adjudication hearing.

Want the full picture? Want the full picture on construction disputes?

Read our guides to Construction Dispute Resolution Options for QSs and CMs and Construction Adjudication Explained for the next steps once a delay dispute crystallises, or see Compensation Events in NEC Contracts for how prospective delay assessment works in practice.