Delay & EOT

Extension of Time Claims: The Schedule Evidence a Contractor Needs

An EOT claim succeeds or fails on its evidence long before anyone argues about method. This guide sets out the notices, programmes and records a contractor should have in hand, and how analysis methods in the SCL Protocol and AACE RP 29R-03 depend on them.

General information only, not legal advice. Entitlement to an extension of time depends on your contract, the governing law and the facts. Read the actual clauses (and verify any wording quoted from secondary commentary in this article against the primary text) and take legal advice before relying on any of it.

Extension of time (EOT) disputes are usually won or lost on records. By the time a delay analysis method is debated, the question that matters is simpler: can the contractor show what the plan was, what happened, when the employer or the contract was told, and how the event moved the completion date?

This article sets out the schedule and record evidence a contractor typically needs, how the notice mechanism in FIDIC 2017 sits on top of it, and how the two best-known references on delay analysis, the SCL Delay and Disruption Protocol and AACE RP 29R-03, make use of it.

1. Start with the contract, not the software

Before opening a schedule, extract from the contract:

  • the time-related clauses: date for completion, grounds for EOT, notice requirements and any time bars;
  • the programme clauses: what programme must be submitted, who must accept it, how often it must be updated and in what format (native file, float ownership, resource loading);
  • the records clauses: what daily or monthly records the contractor is obliged to keep;
  • any specified delay analysis method.

Commentary on FIDIC 2017 notes that the contractor must show an actual delay to completion, on the critical path. The contract wording decides what that means in practice.

2. The notice trail

Notice provisions are procedural but decisive. Under the FIDIC 2017 Red Book, as described by Fenwick Elliott and CMS:

  • A Notice of Claim is due as soon as practicable and no later than 28 days after the claimant became, or should have become, aware of the event. Failure can discharge the other party from liability for the matter.
  • If the Engineer considers a notice late, it must say so with reasons within 14 days, failing which the notice is treated as valid. A deemed-valid notice can still be disputed by the other party.
  • A fully detailed claim is due within 84 days (or another agreed period). It must include a detailed description of the event, the contractual or legal basis, the contemporary records relied on and detailed particulars of the time claimed.
  • For events with continuing effect, the commentary describes interim fully detailed claims, monthly updates and a final claim within 28 days of the effects ending.
  • The Engineer must then agree or determine the claim under Sub-Clause 3.7, including whether the notice was valid.

FIDIC 2017 also introduces an early-warning duty (Sub-Clause 8.4), and Sub-Clause 8.5 sets out the grounds for an extension, including employer-caused delay, variations and listed causes. On concurrent delay, commentary notes that 8.5 has no express rule, and refers the parties to Special Provisions or to a decision "as appropriate taking due regard to all relevant circumstances".

The clause numbers and periods above come from law-firm commentary, not from the FIDIC text itself, which is a paid publication that I have not reviewed. Verify against your actual contract and Particular Conditions, which frequently amend them. Whether a time bar can be avoided also depends on the governing law.

3. The programme evidence

Delay analysis measures change against a reference. If the reference is unreliable, so is the analysis. AACE RP 29R-03 treats this explicitly through its Source Validation Protocols: baseline selection and validation, as-built schedule sources, update validation, and identification of delay events. A practical checklist:

Baseline (as-planned)

  • Accepted or approved baseline in native format, with the date and the correspondence that accepted it.
  • Evidence it is a credible plan: logic and calendars that match the contract (a schedule health check is the quickest way to find out before a dispute starts).
  • Rejected or superseded versions, and why.

Updates

  • Every submitted update in native format with its data date, in sequence.
  • The settings used (retained logic or progress override), because they change the critical path.
  • A record of logic or duration changes made between updates. AACE guidance points to separating pure progress from logic revisions where updates have been altered.

As-built

  • Actual start and finish dates tied to source documents, not just to the schedule.
  • AACE guidance is that where as-built documentation exists, it is the primary source for factual analysis, and that contemporaneous daily reports and inspection records are the best source for as-built data.

