EOT Claim Analysis: The Complete Guide to Delay Analysis Methods, Preparation and Review

A contractor submits an extension of time claim for 94 calendar days. The programme attached to the claim has activities missing logic, open ends on the critical path, and a data date that doesn’t match any progress report. The claim gets rejected, not because the delays weren’t real, but because the analysis can’t survive scrutiny. The pattern is common on disputed projects. Flyvbjerg’s data shows the underlying weather: 91.5% of major projects run over budget or over programme, and only 0.5% hit their targets on cost, time, and benefits. Most of the disputes that follow hinge on whether the delay analysis holds up, not on whether the delay occurred.

The gap between experiencing a delay and proving one is where most claims fail. A valid delay event doesn’t automatically produce a valid EOT. You need a methodologically sound analysis, built on a properly constructed programme, supported by contemporaneous records. This article covers the six recognised delay analysis methods, how to prepare a defensible claim, how to review one from the employer’s side, and why programme quality is the hidden foundation underneath all of it. If you want the wider context first, our overview of the discipline of construction schedule analysis sets the scene.

Why Proper Delay Analysis Matters

The cost of a failed EOT claim isn’t just the time you didn’t recover. It’s the cost of preparing the claim, the consultant fees for the analysis, the months of dispute, and the opportunity cost of resources tied up in arguments instead of delivery. On Boston’s Big Dig, programme disputes contributed to a project that ran from a $2.8 billion budget to $14.6 billion at completion (more than $22 billion once interest on the borrowed funds was counted) and finished nine years late against its original 1998 plan. The Holyrood Parliament Building in Scotland opened three years later than originally programmed against a final outturn of around £431 million, compared with an initial estimate of approximately £40 million at the start of construction (Auditor General for Scotland, 2004). In both cases, delay analysis methods and programme quality were central to the disputes.

Two standards govern how delay analysis should be conducted. The Society of Construction Law (SCL) Delay and Disruption Protocol, 2nd Edition (February 2017), sets out principles for delay analysis and programme preparation. Paragraph 11 addresses delay analysis methods directly, and paragraph 11.4 identifies Time Impact Analysis as the preferred method. AACE International’s Recommended Practice 29R-03, Forensic Schedule Analysis, classifies methods in Section 4.2 and addresses schedule integrity requirements in Section 3.3.

There’s a critical distinction that too many parties miss: notification isn’t substantiation. Most contracts require notice of a delay event within a set period, often 14 or 28 days. That notice puts the other party on alert. But notice alone doesn’t entitle you to an EOT. You still have to prove the delay, prove it was on the critical path, and prove the cause falls within the contract’s compensable events. Many contractors serve notice on time, then submit a claim months later that can’t connect the event to the programme impact. That’s a claim that fails at the first hurdle. Our companion guide on the extension of time claim process walks through the contractual and procedural mechanics in detail.

The Six Methods of Delay Analysis

Six methods dominate forensic schedule analysis. Each has a place, and each carries risks that you need to understand before selecting one.

As-Planned vs As-Built

This is the simplest method: you overlay the as-planned programme against the as-built reality and measure the difference. It works best when delays are few, clearly identifiable, and sequential. The mechanics overlap heavily with the techniques covered in our guide to comparing the baseline against the current schedule. The method’s weakness is that it can’t isolate individual delay events from one another. When delays overlap, which is common on any project of scale, the analysis becomes muddled.

Use this method for simple projects with limited delay events. Don’t use it for complex disputes.

Impacted As-Planned

You take the as-planned programme and insert delay events as fragnet activities. The method is prospective in nature; it shows what would have happened if the delay events were known in advance. It doesn’t account for actual progress or the real sequence of work.

The method is quick and inexpensive, which makes it attractive for early-stage claims. But tribunals and reviewers often reject it because it ignores what actually happened. The impacted as-planned method is useful as an initial screening tool, not as a primary dispute analysis.

Time Impact Analysis (TIA)

