Delay analysis is the process of determining the cause, responsibility, and impact of schedule delays on a construction project. It sounds academic. It isn't. On a £25M project running 3 months late, the difference between "contractor delay" and "employer delay" can be worth £1M or more in extension of time, prolongation costs, and liquidated damages liability.
There are five recognised methods for delay analysis in UK construction, each with different strengths, data requirements, and credibility with adjudicators. Which one you use depends on what records you have, when you're doing the analysis, and how much is at stake.
If you're running earned value management, your EVM data, particularly SPI trends and Schedule Variance, provides quantitative evidence that supports (or undermines) delay claims. More on that below.
This page is part of the earned value definitions glossary. For the full formula reference, see the earned value formulas page.
The Five Methods at a Glance
| Method | Timing | Complexity | Data Required | Best For |
|---|---|---|---|---|
| As-Planned vs As-Built | Retrospective | Low | Planned programme + as-built dates | Simple disputes, low-value claims |
| Impacted As-Planned | Prospective or retrospective | Medium | Baseline programme + delay events | Quick early assessments |
| Collapsed As-Built | Retrospective | High | As-built programme + delay events | Post-completion claims |
| Time Impact Analysis (TIA) | Contemporaneous | High | Updated programmes + delay events | High-value, complex claims |
| Windows Analysis | Retrospective | Very high | Period-by-period programmes + records | Major disputes, adjudication/litigation |
The SCL (Society of Construction Law) Delay and Disruption Protocol (2nd edition, February 2017) provides the authoritative guidance on these methods. If you're preparing a delay claim on a UK contract, that protocol is your starting point.
How Each Method Works
1. As-Planned vs As-Built
The simplest approach. Compare the baseline programme against what actually happened.
AS-PLANNED vs AS-BUILT Planned: |████████████████████| Finish: Week 20 Activity A: |████████| (Weeks 1-8) Activity B: |████████████| (Weeks 5-12) Activity C: |████████| (Weeks 11-16) Actual: |████████████████████████████████| Finish: Week 30 Activity A: |████████████| (Weeks 1-12) +4 weeks Activity B: |██████████████████████| (Weeks 7-18) +6 weeks Activity C: |██████████| (Weeks 17-24) +4 weeks Delay Events: D1: Design info late (Week 4) ──> Client risk D2: Labour shortage (Week 10) ──> Contractor risk D3: Unexpected ground (Week 15) ──> Client risk (CE)
Strengths: Easy to understand, doesn't require programming software, quick to prepare. Weaknesses: Doesn't account for concurrency, can't show causation (only correlation), not accepted for high-value claims.
2. Impacted As-Planned
Take the baseline programme and insert the delay events to model their theoretical impact. The programme is "impacted" forward from the planned dates.
Strengths: Shows the theoretical effect of each delay event, relatively quick. Weaknesses: Relies on a programme that may not reflect how the work was actually planned to be done. Subjective if the baseline wasn't resource-loaded or logically linked.
3. Collapsed As-Built
Start with what actually happened (the as-built programme), then remove delay events one by one to see what would have happened without them. The programme "collapses" back towards the planned dates.
Strengths: Grounded in reality (starts from actual events), works well retrospectively. Weaknesses: Requires a complete as-built record, can be manipulated by the order in which delays are removed.
4. Time Impact Analysis (TIA)
The gold standard. Insert delay events into the programme at the point they occurred, using the programme status at that time as the baseline. Run the analysis forward from each event.
Strengths: Most credible method, shows causation and effect contemporaneously, accepted by adjudicators and courts. Weaknesses: Requires regularly updated programmes (which most projects don't have), expensive to prepare, takes weeks of specialist input.
On NEC4 contracts, TIA aligns with the compensation event assessment process. Clause 63.5 requires the assessment to be based on the Accepted Programme current at the dividing date. That's essentially a TIA performed at the time of each CE.
5. Windows Analysis
Divide the project timeline into "windows" (typically monthly periods) and analyse delay within each window separately. This captures the evolving nature of the critical path.
Strengths: Most thorough approach, handles concurrent delays, shows how responsibility shifts over time. Weaknesses: Extremely time-consuming, expensive (£50K to £200K+ in specialist fees on complex claims), requires comprehensive records for every window.
Worked Example: £25M Rail Depot, 3 Months Late
Worked ExampleScenario: A £25M NEC4 Option C rail maintenance depot in Birmingham. Planned Completion was 20 December 2025. Actual completion was 18 March 2026, 88 days late.
Three delay events identified:
| Event | Date | Duration | Cause | Risk |
|---|---|---|---|---|
| D1: Design changes to drainage | 14 April 2025 | 35 days | Client instruction (CE) | Employer |
| D2: Steelwork fabrication delay | 2 June 2025 | 28 days | Subcontractor performance | Contractor |
| D3: Exceptional weather (Storm Edith) | 8 September 2025 | 22 days | Weather event (CE under 60.1(13)) | Employer |
Total delay events: 85 days. But the project was 88 days late. Where do the other 3 days come from?
The concurrency problem: D1 and D2 overlapped by 12 days. Between 2 June and 7 June 2025, both delays were running simultaneously. Under the SCL Protocol, where there's true concurrent delay (both employer and contractor delay events are critical path delays running at the same time), the contractor gets the extension of time but not the prolongation costs for the concurrent period.
TIA result:
- D1 (employer): 35 days delay to Completion
- D2 (contractor): 16 days net delay (28 days minus 12 days concurrency)
- D3 (employer): 22 days delay to Completion
- Float consumed: 3 days
Entitlement: 57 days extension of time (D1 + D3). Prolongation costs for 45 days (57 minus 12 concurrent days). Contractor absorbs 16 days of culpable delay plus the concurrent period costs.
Prolongation claim: 45 days x £8,200/day (site prelims) = £369,000 in prolongation costs, plus the time impact on the BAC adjustment through compensation events.
How EVM Data Supports Delay Claims
Here's where earned value becomes genuinely useful for delay analysis, and most teams don't realise it.
Your EVM data produces an SPI trend over time. That trend is quantitative evidence of when the project started falling behind and how the delay progressed. It's not a substitute for proper delay analysis (you still need one of the five methods above), but it's powerful corroborating evidence.
SPI trend as evidence:
SPI TREND – £25M Rail Depot 1.10 | 1.05 | * 1.00 |──*──*───*─────────────── Target line 0.95 | * 0.90 | * 0.85 | * * 0.80 | * 0.75 | * * * +────────────────────────────────────────── M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 D1 starts ──^ ^── D2 starts ^── D3 (Storm)
The SPI dropped from 1.02 (ahead of programme) in month 3 to 0.88 in month 5, exactly when D1 (drainage design changes) was causing delay. It recovered slightly before dropping again when D2 hit. The storm in month 8 pushed SPI to 0.75.
An adjudicator looking at this data can see the timing correlation between delay events and schedule performance degradation. That's much harder to argue against than a narrative statement saying "the project was delayed by design changes."
Common Mistakes
- Using the wrong method for the situation. As-Planned vs As-Built is fine for a £200K dispute. It'll get laughed out of the room on a £5M claim. Match the method to the value and complexity. If you're going to adjudication on anything over £500K, you need TIA or Windows Analysis.
- Not maintaining contemporaneous programme updates. TIA requires the programme status at the time each delay event occurred. If you only updated the programme twice in 18 months, you can't run a credible TIA. NEC4 requires programme updates at intervals stated in Contract Data (typically 4 weeks). Follow the contract and you'll have the records you need.
- Ignoring concurrency. Claiming 35 days of employer delay when 12 of those days were concurrent with contractor delay is a credibility destroyer. Address concurrency head-on in your analysis, even when it reduces your claim. Adjudicators reward honesty.
- Treating EVM data as a substitute for delay analysis. SPI and SV are indicators, not proof. They show when delays happened and how severe they were, but they don't establish causation or responsibility. Use EVM data to support your delay analysis, not replace it.
How Gather helps. Gather's AI reads your site diaries daily and maps progress against your cost-loaded programme, giving you accurate earned value data without manual spreadsheet updates. Book a demo to see it working on a live NEC4 project.
Frequently Asked Questions
Which delay analysis method is best?
There's no single best method. The SCL Protocol recommends Time Impact Analysis as the preferred approach where contemporaneous programme updates exist. If they don't, Collapsed As-Built or Windows Analysis are credible alternatives. For low-value disputes, As-Planned vs As-Built may be proportionate. Match the method to the records available and the value at stake.
How does delay analysis work on NEC4 contracts?
NEC4's compensation event process is essentially built-in delay analysis. When a CE affects Completion, the assessment under clause 63.5 uses the Accepted Programme to model the delay impact. This is a form of Time Impact Analysis. The result adjusts the Completion Date and the Prices simultaneously.
Can EVM data prove delay?
Not on its own. But SPI trends provide strong corroborating evidence. A sustained drop in SPI that correlates with a specific delay event is powerful quantitative support. Combine EVM data with one of the five recognised methods for a compelling delay claim.
What records do I need for delay analysis?
At minimum: the baseline programme, progress records (site diaries, meeting minutes, weekly reports), correspondence about delay events, and the as-built programme. For TIA, you also need regular programme updates. For Windows Analysis, you need period-by-period status. The more contemporaneous your records, the stronger your analysis.
.webp)
