Delay Analysis Report: How to Write, Structure and Review Construction Delay Reports

A delay analysis report is the document that turns schedule analysis into evidence. Get the analysis right but the report wrong, and a tribunal may dismiss your findings before reading them. Get both right, and the same analysis carries weight it could never achieve in a poorly structured document.

The difference between a report that persuades and one that doesn’t isn’t the analysis itself. It’s whether the methodology is transparent, the assumptions are stated, the evidence is contemporaneous, and the conclusions follow from the data. These aren’t subjective preferences. They’re requirements set out in the SCL Protocol and AACE International’s Recommended Practice 29R-03.

This guide covers how to write, structure, and review a delay analysis report. It is not a guide to performing delay analysis; for that, see our guide to forensic schedule analysis. It is not a guide to making an extension of time claim; for that, see our EOT claim analysis. This guide is about the deliverable: the report itself.

What we found: The SCL Protocol §11.3 lists eight criteria that should drive method selection (records available, programme information, forum, project value, time available, contract conditions, nature of causative events, nature of the project). Reports that don’t surface how their chosen method was tested against these criteria leave the tribunal no way to assess whether the analysis is fit for purpose.

What it means: Methodology disclosure isn’t a stylistic choice. It’s the precondition for a tribunal taking the analysis seriously. A report that names a method without showing the selection logic asks the reader to take the analyst’s judgement on trust.

What Is a Delay Analysis Report?

A delay analysis report is a structured analytical document that identifies, quantifies, and attributes schedule delays to specific events, parties, and time periods. Its purpose in disputes is to establish three things: causation (what caused the delay), liability (who is responsible), and time entitlement (what extension of time or compensation is due).

A delay analysis report is not:

A schedule review. A schedule review assesses quality. A delay analysis report draws analytical conclusions from schedules.
An EOT claim. An EOT claim is a contractual submission. A delay analysis report is the evidence supporting or challenging that submission.
A progress report. Progress reports describe what happened. A delay analysis report explains why it happened and what the consequences are.

Why a Well-Structured Report Matters

Tribunals and courts assess delay analysis reports on credibility as much as on correctness. A report with sound analysis but poor documentation can lose a meritorious claim. A report with reasonable analysis and rigorous documentation can carry disproportionate weight.

Three structural failures undermine more reports than any analytical error:

Missing methodology transparency. If the tribunal can’t understand what you did, they can’t verify it. If they can’t verify it, they won’t rely on it.
Unstated assumptions. Every analysis rests on assumptions. Hiding them doesn’t make them go away; it makes them a target for the opposing expert.
Unsupported conclusions. A conclusion without the analytical path that leads to it is an assertion. Assertions aren’t evidence.

The cost of a poor report extends well beyond the report itself: lost credibility, adverse cost orders, and in some jurisdictions, the expert being excluded from giving evidence entirely. In England and Wales, Part 35 of the Civil Procedure Rules restricts admissible expert evidence to what is reasonably required and gives the court power to control how expert opinions are presented and tested. Walter Lilly v Mackay [2012] EWHC 1773 (TCC) is the leading modern English case on global claims; Akenhead J’s detailed scrutiny of the delay expert’s methodology in that case is a useful reference for the level of structural rigour the courts now expect.

Recommended Report Structure: The 12-Section Template

Every delay analysis report should follow a consistent structure. This 12-section template covers what tribunals expect and what the SCL Protocol and AACE 29R-03 require.

graph TD A[1. Executive\nSummary] --> B[2. Introduction\nand Instructions] B --> C[3. Project\nBackground] C --> D[4. Documents\nand Data Reviewed] D --> E[5. Schedule\nDescription and\nAssessment] E --> F[6. Methodology] F --> G[7. Factual\nNarrative] G --> H[8. Analysis\nand Findings] H --> I[9. Conclusions] I --> J[10. Assumptions\nand Limitations] J --> K[11. Appendices\nand Demonstratives] K --> L[12. Expert\nDeclaration]

Section 1: Executive summary

The executive summary should be 1-2 pages maximum. State the key findings in plain language:

Total delay identified (in calendar days or working days, specified which)
Critical path impact
Time entitlement (if any) attributed to each party
The methodology applied

Cross-reference the detailed sections so the reader can verify any summary point. The executive summary is not the place for new information; everything in it must appear in the body of the report.

Section 2: Introduction and instructions

State clearly:

Who instructed you and when
The scope of the analysis: what was included and, importantly, what was not included
The specific questions the report addresses
Any limitations on the analysis (time constraints, data availability, scope restrictions)

