Why the method matters to you
Two claims for the same delay can land on very different numbers depending on the method used. A method that compares your original plan to what happened needs a clear baseline programme. A method that models the delay event needs the event pinned to a date, a duration and the activities it hit. If your records can't feed the method, the days quietly disappear, even when the delay was real and you were entitled to time. That's why the records you keep on site should match how the claim will be analysed, not just describe what went wrong.
The main delay analysis methods, in plain English
These are the approaches you're most likely to run into. The names vary between contracts and countries, but the ideas are the same.
- As-planned vs as-built. Lay the original programme next to what actually happened and measure the difference. Simple to follow, but only as good as your baseline programme and your record of actual start and finish dates.
- Impacted as-planned. Drop the delay event into the original programme and see how far the end date moves. Quick and often used for early notices, but it ignores how the job was really tracking at the time.
- Time impact analysis (TIA). Take the programme as it stood just before the delay, model the event, and measure the push to completion. Widely accepted, but it needs an accurate, up-to-date programme and a clearly dated event.
- Windows analysis. Break the job into time windows and look at what drove the delay in each one. Thorough and hard to argue with, but it relies on regular, dated programme updates and good progress records throughout.
- Collapsed as-built (as-built but-for). Start from what actually happened and strip out the delay events to see what the finish would have been without them. Powerful in hindsight, but only works if your as-built record is detailed and reliable.
What every method needs from your site records
Whichever method gets used, the same handful of records decides whether it holds up. Keep these as the job runs, not from memory afterwards:
- A baseline programme, plus dated updates showing how it changed over time.
- Actual start and finish dates for the activities that were affected.
- The delay event pinned to a date, a cause and the specific work it hit.
- Day-by-day site records: a site diary and dedicated delay record, showing labour, plant and what was and wasn't possible each day.
- Supporting evidence such as photos, instructions and correspondence that ties the event to its effect on the programme.
The pattern across every method is the same: a clear programme, dated events, and progress records that connect the two. If you want the detail on what site teams should record before the claim is prepared, that's worth a read before your next notice goes in.
A quick checklist before your next EOT claim
- Do you have a baseline programme everyone agreed on at the start?
- Can you show the programme as it stood just before the delay hit?
- Is each delay event tied to a date, a cause and the activities it affected?
- Do your daily records back up how long the delay actually lasted?
- Have you notified in time and worked through a full EOT claim checklist?
You can't control which method someone uses to assess your claim. You can control whether your records are ready for any of them. Keep a clear programme, date your delay events, and log progress every day, then run your position through the EOT claim readiness checker before you submit.