TIA is the SCL Protocol’s recommended method for contemporaneous assessment of EOT applications during the project (paragraph 4.12, Core Principle 4). For analysis time-distant from the delay event, the 2nd Edition removed any expressed preference (Introduction §K(c)); the choice depends on the criteria in paragraph 11.3. You take a progress update, insert a fragnet representing the delay event, and recalculate the completion date. Then you compare the result to the un-impacted update.

The strength of TIA is that it works on actual progress data at a point in time, respects the programme logic, and can isolate individual delay events. Its weakness is that it requires a reliable, progressed programme for each delay event. If the underlying programme is poor, TIA produces unreliable results.

TIA is the right choice for prospective claims during the project. It’s also defensible in retrospect, provided the programme updates were contemporaneous and of adequate quality.

Collapsed As-Built / As-Built But-For

You start with the as-built programme and remove the delay events to see what the completion date would have been without them. The method works backwards from reality.

Collapsed as-built avoids the problem of relying on a flawed as-planned programme. But it requires a thorough as-built programme, which isn’t always available. It also assumes you can accurately model the removal of delays from the actual sequence, which gets complicated when delays are concurrent.

Use this method when the as-planned programme is unreliable but the as-built is well documented.

Windows Analysis

The windows method divides the project period into time windows and analyses the critical path and delays within each window. It accounts for progress, logic changes, and delay events within their actual timeframes.

The method is respected because it reflects what happened in practice. However, the choice of window boundaries can affect the results. Small windows are more precise but more labour intensive; large windows may obscure the real causation.

Windows analysis suits complex projects with many overlapping delays and is particularly effective in retrospective disputes.

Retrospective Critical Path Analysis

This method identifies the critical path based on what actually happened, not on what was planned. It’s a reality-based approach that can be persuasive, but it risks being labelled as hindsight analysis.

Retrospective critical path analysis works when contemporaneous programmes are unreliable or absent and you need to reconstruct the critical path from available records.

Table: Comparison of Delay Analysis Methods

Method Direction Data Required Best Use Case Key Risk
As-Planned vs As-Built Retrospective As-planned and as-built programmes Simple projects with few delays Can’t isolate overlapping delays
Impacted As-Planned Prospective As-planned programme only Early screening of potential claims Ignores actual progress
Time Impact Analysis Prospective Progressed updates plus fragnets Compensable delay claims during project Dependent on programme quality
Collapsed As-Built Retrospective As-built programme with delay events Unreliable as-planned programme Modelling delay removal is complex
Windows Analysis Retrospective Progress data across defined intervals Complex, multi-delay disputes Window boundaries affect results
Retrospective Critical Path Retrospective Progress records, as-built data No reliable contemporaneous programme Risk of hindsight bias

Method	Direction	Data Required	Best Use Case	Key Risk
As-Planned vs As-Built	Retrospective	As-planned and as-built programmes	Simple projects with few delays	Can’t isolate overlapping delays
Impacted As-Planned	Prospective	As-planned programme only	Early screening of potential claims	Ignores actual progress
Time Impact Analysis	Prospective	Progressed updates plus fragnets	Compensable delay claims during project	Dependent on programme quality
Collapsed As-Built	Retrospective	As-built programme with delay events	Unreliable as-planned programme	Modelling delay removal is complex
Windows Analysis	Retrospective	Progress data across defined intervals	Complex, multi-delay disputes	Window boundaries affect results
Retrospective Critical Path	Retrospective	Progress records, as-built data	No reliable contemporaneous programme	Risk of hindsight bias

Caption: Comparison of the six recognised delay analysis methods, their data requirements, and primary risks.

Which Delay Analysis Method to Use

Method selection isn’t a matter of personal preference. It depends on four factors: the project stage, the data available, the complexity of the dispute, and what the contract requires.

