FIDIC + P6 · 11 min read · GSTPM differentiator

FIDIC and Primavera P6, where they actually meet.

Most FIDIC training treats the contract in isolation. Most Primavera P6 training treats the tool in isolation. Every real EOT and delay claim lives at the interface. This is that interface, mapped out.

Ask any planning engineer who has served an EOT notice under FIDIC where the gap lies in the industry, and the answer is usually the same: nobody teaches how the contract and the tool connect. Contract training is delivered by lawyers who don't open Primavera P6. P6 training is delivered by tool specialists who don't read FIDIC. The people who actually have to run the interface — planners, project controls engineers, quantity surveyors — are left to figure it out in the middle of a live claim.

This article maps the interface. It follows the flow from a FIDIC contractual event to a defensible EOT claim, showing where Primavera P6 is doing the heavy lifting at each step.

The flow, end to end

Every EOT claim on a FIDIC contract follows the same shape:

  1. FIDIC contract defines the risk allocation and claim procedure
  2. Contractual event occurs on site (Variation, late instruction, changed conditions)
  3. Delay event arises from the contractual event
  4. Project schedule in Primavera P6 captures the current state of the programme
  5. Schedule impact is modelled inside P6 as a fragnet or logic change
  6. Delay analysis quantifies the impact on the critical path
  7. EOT / claim submission assembles the schedule evidence into the QS pack

Miss any of these steps and the claim weakens. Miss the P6-side ones and the claim has no defensible evidence base.

Contractual milestones — the ones that carry money

Not every milestone in the programme has contractual weight. The Time for Completion, any Sectional Completions, and Milestones specifically identified in the contract are the ones that trigger payment, liquidated damages, or bonuses. Planners must distinguish these from purely internal reporting milestones and treat them accordingly in the P6 baseline.

In practice: use activity codes to flag contractual milestones separately in P6, use the WBS to group them under a “Contractual Milestones” branch, and lock them behind milestone activities so they cannot be accidentally modified in the update workflow.

Baseline schedules the contract can defend

A baseline programme built for reporting alone will not survive an EOT claim two years later. A contract-defensible baseline has:

  • Full logic — no dangling activities, no orphan critical-path segments
  • Realistic durations tied to productivity or benchmarked crews
  • Documented calendars reflecting the contract's working provisions
  • Contractual milestones clearly identified in the WBS and activity codes
  • Formal acceptance by the Engineer recorded in writing

The last point is where many claims later come unstuck. If the baseline was never formally accepted, arguments about entitlement to Extension of Time have to first cover an argument about which baseline applies.

Progress updates as contractual evidence

Every P6 update is a contractual record. Data dates, retained-logic vs progress-override decisions, and actualised durations should be applied consistently and captured in an update log alongside the schedule narrative. Under FIDIC 2017, the Advance Warning obligation places positive duties on the Contractor to flag events likely to affect performance — the planner is often the first person to notice.

Delay events — recognising them in the update

Planners routinely see delay events before anyone else on the project. Slipped completion of a predecessor, a productivity crash on a critical trade, a late Employer instruction — all of them appear in the P6 update before they appear in a claim log. The planner who recognises a delay event as a contractual event, and flags it into the QS pipeline immediately, provides the QS with days of head-start on the notice window.

Modelling a delay event — the fragnet approach

The delay event is modelled as a fragnet — a small network of activities reflecting the impact on site — and inserted into the programme at the correct data date (typically the update immediately before the event) with appropriate logic ties to the affected activities. Time Impact Analysis then re-runs the schedule with the fragnet in place.

Schedule evidence for the claim pack

When the claim is submitted, the schedule evidence is the planner's deliverable. Baseline exports, update files, fragnet screenshots, and a properly-configured layout that visualises the delay impact. Everything else in the pack — the narrative, the QS records, the correspondence — tells a story; the schedule evidence proves it.

Why P6, not MS Project

Primavera P6 dominates FIDIC-based delay analysis for three reasons: multi-project resource pool (essential on capital projects), baseline management (up to 50 baselines per project), and audit defensibility. MS Project has its place on smaller works but P6 is what the EPC industry expects when the claim gets serious.

The planner's role in the claim

The planner rarely drafts the notice or the submission itself. But the planner provides the data that makes the notice defensible, and the analysis that makes the submission stand up. A planner with a working understanding of FIDIC and disciplined P6 practice is the single most valuable asset on any FIDIC-based project when claims start.

Related GSTPM course
The integration module that most training skips.

The GSTPM FIDIC Contract Management course centres this integration — every claim topic is tied back to a Primavera P6 workflow.