A long delay report is not necessarily a strong Extension of Time claim.
The purpose of an EOT submission is to demonstrate a disciplined chain:
entitling event → contractual compliance → factual occurrence → effect on the programme → critical delay to completion → extension sought
If one link is missing, more pages rarely solve the problem.
1. Start with entitlement, not the schedule software
Before running a delay model, identify the contractual route to time.
For each event, answer:
- What obligation or risk event occurred?
- Which clause can provide an extension?
- What must the Contractor prove?
- Was notice required?
- Was notice compliant?
- Are there separate requirements for detailed particulars?
- Does the event provide time only, or time and Cost?
- Have Particular Conditions changed the standard position?
This prevents a common failure: proving that the project was delayed without proving that the contract allocates that delay to the other party or to an excusable risk.
2. Define the event precisely
“Late information” is not an event description.
A stronger definition would identify:
- the required information;
- contractual or planned need date;
- responsible party;
- actual issue date;
- work dependent on the information;
- relevant correspondence; and
- when the restriction ceased.
The claim should be capable of being broken into discrete events. Combining unrelated causes into a single “Employer delay” makes causation difficult to test.
3. Establish the contemporaneous programme position
The delay analysis should begin with the programme that reasonably represented the project at the time.
Collect and validate:
- accepted or approved baseline;
- subsequent accepted/approved updates;
- native schedule files;
- data date;
- calendars;
- logic;
- constraints;
- actual start/finish information;
- remaining durations;
- progress narratives;
- critical path;
- float;
- approved changes; and
- schedule quality issues.
Do not rely only on PDF printouts if the native programme exists. A forensic review may need the underlying logic and data.
The Society of Construction Law’s Delay and Disruption Protocol emphasises transparency of information and methodology. AACE RP 29R-03 likewise provides a structured technical reference for forensic CPM schedule analysis.
4. Prove impact on completion
The central question is not whether an activity was inconvenienced. It is whether and to what extent the event delayed contractual completion or the relevant Section/milestone.
That requires a credible cause-and-effect explanation:
Event A prevented Activity B from progressing from Date X to Date Y. Activity B was critical, or became critical, to the relevant completion path. After accounting for available float, actual progress, mitigation and other delay, the net effect on completion was Z days.
The analysis method should fit:
- the contract;
- project size and complexity;
- quality of programme records;
- whether the analysis is prospective or retrospective;
- timing of the assessment; and
- forum in which the result may later be tested.
No single delay-analysis method is automatically correct for every project.
5. Use the records to explain the programme
A schedule model without factual records is vulnerable.
Link key analysis periods to:
- daily reports;
- site diaries;
- photographs;
- inspection records;
- RFIs;
- design registers;
- access/handover records;
- meeting minutes;
- progress reports;
- labour and equipment records; and
- contemporaneous correspondence.
The records should show what actually prevented progress—not merely that the activity finished later than planned.
6. Address mitigation
Most claims are stronger when they explain what the Contractor did in response to the event.
Possible mitigation evidence includes:
- resequencing;
- alternative work fronts;
- temporary works;
- additional shifts;
- revised procurement;
- alternative design proposals;
- acceleration measures;
- reallocation of resources; and
- requests for decisions or access.
Mitigation does not mean accepting unlimited cost or risk. It means showing that the claimed delay is the net consequence after reasonable project response, not a passive accumulation of time.
7. Deal with concurrency directly
Ignoring a Contractor-caused delay does not remove it from the project record.
Identify other delays affecting the same completion path and period. Analyse whether they are truly concurrent under the contract and applicable legal framework.
A useful claim explains:
- what other delay existed;
- which activities it affected;
- whether it was independently critical;
- the relevant dates;
- how the analysis treated it; and
- whether it affects time and/or monetary entitlement.
Concurrency can have different consequences for EOT and prolongation cost. Do not collapse those questions into one.
8. Separate EOT from prolongation
An EOT claim answers how much additional time is contractually due.
A prolongation claim answers what additional time-related cost is recoverable because of compensable delay.
They are linked, but they are not the same.
A project can establish an extension for an excusable event without being entitled to recover all costs during the extended period. Conversely, a cost report cannot replace the schedule proof required for the EOT.
Keeping the two analyses distinct makes both clearer.
9. Structure the submission for the reviewer
A practical EOT claim can use the following architecture:
A. Executive summary
Event, clause, notice, EOT sought and short causal explanation.
B. Contractual basis
Relevant obligations, EOT provision, notices and procedural compliance.
C. Factual chronology
A dated, source-referenced account of the event.
D. Programme background
Baseline, updates, milestones and relevant critical path.
E. Delay analysis
Method, assumptions, event insertion/period analysis, results and treatment of float/concurrency.
F. Mitigation
Actions taken and effect.
G. EOT calculation
Clear calculation from analysis result to requested revised completion date.
H. Appendices
Programmes, notices, records, calculations and evidence index.
The reviewer should be able to move from a proposition in the narrative to the supporting record without hunting through an unindexed document dump.
10. Perform a final claim QA
Before issue, ask:
- Does every event have an entitlement route?
- Were all required notices issued?
- Do dates match across narrative, schedules and correspondence?
- Is the programme used in the analysis the correct contemporaneous programme?
- Does the analysis demonstrate delay to completion rather than only activity delay?
- Are mitigation and concurrency addressed?
- Does the requested EOT reconcile mathematically?
- Are all important assertions supported by a source?
- Is the revised completion date clear?
- Are time and money kept conceptually separate?
Strong EOT claims are built during the project
The most persuasive EOT claim is often the product of routine administration months before the submission is drafted.
A reliable programme, current progress data, formal notices, factual daily records and a live event register dramatically reduce the amount of forensic reconstruction required later.
That is the real discipline behind EOT preparation: build the evidence as the delay unfolds, then use the claim to explain what the project records already demonstrate.
REFERENCES & FURTHER READING