The SCL Protocol recommends prospective methods for claims prepared during the project. For retrospective analysis, the Protocol accepts that either TIA or windows analysis can be appropriate, depending on data quality. AACE 29R-03, Section 1.4 (Taxonomy and Nomenclature), classifies methods by timing (Layer 1: Prospective vs Retrospective) and basic approach (Layer 2: Observational vs Modeled), with Modeled methods further split into Additive (Layer 3) and Subtractive in Sections 3.6–3.9, which provides a structured basis for selection.

When the contract specifies a method, that’s what you use, even if it’s not your preferred approach. When the contract is silent, select the method that matches the data you have and the question you need to answer.

Table: Method Selection Decision Guide

Situation Recommended Method Rationale
Claim during project, good programme data TIA Prospective, addresses each event, SCL preferred
Claim during project, fair programme data Impacted as-planned (screening only) Quick but must be supplemented later
Retrospective claim, strong as-built Collapsed as-built or windows Accounts for actual sequence
Retrospective claim, many concurrent delays Windows analysis Isolates delays by time period
No reliable contemporaneous programme Retrospective critical path Reconstructed from available records
Simple project, one or two delay events As-planned vs as-built Simple, transparent
Contract specifies a particular method Whatever the contract says Contractual compliance is non-negotiable

Situation	Recommended Method	Rationale
Claim during project, good programme data	TIA	Prospective, addresses each event, SCL preferred
Claim during project, fair programme data	Impacted as-planned (screening only)	Quick but must be supplemented later
Retrospective claim, strong as-built	Collapsed as-built or windows	Accounts for actual sequence
Retrospective claim, many concurrent delays	Windows analysis	Isolates delays by time period
No reliable contemporaneous programme	Retrospective critical path	Reconstructed from available records
Simple project, one or two delay events	As-planned vs as-built	Simple, transparent
Contract specifies a particular method	Whatever the contract says	Contractual compliance is non-negotiable

Caption: Decision guide for selecting the appropriate delay analysis method based on project conditions.

flowchart TD A{"Is the claim\nprospective?"} -- Yes --> B{"Is the programme\nreliable?"} A -- No --> C{"Is there a strong\nas-built programme?"} B -- Yes --> D["Time Impact Analysis"] B -- No --> E["Impacted As-Planned\nfor screening only"] C -- Yes --> F{"Are delays\nconcurrent?"} C -- No --> G["Retrospective\nCritical Path Analysis"] F -- Yes --> H["Windows Analysis"] F -- No --> I["Collapsed As-Built"]

Figure 3: Decision tree for selecting the appropriate delay analysis method

Prepare a Defensible EOT Claim

A defensible EOT claim rests on a defensible programme. We’ll cover the steps in order, but don’t skip the first one. If the programme doesn’t pass basic quality checks, the analysis built on it won’t either.

flowchart LR A[1. Check Schedule\nQuality] --> B[2. Identify\nDelay Events] B --> C[3. Establish\nCritical Path] C --> D[4. Perform\nAnalysis] D --> E[5. Address\nConcurrent Delay] E --> F[6. Quantify\n& Submit]

Figure 1: Six-step EOT claim preparation process

Check Schedule Quality Before Analysis

Before you run any delay analysis, run the DCMA 14-Point Assessment on the programme. If the programme fails on missing logic, constraints, or negative float, the delay analysis results are unreliable. Fix the programme first.

The DCMA 14-Point is a pre-claim quality gate, not a final standard. It tells you whether the programme is good enough to analyse. The GAO Schedule Assessment Guide (December 2015), Chapter 8, provides a broader quality framework that supplements the DCMA checks.

Identify and Document Delay Events

List every event that caused or may cause delay. For each event, record: the date it occurred, the cause, the contract clause under which you claim entitlement, the activities affected, and the number of days of delay.

Document events as they happen. Contemporaneous records carry far more weight than reconstruction months after the fact. A site diary entry from 14 March 2025 beats a recollection from October 2025 every time.

Establish the Critical Path

The critical path determines whether a delay event actually affects the project completion date. A delay on a non-critical path activity consumes float, but it doesn’t entitle you to an EOT until that path becomes critical.

