An extension of time claim is usually decided before anyone opens a delay analysis. In my experience, it's decided by whether the programme was kept properly while the work was still live. Method choice matters, but it's the second question, not the first.
That's not the order most guidance implies. Most writing on forensic delay analysis, and there's a lot of it, spends its weight on choosing between Impacted As-Planned, Time Impact Analysis, Windows Analysis and Collapsed As-Built, under the SCL Delay and Disruption Protocol (2nd edition, February 2017) and AACE International's Recommended Practice 29R-03, Forensic Schedule Analysis. That material is genuinely useful. But it treats method selection as the thing that wins or loses the claim, when in most disputes I've seen, the method was never really in question. What decided the outcome was whether there was anything reliable to run the method against.
What "Properly Kept" Actually Means
A programme that's genuinely useful in a later dispute isn't the one with the prettiest bar chart. It's the one updated on a fixed cycle, logic-linked rather than constrained into shape, baselined and re-baselined with the reasons recorded, and tied to dated correspondence explaining why each update looks the way it does. None of that is glamorous. All of it is what turns "we think this event caused the delay" into "here is the accepted programme update immediately before the event, and here is what changed after it."
NEC4 contracts already build a version of this into the contract mechanics, whether or not anyone thinks of it as claims preparation. The Early Warning Register exists to capture emerging risk in real time under Clause 15, and compensation events are assessed against the Accepted Programme under Clause 63 (our NEC4 programme requirements guide covers the acceptance mechanics in full). Run those two mechanisms properly, on time, every month, and you've built most of the evidential record a forensic analysis needs without ever setting out to build one. Ignore them until a dispute is live, and you're reconstructing that record from memory and email searches, against a party with every incentive to dispute your version of events.
This gets more relevant, not less, as more first-draft programmes arrive AI-assisted rather than built activity by activity by a planner. An AI-generated programme can clear a DCMA-style structural check and still carry exactly the gaps a rushed human one would: constraints standing in for logic, updates that aren't really updates. I've written elsewhere about who's actually checking that work. But that's a separate question from this one. Whoever or whatever built the programme, the discipline of maintaining it monthly and honestly is what a dispute will actually test.
Where the Concession Has to Go
None of this means method doesn't matter, and I don't want to overstate the case. AACE RP 29R-03 exists precisely because the wrong method, applied to the right facts, can produce a number nobody can defend. Windows Analysis genuinely handles concurrent delay more transparently than a global Impacted As-Planned comparison. Time Impact Analysis genuinely needs a contemporaneous, accepted programme update to sit against, and using the wrong one, or misapplying the technique to records that don't support it, can turn a strong factual position into a weak claim. Method selection is a real skill, and getting it wrong is a real way to lose.
And no quality of record survives a missed procedural step. Under FIDIC's Red Book, both the 1999 (Sub-Clause 20.1) and 2017 (Sub-Clause 20.2) editions treat the 28 day notice period as a condition precedent. Miss it, and the entitlement to time can be lost regardless of how good the programme behind it is. Good records are necessary. They were never going to be sufficient on their own.
Why I Still Think Records Come First
Here's the distinction I'd draw. Method and procedure decide whether a good claim survives contact with the contract and the tribunal. Records decide whether there's a good claim to defend in the first place. You can coach a weak method into a stronger one, or bring in someone who knows AACE's nine Method Implementation Protocols cold. You can rarely coach a missing baseline back into existence, or make a programme that was never logic-linked retrospectively honest. One of these problems is fixable after the fact. The other usually isn't.
That's why, when someone asks where to put limited time and budget for claims readiness, my answer is rarely "get a better forensic analyst on retainer." It's "get the monthly update discipline right, now, on every live project, whether or not a claim looks likely yet." A programme that would pass a basic structural check today is a programme that will still be defensible in eighteen months, when nobody quite remembers why an activity moved. Waiting until a dispute is visible is waiting until the record you needed was already being written badly.
What This Looks Like in Practice
None of this is exotic. It's monthly updates that actually happen on the date they're meant to, not batched up and reconstructed at month end. It's baselines that get formally reset with a documented reason, not silently overwritten. It's early warnings and compensation event notices raised against dated events, not folded into the next progress meeting because it felt easier. None of it requires guessing in advance which project will end up in dispute, because you don't get to choose that. You only get to choose whether the programme was ready if it does.
Book a Free Consultation if a live or approaching dispute has you looking at delay analysis and you want a straight read on where the position actually stands. Our Delay and EOT Position Review is built for exactly that: a candid assessment before you commit to a full claim, not after.