Two of the six methods described in the SCL Delay and Disruption Protocol look almost identical on a slide: take a programme, insert the delay event as a fragnet, recalculate, and read off the movement of the completion date. The similarity ends at the choice of programme.
Impacted As-Planned
The delay is inserted into the original baseline programme, the one approved at the start of the works, regardless of what had actually happened on site by the time the delay occurred. It is simple, quick, and needs only the baseline and a description of the event. Its weakness is the same as its strength: it ignores progress. If the contractor was already behind for its own reasons, or ahead, or had resequenced, the baseline no longer represents the project the delay hit. Engineers and tribunals tend to describe the result as theoretical for exactly that reason.
Time Impact Analysis
The delay is inserted into a contemporaneous programme update, the one current at the time the delay event occurred, reflecting actual progress to that date. The analysis then asks what the completion date would have been with and without the event, as seen from that point in time. The Protocol favours this approach for prospective analysis, meaning analysis carried out during the works, close to the event, when the fully detailed claim is being prepared.
| Impacted As-Planned | Time Impact Analysis | |
|---|---|---|
| Programme used | Original baseline | Updated programme at the time of the event |
| Accounts for actual progress | No | Yes, up to the event date |
| Data needed | Baseline, event fragnet | Baseline, regular updates, event fragnet |
| Typical timing | Retrospective, often when updates were not kept | Prospective, during the works |
| How Engineers tend to receive it | Sceptically, as theoretical | More readily, as contemporaneous |
| Effort | Low | Moderate; depends on update quality |
Which applies to your claim
The honest answer is: the one your records can support. A time impact analysis needs a programme update that was actually maintained and, ideally, accepted by the Engineer near the event date. If monthly updates exist and were submitted with progress reports, as they are on most Gulf and Indian infrastructure projects, TIA is usually the stronger choice for a claim made during the works. If updates were not kept, or the claim is being assembled long after the event, an impacted as-planned analysis may be all the data allows, and the claim should say so plainly rather than dress it up.
What the Engineer will test
- Was the programme used a real, submitted one, or reconstructed for the claim?
- Is the fragnet a fair model of the event, with realistic durations and logic?
- Were concurrent contractor delays in the same window addressed?
- Does the shift in completion actually run through the critical path, or through float?
What this means in practice
- Keep the monthly programme update current and submitted. It is the single asset that makes TIA available later.
- Name the method in the claim and explain why it fits the timing.
- Do not present an impacted as-planned result as if it reflected actual progress.
- Let your delay analyst choose and defend the method; the contracts team's job is to preserve the records that make the choice possible.
DraftMyEOT does not run the analysis. It keeps the register, the programme extracts, and the evidence organised so your analyst can, and its time impact section states the method you name rather than implying one.
Start a 48-hour draft →Sources
This article is general information about how these contract mechanisms typically work. It is not legal advice, and it is not a substitute for review of your specific contract by a qualified professional.