Identify the critical path through the programme logic. Don’t assume the longest path in the as-built equals the critical path in the as-planned. The critical path can shift during the project as delays consume float on near-critical paths.

Perform the Delay Analysis

Select the appropriate method, apply each delay event systematically, and record the impact on the completion date. If you’re using TIA, apply delay events in chronological order, using the programme update immediately prior to each event as the base.

Document every step: the base programme used, the fragnet inserted, the calculated completion date, and the resulting extension. Transparency makes the analysis auditable. Opaque analyses invite challenge.

Address Concurrent Delay

Concurrent delay exists when two or more independent delay events affect the critical path at the same time. One may be the contractor’s responsibility; the other may be the employer’s. Most standard forms handle concurrent delay differently, but the principle is consistent: if both parties caused delay at the same time, neither gets the full benefit. For a deeper treatment of how to identify and apportion these situations, see our explainer on concurrent delay in construction claims.

Identify concurrent delays honestly. Trying to ignore a contractor-caused delay that overlaps with an employer-caused one is the fastest way to lose credibility with a tribunal.

Quantify the EOT and Prepare the Submission

Calculate the total extension of time by aggregating the results. Cross-check against the actual completion date to confirm the analysis makes sense. If your analysis shows 60 days of EOT but the project finished 120 days late, there’s a gap you need to explain.

Prepare the submission with clear references to the contract clause, the delay event, the programme analysis, and the resulting EOT. Include the programme files, not just PDFs. Reviewers need to be able to open the programme and verify the logic.

Review an EOT Claim: The Employer’s Perspective

If you’re reviewing an EOT claim, your job is to test it, not to accept it. The following five steps will get you to a defensible position.

flowchart LR A[1. Check Contractual\nCompliance] --> B[2. Assess Schedule\nQuality] B --> C[3. Review\nMethodology] C --> D[4. Evaluate\nConcurrent Delay] D --> E[5. Assess\nMitigation]

Figure 2: Five-step employer review process for EOT claims

Verify Contractual Compliance

First, check whether the claimant complied with the notice and claim procedures in the contract. Did they notify within the required period? Did they provide the particulars the contract demands? If the contract requires substantiation within 28 days of notice, and the claim arrives 90 days late, you have a procedural basis to reject it, regardless of the delay’s merits.

Check this before you invest time in the technical analysis. Procedural non-compliance is often dispositive.

Evaluate the Schedule Basis

Open the programme and check its quality. Run the DCMA 14-Point. Look for missing logic, excessive constraints, out-of-sequence progress, and negative float. If the programme can’t pass basic quality checks, the analysis built on it’s unreliable.

What we found: a claim built on a programme that fails the DCMA missing-logic threshold (five per cent of activities, metric 1) cannot rest on a defined critical path. The activities the analysis assumes are critical may not actually be critical once the missing predecessors and successors are added. What it means: schedule quality has to be validated before the delay analysis runs, not after. A claim built on an unvalidated programme is speculative, and tends to read that way to an assessor.

Assess the Delay Analysis Methodology

Check whether the method is appropriate for the circumstances. If the claim uses impacted as-planned on a complex, multi-delay retrospective dispute, the method isn’t fit for purpose. If the contract specifies a method and the claimant used a different one, note the discrepancy.

Review each fragnet for logic and reasonableness. A fragnet that assumes a labour productivity of 50% without justification is a fragnet designed to inflate the delay.

Check for Concurrent Delay

Look for delays caused by the claimant that overlap with the compensable events. If the contractor was late mobilising, had supply chain issues of their own making, or failed to coordinate trades, and those delays overlap with employer-caused delays, concurrent delay applies.

Many claims conveniently omit concurrent delays. That omission is telling.

Review Mitigation and Reasonableness

Most contracts require the contractor to mitigate delay. Check whether the claimant took reasonable steps to minimise the impact. If the claim shows no acceleration effort, no re-sequencing, and no resource reallocation, the claimant may not have met their mitigation obligation.

