FIDIC for Planning Engineers — the integration module.

Why this module exists

Most FIDIC courses teach the contract in isolation. Most Primavera P6 courses teach the tool in isolation. Neither prepares a planning engineer to actually operate the interface between the two — which is where every real EOT and delay claim lives.

This module closes that gap. It is built for planners who already know how to open Primavera P6, run an update and read a Gantt, and who now need to understand what the contract expects of them.

Contractual milestones ' + $MDASH + ' the ones that carry money

Not every milestone in your 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, and bonuses. Planners have to distinguish these from purely internal reporting milestones — and treat them accordingly in the baseline.

Baseline schedules the contract can defend

A baseline built for reporting alone will not survive an EOT claim two years later. Contract-defensible baselines have:

• Full logic (no dangling activities, no orphan critical path segments)
• Realistic durations tied to productivity or benchmarked crews
• Documented calendars that reflect the contract's working provisions
• Contractual milestones clearly identified in the WBS and codes
• Formal acceptance recorded in writing

Progress updates as contract evidence

Every 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 to know.

Delay events: seeing them first

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 show up in the update before they show up in a claim log. Recognising them as contractual events, and flagging them to the QS and PM, is the planner's highest-value function.

Contractual notices — the planner's prompt

The planner rarely drafts the notice. But the planner is the one who provides the data that makes the notice defensible — the affected activity IDs, the impact on the critical path, the fragnet of the event. A planner who understands FIDIC notice discipline pushes information into the QS pipeline in a form the QS can use immediately.

EOT and Time Impact Analysis in daily practice

TIA is not a specialist activity reserved for a claims consultant. On any project with a live claims environment, TIA should be a routine planner deliverable — run at each update, using the fragnet library built up over the project life. This module walks through the end-to-end mechanics inside Primavera P6.

Claims documentation the schedule owns

The claims pack draws on QS records, correspondence and site diaries — but the programme 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 tells a story; the programme evidence proves it.

Schedule evidence in a determination

When the Engineer determines a claim, the programme evidence is one of the first things scrutinised. Inconsistent updates, unexplained logic changes, missing baseline acceptance — each of these weakens the claim regardless of the underlying merits. Discipline in the schedule is discipline in the claim.

The link to Primavera P6

This module presumes working Primavera P6 knowledge. If you are new to the tool, take our Oracle Primavera P6 course first and return here with the fundamentals in place. If you are already comfortable in P6, this module is the highest-leverage upgrade you can add to your career.