Delay Analysis, where FIDIC and Primavera P6 meet.

Delay Analysis is Programme Discipline

Every delay analysis method depends on programme discipline. A poorly constructed baseline, ragged updates or hidden logic will defeat even the most sophisticated technique. The first job is not choosing the method — it is having a defensible programme in the first place.

1. 1Baseline Schedule that stakeholders accept
2. 2Regular Progress Updates with clean data dates
3. 3Actual Progress recorded against every activity
4. 4Delay Event modelled and inserted
5. 5Schedule Impact quantified on the critical path
6. 6Delay Analysis method applied
7. 7EOT / Claim submission with evidence pack

Baseline schedules that survive scrutiny

A baseline built for reporting only will not stand up under a claim. A defensible baseline has full logic, realistic durations, no undocumented constraints, clear WBS, and calendar assumptions that match the contract. It is signed off by the parties before work begins.

Progress updates ' + $MDASH + ' the boring part that matters most

Weekly or fortnightly updates on strict data dates. Retained logic versus progress override, chosen consciously and applied consistently. Actualised durations, not just percent complete. Progress narrative captured in a separate log. This is the raw material of every future claim.

Modelling a delay event

The delay event is modelled as a fragnet — a small network of activities that reflects the impact on site. It is inserted into the programme at the correct data date (typically the update immediately before the event) with appropriate logic ties to the affected activities.

Critical path ' + $MDASH + ' the whole point

Delay to a non-critical activity does not, by itself, delay completion. The analysis has to show that the event affected the critical path or drove a non-critical path into criticality. Float ownership, near-critical activities, and multiple concurrent paths all complicate this — and are all covered in the course.

Time Impact Analysis (TIA)

TIA is a prospective, contemporaneous method: the analyst inserts the delay event into the programme as it becomes known, and re-runs the schedule to see the impact on completion. It is well-suited to live claims where the event is current or recent. The Society of Construction Law Protocol identifies TIA as its preferred contemporaneous method in appropriate circumstances.

Windows Analysis and As-Planned vs As-Built

Windows Analysis breaks the project into time periods (windows) and analyses delay in each. As-Planned vs As-Built compares the original programme against what actually happened. Collapsed As-Built removes delay events from the as-built to demonstrate what would have happened without them. Each method has strengths and weaknesses; the right choice depends on the data available and the claim context.

EOT and claims documentation

The final output is the evidence pack: baseline programme, update files, fragnet model, delay narrative, cause-effect chain, and the quantified EOT. It should be assembled so that a fresh reader — the Engineer, a Dispute Adjudication Board, an arbitrator — can follow the argument end to end without prior context.

This module connects directly to Extension of Time, FIDIC Claims and, most of all, to FIDIC for Planning Engineers — the module that puts the whole pipeline into daily practice.