This section sets the boundary of the report. Anything outside the stated scope is not covered by your opinion, and the reader needs to know that.

Section 3: Project background

Provide the factual context:

Contract type and key terms (lump sum, design and build, cost-plus)
Project scope and value
Key dates: contract execution, commencement, contractual completion, actual completion, any extension of time granted
Parties, roles, and contractual relationships
Relevant contractual provisions (liquidated damages, force majeure, change clause)

For the claim process that sits alongside this factual background, see our guide to the extension of time claim process.

Section 4: Documents and data reviewed

List every document you examined. This section is critical for transparency and for the opposing party’s ability to challenge your data foundation.

Include:

Schedule data: baseline programme, periodic updates, revised programmes
Correspondence: project letters, emails, site instructions, variation notices
Progress reports and meeting minutes
Weather data
Change orders, variation orders, and compensation events

Also state what was NOT available and how that limitation affects the analysis. Missing data is not a weakness in the report if you acknowledge it; it is a weakness if the opposing expert discovers it first.

For the specific challenges of working with P6 schedule data, see our guide to XER file analysis.

Section 5: Schedule description and assessment

Describe the schedule(s) you analysed and assess whether they are fit for delay analysis.

Essential details:

Which schedule versions were used and why
Activity count, critical path identification, float distribution
Schedule quality assessment (such as a DCMA 14-Point Assessment)
Whether the schedule is logic-driven or contains hard constraints, manually-scheduled tasks, or open ends
Assessment of whether the schedule is sufficiently reliable for delay analysis

Do not skip the quality assessment. Analysing delays in a schedule with broken logic produces unreliable results, and the opposing expert will identify this. For the baseline review process, see our guide to baseline schedule review.

Section 6: Methodology

This is where most reports fall short. Naming a method is not the same as explaining it.

What to include:

Which delay analysis method was applied (for example, time impact analysis, as-built but-for, windows analysis, impacted as-planned)
The AACE 29R-03 MIP designation. AACE 29R-03 defines 9 MIPs (Methodology Implementation Protocols). Name the specific MIP applied.
Why this method is appropriate for this dispute
Whether the analysis is prospective (forward-looking from the delay event) or retrospective (looking back from the as-built)
Acknowledgement of the limitations of the chosen method

For the detailed methodology behind the most commonly used approach, see our guide to time impact analysis.

Section 7: Factual narrative

Present a chronological account of the delay events based on contemporaneous project records. This section is the evidence foundation for the entire analysis. For the broader discipline of construction schedule analysis, the factual narrative is where abstract methodology meets concrete project reality.

For each delay event:

What happened
When it occurred
Who was responsible (based on the contractual and factual record)
What contemporaneous documents support the account

Differentiate clearly between delay events (which affect the critical path) and disruption or pace issues (which affect productivity). Not every problem is a delay, and this distinction matters for causation.

Section 8: Analysis and findings

This is the core analytical section. For each delay event, show:

The schedule before the delay event (the “before” position)
The delay event inserted into the schedule
The recalculated schedule after the event (the “after” position)
The difference: the impact on the critical path and completion date

This linkage, from event to schedule impact to critical path to completion date, is the causation chain. If you can’t show it, the conclusion is an assertion.

For concurrent delays: identify where two or more delay events affect the critical path in the same window and explain how they were treated. See our guide to concurrent delay for the analytical approach.

Present findings in a table:

Window	Delay Event	Responsible Party	Days Impact on Critical Path	Concurrency?
Window 1	Design changes	Employer	28	No
Window 2	Late access	Employer	14	Yes (with contractor delay of 21 days)
Window 3	Weather event	Neutral	7	No

Section 9: Conclusions

State clear conclusions that answer the questions posed in the introduction:

Total delay attributable to each party
Net time entitlement (extension of time or acceleration)
Any qualifying comments on confidence levels
Caveats on conclusions that depend on assumptions

Conclusions must follow from the analysis. If a conclusion appears for the first time in this section without analytical support earlier in the report, it will be challenged.

Section 10: Assumptions and limitations

List every assumption explicitly:

Assumptions about schedule logic where the programme was incomplete
Assumptions about productivity rates where actuals were unavailable
Assumptions about concurrent events and their interaction
Sensitivity of conclusions to each assumption

The test is: if the assumption changes, does the conclusion change? If the answer is yes, state that. This section is not a weakness. It demonstrates rigour.

For risk-aware approaches to assumption sensitivity, see our guide to schedule risk analysis.