Gaps

  • Missing updates, late updates or recreated updates. AACE has a specific method category (MIP 3.5) for situations where contemporaneous updates are missing or heavily modified and have to be recreated. That is more assumption-heavy than analysis using unaltered updates.

4. The records that connect events to delay

A programme tells you what the plan was. Records tell you what happened and who knew. Typical record types, in the order they are usually needed:

  1. Notices, early warnings and the Engineer's responses.
  2. Instructions, variations, RFIs and drawing-issue registers (with dates of issue against dates required).
  3. Daily site diaries, labour and plant returns, weather logs and progress photographs.
  4. Meeting minutes and progress reports.
  5. Material delivery and approval records for long-lead items.
  6. Third-party interface records and contemporaneous correspondence.

The SCL Protocol's Core Principle 1 encourages the parties to agree the types of records to be kept and to allocate resources to keeping them, and its Core Principle 4 warns against a "wait and see" approach: time impacts should be dealt with as the work proceeds, and applications made close in time to the event.

5. Choosing an analysis method

The SCL Protocol (2nd edition) no longer expresses a single preferred method for after-the-event analysis; instead it lists factors including the contract terms, the nature of the events, the claim or dispute, project value, time available, available records and proportionality. It also stresses an overriding objective that conclusions be "sound from a common sense perspective", and that the critical path is often best established from production and resource data, not software output alone.

AACE RP 29R-03 organises methods by the way they use schedules. The headline categories, as listed in the 2011 revision, are:

AACE MIPApproachTypically used when
3.1 / 3.2Observational, static: as-built compared with as-planned (whole project or in periods)Limited records; simple projects
3.3 / 3.4Observational, dynamic, contemporaneous: compares successive updates (as-is, or split progress from logic changes)Good, unaltered updates exist
3.5Observational, modified or recreated updatesUpdates missing or heavily modified
3.6 / 3.7Modelled, additive: insert delays into a base schedule (single or multiple base, e.g. impacted as-planned or windows-type)Events can be modelled clearly
3.8 / 3.9Modelled, subtractive: remove delays from an as-built simulation (e.g. collapsed as-built)Strong as-built data

The mapping of well-known names (windows, time impact analysis, collapsed as-built) to MIP numbers is described slightly inconsistently within the 2011 document, so cite the RP directly.

Practical rule: the better the contemporaneous updates, the less a method has to assume. The worse the records, the more assumptions, and the more scrutiny they will get.

6. Concurrency and float

Two points frequently decide the outcome:

  • Concurrent delay. The SCL Protocol (2nd edition) defines true concurrent delay as two delay events occurring at the same time, one an employer risk event and one a contractor risk event, with both affecting the critical path. It states that contractor delay occurring concurrently with employer delay should not reduce any EOT due. Some contracts and governing laws treat concurrency differently, so check yours.
  • Float. Who owns float, and whether it is consumed by prior contractor delay, depends on the contract. If a contractor delay already pushed completion out, a later employer event may not have changed the completion date at all.

7. Worked example

Illustrative example, not a real project. Every date, duration and event below is invented. It shows how the evidence chain is assembled, not how any real claim was decided, and is not a statement about entitlement.

A contractor on a hypothetical fit-out has a baseline completion of 30 June. In March, drawing revision C for a mechanical riser is issued three weeks after the date the programme required. The contractor wants to assess the effect on completion.

Evidence assembled:

ItemEvidencePurpose
ContractNotice clause; EOT clause; programme clauseDefine what must be proved and by when
NoticeNotice sent two days after revision C was received; Engineer's acknowledgementCompliance with the notice period
BaselineAccepted baseline, native file, plus acceptance emailReference for as-planned
UpdateFebruary and March updates, native files, same settingsShow the riser activity position before and after
RecordsDrawing register (date required v date issued), RFI log, site diary showing riser crew standing timeLink the event to actual disruption
AnalysisWindows-type analysis over March and April updatesTest whether the event moved the critical path

