FIDIC delay analysis, method by method.

Delay analysis is the technique used to identify the cause, effect and duration of delay to a project's completion. On FIDIC contracts it is the analytical spine of any Extension of Time claim — the way you demonstrate that a delay event actually delayed completion, and by how much.

Programme discipline comes first

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.

That means:

1. A baseline programme that stakeholders accept, with full logic and no undocumented constraints
2. Regular progress updates on strict data dates, with actualised durations
3. Actual progress recorded against every activity
4. A schedule narrative capturing progress commentary and any logic changes

The four main methods

1. 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 SCL Protocol identifies TIA as its preferred contemporaneous method in appropriate circumstances.

2. Windows Analysis

Windows Analysis is a retrospective method that breaks the project into time periods (windows) and analyses delay in each window. It is useful for long, complex projects where a single retrospective analysis over the whole period would obscure the sequence of events.

3. As-Planned vs As-Built

Compares the original programme against what actually happened. Simple to explain, but not always sufficient on its own for concurrent delay or complex sequences.

4. Collapsed As-Built (But For)

Removes delay events from the as-built to demonstrate what would have happened without them. Powerful in the right hands but methodologically demanding, and vulnerable to challenge if the removal is not done cleanly.

The SCL Protocol

The Society of Construction Law Delay and Disruption Protocol is the most widely-referenced framework in the industry. It sets out core principles for prevention and resolution of delay and disruption issues, and gives guidance on when each analysis method is appropriate.

The SCL Protocol is not binding — it is guidance — but tribunals and Engineers frequently reference it, and it has become a de facto industry standard for the methodological discussion.

Which method to use

The choice depends on:

• When the analysis is being done — prospective (during the event) or retrospective (after)
• What programme data survives — contemporaneous updates, or only end-state records
• The complexity of the events — single event, multiple events, concurrent delay
• The contract requirements — some contracts specify or prefer particular methods

For a live, in-flight claim with clean update data, TIA is often the strongest choice. For a retrospective analysis over a long project history, Windows or Collapsed As-Built approaches are more common.

Primavera P6 as the tool of choice

Primavera P6 is the industry standard for delay analysis on EPC and infrastructure projects, primarily because of its multi-project resource pool, robust baseline management, and audit-defensibility. MS Project has a place on smaller works but P6 is what the EPC industry expects.

How this actually integrates with a FIDIC workflow: FIDIC + Primavera P6.

The output

The final delay-analysis output is not a chart. It is an 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.