Section 11: Appendices and demonstratives

Include:

Schedule extracts and Gantt chart extracts showing before/after positions
Critical path identification for each analysis window
Windows analysis tables
Network logic diagrams
Chronology of delay events
Key correspondence extracts
Weather data summaries

Best practice for demonstratives:

Label every exhibit with a reference number
Use consistent formatting across all extracts
Include legends and axis labels on every chart
Ensure every figure and table is referenced in the body text

Section 12: Expert declaration

Include:

Statement of independence
Compliance with the relevant jurisdiction’s expert requirements
SCL Protocol compliance statement (where applicable)
Qualifications and experience

In England and Wales, this means compliance with Part 35 of the Civil Procedure Rules and the associated Practice Direction. In the United States, this means addressing the admissibility requirements under Daubert (or the relevant state standard).

SCL Protocol Requirements for Delay Analysis Reports

The SCL Delay and Disruption Protocol sets out requirements that directly affect report structure and content.

Key requirements:

Methodology selection on stated criteria. SCL Protocol §11.3 sets out eight criteria the choice of delay analysis method “should be determined by reference to”: the relevant conditions of contract, the nature of the causative events, the nature of the project, the value of the project or dispute, the time available, the nature, extent and quality of the records available, the nature, extent and quality of the programme information available, and the forum in which the assessment is being made. A report that names a method without showing how it was tested against these criteria gives the tribunal no basis to assess whether the method fits the dispute.
Common-sense check on conclusions. SCL Protocol §11.2 states: “Irrespective of which method of delay analysis is deployed, there is an overriding objective of ensuring that the conclusions derived from that analysis are sound from a common sense perspective.” Conclusions that survive the analytical method but fail this test (e.g. a calculated delay that doesn’t match the project’s actual progress trajectory) need to be re-examined, not buried.
Contemporaneous records as the evidence foundation. SCL Protocol §1.7 states: “Records relevant to progress and delay and disruption events must be generated contemporaneously as the works progress, and not afterwards.” A report built on reconstructed records is structurally weaker than one built on records made at the time.
Independence and no advocacy. The SCL Protocol requires experts to give independent opinions regardless of who instructed them, and to present findings rather than argue a case. The distinction between expert opinion and advocacy is the distinction between being useful to the tribunal and being excluded from it.

Common compliance failures in delay analysis reports:

Naming a methodology without explaining how it was applied
Using data that was not contemporaneous without acknowledging the limitation
Drawing conclusions that go beyond the analysis
Omitting adverse findings

AACE 29R-03 Source Data and Methodology Requirements

AACE Recommended Practice 29R-03, Forensic Schedule Analysis, treats source data discipline and methodology fit as preconditions for the analysis to be defensible. The report has to surface both.

Section 2 of the standard sets out the Source Validation Protocols (SVPs): the structured checks that must be applied to baseline schedules (SVP 2.1), as-built schedules (SVP 2.2), schedule updates (SVP 2.3), and discrete delay events (SVP 2.4) before any analysis is run. Every Method Implementation Protocol (MIP 3.1 through 3.9) lists which SVPs it requires; a report that does not disclose which SVPs were applied to which schedule version leaves the tribunal unable to assess whether the analysis stands on validated data.

Section 5.3 frames the same principle from the methodology-selection side: “the choice of a particular forensic scheduling methodology is substantially influenced by the availability of source data that can be validated and determined reliable for the purpose of the analysis… it is incumbent on the forensic schedule analyst to determine the amount of contemporaneous project documentation available and assess its quality.” In practice that means the choice of method should follow the data, not lead it, and the report should show the work.

Key reporting obligations the report should surface:

Requirement	What to Disclose
Data sources	All schedule data, documents, and records examined; what was not available
Methodology description	The specific MIP applied; why it was chosen; its limitations
Source validation	Which SVPs were applied to which schedule version (baseline, as-built, updates)
Assumptions	Every assumption that could affect the results; sensitivity of conclusions to each
Limitations	Constraints on the analysis (data, time, scope)
Results	Quantified delay per event; critical path impact; concurrent delay treatment
Provenance	Who performed the analysis; their qualifications; the tools used

AACE 29R-03 also distinguishes between the forensic analyst and the project scheduler, noting that the analyst must demonstrate independence from the project team.

Credibility Killers: Common Mistakes in Delay Analysis Reports

The following mistakes undermine more reports than any analytical error:

Mistake	Why It Undermines Credibility	How to Avoid It
Cherry-picking evidence	Selective reliance on documents that support one position while ignoring others	List all documents reviewed; address adverse evidence explicitly
Advocacy language	Using language like “clearly” or “obviously” signals opinion, not analysis	Use measured, qualified language; let the data speak
Missing contemporaneous records	Analysis based on reconstruction rather than records is inherently less reliable	State what contemporaneous records were available; acknowledge gaps
Methodology name vs application mismatch	Calling something “time impact analysis” when it isn’t creates a credibility gap	Describe the methodology applied, not just its name
Failing to assess schedule quality first	Analysing delays in a schedule with broken logic produces unreliable results	Include a schedule quality assessment before the delay analysis
Ignoring concurrent delay	Omitting concurrent events suggests selective analysis	Identify and address all concurrent delays explicitly
Unsupported assumptions	Assumptions that are not stated cannot be tested	List every assumption; assess sensitivity
Overclaiming precision	Stating “147.3 days” when the analysis cannot support that precision	Round appropriately; qualify precision
Not linking events to critical path	An event that doesn’t affect the critical path isn’t a delay to completion	Show the causal chain: event, schedule impact, critical path, completion date
Circular reasoning in as-built analysis	Using the as-built to prove the as-built	Distinguish between as-built facts and analytical conclusions

On large industrial EPCC disputes, schedule data often arrives across multiple inconsistent formats: PDF programme prints, native P6 files exported at different times, screenshots of Gantt views. The report has to surface which version was treated as authoritative for which analysis window. Skipping this disclosure is one of the most reliably effective grounds for an opposing expert to challenge the foundations of the analysis; the schedule version question gets answered first, and if it isn’t answered cleanly, the rest of the report carries less weight.

For more on identifying schedule quality problems that can undermine analysis, see our guide to baseline schedule review.

How to Review an Opposing Delay Analysis Report

When reviewing the other side’s report, work through this checklist:

Methodology selection:

Was the methodology appropriate for the type of delay being analysed?
Is the methodology named consistently with how it was actually applied?
Does the report explain why this method was chosen over alternatives?

Data completeness:

Were all relevant schedule versions used?
Were all contemporaneous records considered?
Is there evidence of selective reliance on some documents while ignoring others?

Assumption reasonableness:

Are all assumptions stated explicitly?
Are the assumptions reasonable and supportable?
Would changing any assumption change the conclusion?

Causation linkage:

Does the report connect each delay event to critical path impact?
Is the “before” position shown for each analysis step?
Are concurrent delays identified and addressed?

Red flags:

The methodology changes mid-report without explanation
Key data is missing but the limitation is not acknowledged
Conclusions appear that weren’t supported by the analytical sections
The report reads like an advocacy document rather than an expert opinion

For the analytical framework underpinning this review, see our guide to forensic schedule analysis.

Tools for Preparing Delay Analysis Reports

Tool	Function	Best For
Primavera P6	Schedule management and critical path analysis	Large projects with complex logic networks
Microsoft Project	Schedule management and basic critical path analysis	Smaller projects; owner-side reviews
Primavera Risk Analysis	Monte Carlo simulation and risk quantification	Risk-informed delay assessment
Time Line	Forensic delay analysis with built-in windows analysis	Dedicated forensic analysis
Delay Analyzer	IMPACT-style delay analysis	Forensic delay quantification
Steelray	Schedule quality checking	Pre-analysis validation

For a comprehensive comparison of schedule analysis tools, see our guide to schedule analysis software.

Key Takeaways

Structure follows function. The 12-section template ensures your report covers everything the tribunal expects and the standards require.
Transparency is credibility. State your methodology. List your assumptions. Show your working. A transparent report is a defensible report.
Don’t name a method; explain it. Calling it “time impact analysis” is not the same as showing how you applied it.
Assess schedule quality first. Analysing delays in a schedule with broken logic undermines the entire report. Run a quality check before you start.
Link events to critical path impact. Every delay conclusion must trace a path from the event, through the schedule, to the critical path, to the completion date.
Round your claims appropriately. If your analysis can’t support “147.3 days,” don’t claim it. Precision is not accuracy.
Write for the opposing expert. If the person most likely to challenge your work can follow and test your analysis, the tribunal can too.

Quick reference: Every delay analysis report must include:

Element	Where in the Report
Methodology and why it was chosen	Section 6
All assumptions stated explicitly	Section 10
Data sources and completeness	Section 4
Schedule quality assessment	Section 5
Causation chain: event to critical path impact	Section 8
Concurrent delay treatment	Section 8
Statement of independence	Section 12
Assessment limitations	Section 10