Findings in this hypothetical: the riser activity was on a near-critical path with 10 days of float; revision C consumed that float and then delayed one successor by 11 days; but a separate, earlier contractor-side delay on ceiling-grid work had already pushed the forecast completion 6 days beyond baseline. The analysis would therefore need to separate the periods and identify what, if anything, was driving completion in each window. Without the update chain, the daily diaries and the drawing register, none of that separation could be shown.

8. A contractor's EOT evidence checklist

  • [ ] Contract time, programme and records clauses extracted and summarised
  • [ ] Notice of Claim issued within the stated period, with proof of delivery
  • [ ] Fully detailed claim timetable diarised, with continuing-effect updates if applicable
  • [ ] Accepted baseline and every update in native format, in sequence, with data dates
  • [ ] Scheduling settings recorded for each update
  • [ ] Event register: each event, its date, its cause and the contractual ground relied on
  • [ ] Records index linking each event to drawings, instructions, diaries and correspondence
  • [ ] Critical path established from both the schedule and the production and resource data
  • [ ] Concurrency, float use and mitigation considered and documented
  • [ ] Method chosen with reasons, and assumptions listed
  • [ ] Independent technical review before the claim goes out

Where RAYYAF fits

RAYYAF's Delay and EOT Consultancy offer supports contractors and consultants with a delay event register and chronology, review of baseline and updated programmes, time impact or windows analysis as suited to the records, an evidence index and a draft technical report for your commercial team. It excludes legal advice, entitlement opinions, expert witness appearances and any guarantee of outcome. If you want to keep programmes and updates dispute-ready as the project runs, see Monthly Outsourced Planning Support.

About the author

Mohd Faisal Afatab is Founder and Principal Consultant of RAYYAF, with 14+ years in construction planning and project controls. His earlier roles include planning management on international PMC assignments where his work covered baseline schedules, critical path analysis, recovery programmes, delay assessments and EOT support in Primavera P6 and MS Project. These are experiences from previous employment, not RAYYAF client engagements.

Sources

Verification note: the SCL Protocol and AACE RP 29R-03 are described here from a law-firm article and from the 2011 revision of the RP respectively. The FIDIC clause content is taken from commentary. Check each against the current primary text before relying on it.

Frequently asked questions

What is the most common reason an EOT claim is weak?

Missing or late contemporaneous evidence: no timely notice, no accepted or updated programme to measure against, and no site records that tie the event to the work it actually delayed. Method choice matters, but it cannot repair absent records.

Which delay analysis method is best?

The SCL Protocol (2nd edition) does not prefer a single method for after-the-event analysis. It lists factors for choosing, including the contract terms, the nature of the events, the available records, value and proportionality. The method has to fit the records you actually have.

Does a late notice always defeat a claim?

It depends on the contract and the governing law. Under FIDIC 2017 commentary, failure to give notice within the stated period can discharge the other party from liability, but there are procedural steps, and the position can vary with the governing law. Take advice on your specific contract.

Can RAYYAF guarantee that a claim will be granted?

No. Entitlement and outcome depend on the contract, the evidence and the decision-maker. RAYYAF supports the technical analysis and documentation and does not provide legal advice or entitlement opinions.

Sources

  1. Fenwick Elliott: The SCL Delay and Disruption Protocol, a second edition
  2. AACE International RP 29R-03, Forensic Schedule Analysis (2011 revision, as hosted by Planning Planet)
  3. Fenwick Elliott: Changes to the Claims provisions in the 2017 FIDIC Red Book
  4. Gowling WLG: FIDIC claims for time (2024)
  5. CMS: New FIDIC Second Editions, revamped claims and dispute resolution provisions
  6. 39 Essex Chambers (P. Atkinson), FIDIC 2017 overview, IPBA Manila

More from Insights