Primavera P6 for EOT Claims.

What EOT actually requires

Extension of Time is an extension of the Time for Completion granted to the Contractor for events for which the Employer bears responsibility under the contract. Every serious EOT submission has to demonstrate four things:

1. Cause — what event happened and when
2. Effect — how the event affected the critical path of the accepted baseline programme
3. Entitlement — which clause of the contract grants relief for this event
4. Quantum — how many days of extension are being claimed, and how that number was derived

The QS and contract engineer own cause and entitlement. The planner owns effect and quantum. That is where Primavera P6 does the work.

The EOT evidence pipeline

On any project run under FIDIC or similar contracts, the planner should treat every baseline and every update as evidence in waiting. The pipeline that produces a defensible EOT submission is:

1. Baseline programme captured before work starts and accepted by the Engineer in writing
2. Weekly or fortnightly progress updates on strict data dates, with actualised durations and retained logic applied consistently
3. Contract-required notices served on time (under FIDIC 1999 Sub-Clause 20.1: within 28 days of awareness; FIDIC 2017 restructures this under Sub-Clause 20.2)
4. Delay event modelled as a fragnet and inserted into the update immediately preceding the event
5. Time Impact Analysis re-runs the schedule with the fragnet in place; the delta on the completion milestone is the claimed extension
6. Evidence pack assembled — baseline export, update files, fragnet model, TIA output, layouts, narrative, cross-references
7. Submission to the Engineer with entitlement referenced against the relevant contract clauses

The planner's role in the pipeline

Planners rarely draft the notice or the final submission text. But the planner provides the data that makes the notice defensible and the analysis that makes the submission stand up. On any live claim:

• Identify the delay event in the update as soon as it appears, and flag it into the QS pipeline the same day
• Archive the update file (XER export) at each data date — do not overwrite; the historical progression is evidence
• Model the fragnet as soon as scope of the impact is understood, even before the submission is drafted
• Run the TIA and share the delta with the QS and PM before it is polished for external use
• Cross-check the schedule impact against site diaries, RFIs and correspondence so the narrative and the numbers reconcile

The evidence pack: what goes in

How Time Impact Analysis actually runs

The mechanics inside P6:

1. Open the schedule at the data date immediately before the delay event became known
2. Copy the project (File → Copy Project) so the analysis is on a separate copy that will not affect the live schedule
3. Insert the fragnet — new activities representing the delay event, with realistic durations and proper logic ties to affected activities
4. Run F9 (Schedule) with Retained Logic
5. Note the new Project Finish date
6. The number of days between the pre-fragnet Project Finish and the post-fragnet Project Finish is the impact of this delay event on completion
7. If the impact is zero, the event delayed non-critical work only — no EOT entitlement for that event on its own

FIDIC clauses to reference

Which clause supports the entitlement depends on the FIDIC edition and the nature of the event. Common references include:

• FIDIC 1999 Sub-Clause 20.1 — Contractor's claims (notice within 28 days)
• FIDIC 2017 Sub-Clause 20.2 — Contractor's claims for Extension of Time and/or additional Cost
• FIDIC 2017 Sub-Clause 8.4 — Advance Warning (positive duty to flag known events)
• FIDIC 1999 Sub-Clause 8.4 — Extension of Time for Completion (grounds for EOT)

The Particular Conditions of your specific contract can modify any of these. Always work from the signed document, not a general reference.

Common EOT-preparation mistakes

• Notice served late — the most common way EOT claims fail. Time-bars are strict.
• Baseline was never formally accepted — every impact measurement gets contested first on the baseline validity
• Silent logic changes between updates — unexplained logic modifications weaken the narrative
• Fragnet modelled without clear logic ties — the impact number looks arbitrary
• Cost claim confused with time claim — entitlement to time and money are separate; conflating them weakens both
• TIA run with progress override instead of retained logic — produces a smaller impact number that is contestable

The wider FIDIC picture

Every EOT submission sits inside a broader FIDIC claims workflow. For the contractual side of the picture:

• Extension of Time under FIDIC
• FIDIC Claims workflow
• FIDIC for Planning Engineers
• FIDIC + Primavera P6 integration
• EOT claims — the planner's field guide

FAQ