Primavera P6 Delay Analysis.

Delay analysis is programme discipline first

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

That means:

1. A baseline that was captured before work started and formally accepted
2. Regular progress updates on strict data dates, with actualised durations and retained logic consistently applied
3. Actual progress recorded against every activity, not just percent complete
4. A schedule narrative that captures logic changes and update decisions

Without those four, every method below is starting from a compromised base.

Method 1: Time Impact Analysis (TIA)

Prospective, contemporaneous. The SCL Delay and Disruption Protocol identifies TIA as its preferred contemporaneous method in appropriate circumstances.

The workflow in Primavera P6:

1. Identify the progress update immediately before the delay event became known (data date DD1)
2. In a copy of the schedule at DD1, model the delay event as a fragnet — a small network of activities reflecting the impact on site
3. Insert the fragnet into the schedule with proper logic ties to the affected activities
4. Run F9 (schedule) — the completion date will move
5. The difference between the pre-fragnet and post-fragnet completion dates is the impact of the delay event

TIA works best on live claims where the event is current or recent and the schedule data is contemporaneous. Its strength is that it is prospective — it asks "what will happen if we do nothing about this event", which is exactly the question a fair-minded Engineer wants answered.

Method 2: Windows Analysis

Retrospective, incremental. Breaks the project into time periods (windows) and analyses delay in each window.

The workflow:

1. Divide the project into contiguous windows — typically monthly, matching the progress-update rhythm
2. For each window, capture two baseline snapshots — one at window start (BL_n-1) and one at window end (BL_n)
3. Analyse what changed on the critical path within the window and attribute the change to specific events
4. Sum the window-by-window attributions to produce the overall delay picture

Windows Analysis is useful on long, complex projects where a single retrospective analysis over the whole period would obscure the sequence of events. It also lets you isolate periods of Contractor-caused delay from Employer-caused delay in a way TIA does not always show cleanly.

Method 3: As-Planned vs As-Built

Retrospective, comparative. Compares the original baseline programme against what actually happened.

The workflow:

1. Retain the original baseline (BL0) exactly as it was captured
2. Build an as-built schedule reflecting what actually happened — actual start / finish for every activity
3. Compare BL0 against the as-built, activity by activity, to identify slippage
4. Attribute slippage to specific events and parties

Simple to explain and often the starting point in a claim narrative. Its weakness is that it does not, on its own, deal well with concurrent delay — you need to layer another method on top when concurrency is contested.

Method 4: Collapsed As-Built (But For)

Retrospective, causation-focused. Removes delay events from the as-built to demonstrate what would have happened without them.

The workflow:

1. Start with the completed as-built schedule
2. Identify each delay event you are attributing to the Employer
3. Remove (collapse) each event from the as-built — delete the added activities, restore the original durations, un-do the logic changes
4. Re-schedule the collapsed as-built
5. The gap between actual completion and the collapsed completion is the Employer's delay contribution

Powerful in the right hands and often persuasive at determinations because it directly answers "but for these events, when would the project have finished?" Weakness: methodologically demanding and vulnerable to challenge if the collapses are not done cleanly.

Comparing the four methods

Concurrent delay

Concurrent delay — where two or more delay events (one Employer-caused, one Contractor-caused) occur in the same window and each would independently delay completion — is one of the most contested topics in delay analysis. Different approaches exist:

• Dominant cause — identify the dominant of the two causes and treat the delay as that cause
• SCL Protocol approach — the Contractor is entitled to time (typically not money) for the Employer-caused delay
• Apportionment — split the impact between the parties based on relative responsibility

The right approach depends on the contract, the jurisdiction and the facts. There is no universally correct answer; the point is to have a defensible one and document it clearly.

The SCL Delay and Disruption 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 claims, and gives guidance on when each analysis method is appropriate. It 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.

The delay-analysis output pack

The final output of any delay analysis is not a chart. It is an evidence pack:

• Baseline programme (original + any revised baselines used)
• Progress update files (XER exports at each relevant data date)
• Fragnet models for each delay event
• Layouts and filters used, exported to PDF
• Narrative walking through the method, the events, the cause-effect chain and the quantum
• Cross-references to correspondence, notices and site records

Assembled so a fresh reader — the Engineer, a Dispute Adjudication Board, an arbitrator — can follow the argument end to end without prior context.

Deeper reading

• Primavera P6 for EOT claims — the workflow that packages delay-analysis output into a submission
• FIDIC delay analysis (contract lens)
• Extension of Time under FIDIC
• Delay analysis educational guide

FAQ