Forensic Delay Analysis

We establish the facts of what happened and when by looking at the records, the programmes and the delay events themselves. We consider the original plan, how things actually progressed, and any relevant changes to see how they affected the project programme.

We establish the facts of what happened and when by looking at the records, the programmes and the delay events themselves.

We consider the original plan, how things actually progressed, and any relevant changes to see how they affected the project programme.

The aim is a clear account of delay — not a narrative written around a preferred conclusion. The programme, the records and the events have to line up.

Records first

Programmes, progress records and correspondence are used to establish what was planned and what occurred.

Plan versus actual

As-planned and as-built positions are compared so delay is described against the programme, not in isolation.

Delay events

We look at the events themselves and how they sat in the network at the time they occurred.

Cause and effect

The analysis is directed at how those events affected critical path, float and completion.

How we work

A practical sequence

01

Assemble the evidence

Collect the relevant programmes, updates and project records for the period in question.
02

Rebuild the story

Set out the original plan, the actual progress and the events that intervened.
03

Show the effect

Explain how those events moved the programme, in language the project and commercial teams can use.

What you get

Useful output, not another unused report

A factual account of delay events and their timing
Analysis tied to the programme rather than to assertion
Clearer discussion of entitlement, mitigation and remaining risk
Material that can support commercial or dispute processes where required

When to use this

Use forensic delay analysis when the project needs an evidence-based view of what delayed the programme, and by how much.

Forensic Delay Analysis