Reasonableness also applies to the claimed extension itself. If the event is a two-week design information delay, and the claimant seeks 12 weeks of EOT, the analysis needs to show why the ripple effect produced six times the original delay.

Programme Quality as the Hidden Foundation

Poor programmes produce indefensible claims. This isn’t a controversial statement; the SCL Protocol’s second edition is explicit at §4.7 that the most recent updated programme is the primary tool for assessing EOT applications, and AACE RP 29R-03 §3.3 sets out the schedule-integrity preconditions that any forensic method requires.

The common defects are consistent: missing logic, excessive constraints, negative float, out-of-sequence progress, and open ends on or near the critical path. Each of these defects undermines the critical path and therefore undermines any delay analysis that depends on it.

The DCMA 14-Point Assessment is the minimum quality gate. If the programme doesn’t pass, don’t analyse it. Fix it first. The assessment checks for missing logic (§1), hard constraints (§5), negative float (§7), and other structural defects that render a programme unreliable for forensic analysis.

The James Webb Space Telescope launched in December 2021 against an original 2007 launch target, and the final development cost reached the order of US$10 billion against early-2000s estimates of a few billion dollars. The California High-Speed Rail project ballooned from $33B to more than $100B. In both cases, the gap between planned and actual was so large that any delay analysis had to reckon with programmes that no longer reflected reality partway through. That’s what happens when the programme degrades beyond recovery: the analysis becomes reconstruction, not evaluation.

Callout: Programme Quality Checklist Before Any Delay Analysis

Open ends: zero on the critical path

Constraints: limited to contractually mandated dates only

Negative float: none; investigate and resolve

Missing logic: zero activities without at least one predecessor and one successor

Out-of-sequence progress: identified and explained

Data date: matches the relevant progress reporting period

Critical path: continuous and logical from start to finish

Caption: Pre-analysis quality checks that must be satisfied before any delay analysis is credible.

Records and Verification

Contemporaneous records are the evidence base for any EOT claim. Without them, the analysis is reconstruction, and reconstruction is always less convincing than documentation created at the time.

The records that matter most include: site diaries, progress meeting minutes, correspondence giving or withholding instructions, programme progress updates, photographs with dates, resource allocation records, and inspection records.

A programme update saved on 15 June 2025 showing the impact of a delay event that occurred on 10 June 2025 is contemporaneous. A programme created in November 2025 that purports to show conditions in June 2025 isn’t. The distinction matters, and tribunals are alert to it.

Organise records chronologically, cross-referenced to delay events. This makes the reviewer’s job easier and makes the claim more credible. A reviewer who can verify a claim quickly is a reviewer more likely to accept it.

Standards References

The following standards are directly relevant to EOT claim analysis and should be consulted for detailed guidance:

SCL Delay and Disruption Protocol, 2nd Edition (February 2017): Section 11 (paragraphs 11.1–11.8) for delay analysis methods; paragraph 4.12 for TIA as the recommended method for contemporaneous assessment (with preference removed for time-distant analysis per Introduction §K(c)); paragraph 1.56 for the requirement that the Accepted Programme be reasonable, realistic and achievable
AACE Recommended Practice 29R-03, Forensic Schedule Analysis: Section 2 (SVP 2.1–2.4) for source/schedule integrity requirements; Section 1.4 (Taxonomy and Nomenclature) for method classification (prospective vs retrospective; observational vs modeled; additive vs subtractive)
DCMA 14-Point Assessment: As a pre-claim schedule quality check, applicable before any forensic analysis begins
GAO Schedule Assessment Guide (December 2015): Chapter 8 for programme quality criteria and best practice assessment

Close

A successful EOT claim isn’t built on argument. It’s built on a sound programme, a defensible analysis, and contemporaneous records that connect the event to the delay. Get the programme right first; everything else follows. Skip that step, and you’re building a claim on sand.