Choosing a Delay Method
Last reviewed 9 September 20263,492 words16 min read
Prospective or retrospective, observational or modelled — the decision tree before the analysis
🟩 In one line: The method is chosen by five things — what the contract says, whether you are looking forward or back, what records and programmes exist, how much is at stake, and who will scrutinise it — and both the SCL Protocol's six methods and AACE 29R-03's nine method implementation protocols sit on the same two axes: observational vs modelled, and static vs dynamic.
👤 Who this is for: Mid-level planners asked to "do the delay analysis"; senior planners advising the contracts manager on what to commission. Prerequisites: Time-impact-analysis, Concurrent-delay, Extension-of-time-basics.
First, let's be honest about why this page exists
Most delay analyses in the Gulf are chosen by habit: the contractor's planner does a TIA because that is what the last project did, the Engineer's consultant does an as-planned vs as-built because it is cheap, and the tribunal a year later asks why neither party used the method the contract required or the records supported. Method choice is not a technical preference; it is the first argument in the claim, and getting it wrong is how a good entitlement produces a bad number.
This page is the decision, not the methods. Each method has its own page. Here you learn the axes, the two taxonomies, the five factors, and how to write the one paragraph in the claim that justifies the choice.
🟨 The standard — what "good" looks like
| Source | What it says (paraphrased) | Use it for |
|---|---|---|
| SCL Delay and Disruption Protocol, 2nd ed. (2017), Core Principle 4 and Guidance Part B section 11 | Six commonly used methods: impacted as-planned; time impact analysis; time slice windows; as-planned vs as-built windows; longest path analysis; collapsed as-built. Choice depends on: contract terms; nature of the events; value of the dispute; time available; records available; programme information available; forum and level of scrutiny (check against your copy) | The six methods and the factors |
| SCL Protocol, Core Principle 4 | Contemporaneous, prospective assessment preferred while the project is running (TIA); after the event, a retrospective method informed by the as-built is generally more appropriate (check against your copy) | Prospective vs retrospective |
| AACE RP 29R-03 Forensic Schedule Analysis (2011) | Method implementation protocols (MIPs) classified by: observational vs modelled; static vs dynamic; gross vs periodic; additive vs subtractive; single vs multiple base. Nine MIPs numbered 3.1–3.9. Source validation protocols for as-planned, as-built and updates. Excusability, compensability and concurrency analysed after the schedule analysis (check against your copy) | The taxonomy and the validation steps |
| AACE RP 52R-06 Time Impact Analysis — As Applied in Construction | TIA as a prospective forward-looking method for contemporaneous EOT requests | When TIA is the right tool |
| ASCE 67-17 Schedule Delay Analysis | Standard guidelines for delay analysis practice: baseline validation, as-built development, method selection, concurrency (check against your copy) | Cross-reference |
| FIDIC 1999 Cl 20.1 / 2017 Cl 20.2; Cl 8.4 / 8.5; NEC Cl 62–63 | Contract may specify the method (often in PCs / Scope); NEC's Cl 63.3 / 63.5 effectively mandates a prospective, Accepted-Programme-based impact | Contract first |
| Hub convention | TIA base = last accepted update, never the baseline; fragnet per event with Reflection and comparison archived; concurrency three tests; planner shows paths, lawyers argue money | Your defaults |
🟢 Rule: read the contract first; while the job is live, impact the last accepted update prospectively; after the fact, let the as-built records choose between windows and collapsed as-built; and write down why in one paragraph before the analysis starts.
How it actually works
1. The two axes.
| Axis | Meaning | Ends |
|---|---|---|
| Observational vs modelled | Do you read what happened in the existing programmes (observational), or insert/remove events in a model and measure the change (modelled)? | Observational: as-planned vs as-built, windows, longest-path analysis. Modelled: impacted as-planned, TIA, collapsed as-built |
| Static vs dynamic | Do you use one programme (static) or a series of updates through time (dynamic)? | Static: gross as-planned vs as-built, impacted as-planned, single-base collapsed. Dynamic: windows, TIA on successive updates, multiple-base collapsed |
Add the time direction: prospective (forecasting the likely effect at the time of the event) or retrospective (measuring the actual effect afterwards).
2. The two taxonomies mapped to each other.
| SCL Protocol method | AACE 29R-03 MIP (approx.) | Observational / modelled | Static / dynamic | Direction | Needs |
|---|---|---|---|---|---|
| Impacted as-planned | 3.6 (modelled additive, single base) | Modelled | Static | Prospective (theoretical) | Baseline only |
| Time impact analysis | 3.7 (modelled additive, multiple base) | Modelled | Dynamic | Prospective | Baseline + updates at each event |
| Time slice windows | 3.3 / 3.4 (observational dynamic, contemporaneous as-is / split) | Observational | Dynamic | Retrospective | Baseline + reliable updates |
| As-planned vs as-built windows | 3.2 (observational static, periodic) or 3.5 (observational dynamic, modified/recreated) | Observational | Static periodic or dynamic | Retrospective | Baseline + as-built; updates optional |
| Longest path analysis (retrospective) | 3.1 / 3.2 variant using the as-built critical path | Observational | Static or periodic | Retrospective | Detailed as-built |
| Collapsed as-built | 3.8 / 3.9 (modelled subtractive, single / multiple base) | Modelled | Static or dynamic | Retrospective | Fully logic-linked as-built |
MIP numbering per 29R-03 — check the mapping against the RP yourself; the Protocol and the RP were written independently and the correspondence is approximate.
3. The five factors, as questions.
| Factor | Question | Pushes toward |
|---|---|---|
| Contract | Does the contract or PC name a method? Does NEC's Accepted-Programme mechanism apply? Is the claim being made now (Cl 20.1 interim) or after completion? | Named method; NEC → prospective impact on Accepted Programme |
| Timing | Is the project live and the event recent? | Live → TIA. Post-completion → windows or collapsed as-built |
| Records | Do reliable monthly updates exist? Is there an as-built with dates and logic? Is the baseline validated? | Good updates → time slice windows or TIA. As-built only → as-planned vs as-built windows or longest path. Fully linked as-built → collapsed as-built. Baseline only → impacted as-planned (weak) |
| Stake and time | Value of the claim vs the cost and weeks of analysis | Small/quick → windows on updates. Large/contested → dynamic method with full validation |
| Forum | Engineer's determination, DAAB, arbitration, court? | Higher scrutiny → observational dynamic with validated sources; avoid impacted as-planned |
4. The choice in practice.
| Situation | Method | Why |
|---|---|---|
| Live FIDIC job, variation instructed last month, EOT claim due | TIA on the last accepted update (52R-06) | Prospective, contemporaneous, Protocol Core Principle 4; the Engineer expects it |
| Live NEC job, CE quotation | Impact on the Accepted Programme in force | Cl 62.2 / 63.3 (63.5) require it; nothing else is admissible |
| Post-completion, 26 monthly updates accepted, dispute at DAAB | Time slice windows (each window = one update period), corroborated by as-built | Uses the contemporaneous record; observational; hard to attack |
| Post-completion, updates missing or unreliable, good site diaries and IRs | As-planned vs as-built windows with an as-built built from records | Records choose the method; updates cannot be trusted |
| Employer arguing the contractor would have been late anyway | Collapsed as-built as a cross-check, if a linked as-built can be built honestly | Subtractive method tests the "but for" |
| Tender-stage or budget dispute with baseline only | Impacted as-planned, stated as theoretical | Only if nothing else is possible; disclose the limits |
5. Source validation before any method (29R-03 protocols, paraphrased): validate the baseline (logic, constraints, calendars, realism — the DCMA run); validate each update (data date, actuals against records, out-of-sequence); build or validate the as-built (actual dates from IRs, diaries, photographs, not from the last update alone). An analysis on an unvalidated base is the first thing the other side attacks.
6. Write the justification paragraph. Before running anything: contract clause governing method; timing (live/post); programmes available with their acceptance status; records available; method chosen; method rejected and why; what the method will and will not show (e.g. TIA shows likely delay, not actual). That paragraph goes at the front of the analysis section and stops the "why this method" argument before it starts.
📜 What the method does not decide
Excusability (is it the Employer's risk under the contract?), compensability (is Cost recoverable?), concurrency (was the Contractor also delaying the same period?), and mitigation are analysed after the schedule analysis produces the delay in days. 29R-03 keeps them separate for this reason; so does the Protocol. The planner's product is the delay in days on the relevant path, with the causal chain shown; the classification is the contracts manager's and the lawyer's. See Concurrent-delay for the three tests the planner does run.
🟥 Where people go wrong
- Method chosen by habit, not by the five factors. "We always do TIA" on a post-completion dispute with 30 accepted updates, producing a theoretical number the as-built contradicts. Answer the five questions first.
- Impacted as-planned presented as fact. A baseline with events inserted, ignoring everything that actually happened. It is the weakest method and every tribunal knows it. Use only when nothing else exists, and say so.
- TIA on the baseline. Impacting a two-year-old programme for an event last month. The base is the last accepted update; that is the whole point of "time impact".
- Windows chosen without validating the updates. Progress Override, moved data dates, unrealistic RDs in month 14 — the window analysis inherits every defect. Validate each update against records before it becomes a window boundary.
- Collapsed as-built on an as-built with no logic. The as-built was built by pasting actual dates onto the baseline; collapsing it collapses nothing. It needs a genuinely as-built network, which is weeks of work.
- Mixing methods mid-analysis. TIA for the Employer's events, as-planned vs as-built for the Contractor's. One method across the dispute, or two methods each applied to all events as a cross-check.
- Concurrency argued inside the method. The schedule analysis produces paths and days; whether concurrent delay reduces entitlement is a contract question. Keep the steps separate so the numbers survive the argument.
⚖️ When you're challenged
"Just run a TIA on the baseline. That's what the Engineer wants." A TIA impacts the schedule as it stood when the event happened — the last accepted update, which is Update 9. Impacting the baseline ignores nine months of actual progress and would give a number neither side could defend. The Engineer's own guidance, 52R-06 and the Protocol, both say the same.
"Why not as-planned vs as-built? It's cheaper." For this dispute we have 24 accepted updates and a Protocol-compliant record. Time slice windows use that record and are harder to attack than a gross as-planned vs as-built, which would ignore the updates the Engineer accepted. If the updates were missing, I'd agree with you.
"Which method gives us the most days?" Not a question I can answer without losing the claim. The method is chosen by contract, timing, records and forum, and the justification paragraph says why. A method chosen for its answer is the first thing the other side's expert will demonstrate.
"Can you do the concurrency analysis as part of the delay analysis?" The schedule analysis produces the delay on each path by period; the concurrency tests — critical, same period, independent — are run on that output and shown as float paths. Whether concurrency reduces the EOT or the money is a contract question for the contracts manager. Two steps, two documents.
📄 Related pages
- Time Impact Analysis — the prospective method, on the right base
- As-planned vs as-built and collapsed as-built — two of the retrospective methods
- Windows analysis — time slice and as-planned vs as-built windows in full
- Concurrent Delay — the three tests run on the analysis output
- Extension of Time Basics — where the method sits in the claim
- SCL Protocol summary — the Protocol's six methods and core principles
- How to review a schedule — source validation of baseline and updates
- Redirect: aace-29r-03-summary is absorbed into this page's taxonomy table
✏️ Worked example — Doha office tower, post-completion dispute, method selection memo
Position: Contract FIDIC 1999 Yellow, PCs silent on method; project complete 11 months late; 28 monthly updates, 26 accepted by the Engineer; as-built dates available from IR register and daily diaries; 14 Employer events (variations, late design approvals, utility) and 3 Contractor issues (façade subcontractor, MEP manpower); claim value large; forum DAAB then arbitration.
| Factor | Finding | Implication |
|---|---|---|
| Contract | No method named; Cl 8.4 / 20.1 apply; interim claims were made contemporaneously with TIAs on Updates 6, 11, 17 and 22 | Contemporaneous TIAs are evidence of the position at the time; the retrospective analysis must reconcile to them |
| Timing | Post-completion | Retrospective method |
| Records | 26 accepted updates, validated: same-day DD, Retained Logic, RD basis in Notebooks; two updates (14, 19) had Engineer's comments on RDs; as-built from IRs corroborates actual dates to ±2 days | Time slice windows viable; updates reliable enough to be window boundaries |
| Stake / time | Large; 12 weeks available | Full validation affordable |
| Forum | DAAB → arbitration | Observational, dynamic, transparent |
Method chosen: Time slice windows, 28 windows (one per update), critical path identified in each window from the accepted update, actual progress from the as-built; delay per window attributed to events by cause; contemporaneous TIAs reconciled window by window. Cross-check: collapsed as-built on the three largest events only, using an as-built network built from the IR register (disclosed as a cross-check, not the primary method). Rejected: impacted as-planned (ignores the record; weak at arbitration); gross as-planned vs as-built (discards 26 accepted updates).
Justification paragraph (as written in the report): "The Contract is silent on method. The analysis is retrospective. Twenty-six accepted monthly updates exist and have been validated against contemporaneous records (Appendix B). A time slice windows analysis is therefore adopted (SCL Protocol 2nd ed. method 3; AACE 29R-03 MIP 3.3), identifying the critical path in each window from the accepted update and measuring the delay to Section completion between successive data dates. Delay in each window is attributed to the events shown by the as-built records. The four contemporaneous time impact analyses submitted with interim claims are reconciled to the windows in Appendix D. A collapsed as-built cross-check is provided for events E-04, E-09 and E-12. An impacted as-planned analysis was not adopted because it would disregard the accepted record. Concurrency, excusability and compensability are addressed separately in Section 6."
Window extract:
| Window | DD from → to | Critical path (accepted update) | Movement of MS-230 (wd) | Attributed | Event ref |
|---|---|---|---|---|---|
| 9 | 25-Sep → 25-Oct (Y1) | Podium structure → transfer beams | −11 | Late IFC transfer beam drawings (Employer) −9; formwork crew shortage (Contractor) −2, non-critical path | E-04 |
| 14 | 25-Feb → 25-Mar (Y2) | MV switchgear → energisation | −18 | Utility drawing approval (Employer/authority) −18 | E-09 |
| 22 | 25-Oct → 25-Nov (Y2) | Façade L20–L32 | −9 | Façade subcontractor productivity (Contractor) −9 | C-02 |
Total attributed across 28 windows: Employer −168 wd, Contractor −41 wd, concurrent per the three tests −12 wd (shown as float paths in Section 6 for the lawyers to argue).
📖 References
- SCL Delay and Disruption Protocol, 2nd ed. (2017), Core Principle 4; Guidance Part B section 11 (check against your copy)
- AACE International RP 29R-03, Forensic Schedule Analysis (2011) — method implementation protocols 3.1–3.9, source validation protocols (check against your copy)
- AACE International RP 52R-06, Time Impact Analysis — As Applied in Construction
- ASCE/CI 67-17, Schedule Delay Analysis (check against your copy)
- FIDIC Conditions of Contract 1999, Cl 8.4, 20.1; 2017, Cl 8.5, 20.2 (check the edition in your contract)
- NEC3 / NEC4 ECC, Cl 62.2, 63.3 / 63.5 (check the edition in your contract)
General guidance, not legal advice. Contract wording, editions and amendments differ on every project. Read your own contract and take professional advice before relying on anything here in a claim or a dispute.
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about choosing a delay method. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.
Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.
Add your experience