Construction Delay Analysis: Methods, Evidence and Catching Delays Early

Construction delay analysis is the process of establishing how much a project was delayed, what caused it, and who carries the time and cost consequences. It is normally performed against the baseline programme using the contemporaneous project records.

Most teams meet it in its worst form: retrospectively, under commercial pressure, with a claim already drafted and a consultant reconstructing eighteen months of events from an incomplete record. By that stage the analysis is an argument about the past rather than a tool for managing the project.

The same techniques work far better applied early and at small scale. Understanding which activity absorbed float, which delay was concurrent and which one actually moved the completion date is useful in week nine, not only at final account.

Three distinctions run through everything below. Excusable delays entitle the contractor to time, and compensable ones also to money. Critical delays extend the completion date, while non critical delays consume float without moving the end. Concurrent delays occur when both parties cause overlapping critical delay in the same period, which is where most disputes end up.

Several recognised methods exist. They differ mainly in whether they look forwards or backwards, and in how much contemporaneous record they require.

As planned versus as built. Compare the baseline against what actually happened. Simple, cheap and intuitive, but it shows correlation rather than causation and struggles with concurrency.

Impacted as planned. Insert the delay events into the baseline and recalculate. Prospective and quick, but it assumes the baseline was realistic and ignores how the project actually unfolded.

Collapsed as built. Build the as built programme, then remove the delay events to show what would have happened without them. Retrospective, and only as reliable as the as built record it rests on.

Time impact analysis. Insert each delay into the programme as it stood immediately before that event and recalculate the completion date. Widely regarded as the most rigorous approach, and the most demanding, because it needs a properly updated programme at each point in time.

Windows analysis. Divide the project into periods and analyse critical path movement within each. It handles a shifting critical path better than any single snapshot method, which is why it is common on long or complex projects.

The choice is usually dictated by the contract, the forum and the quality of the records rather than by analytical preference. Which is itself the point: the method you are entitled to use is decided by what you recorded while the work was happening.

Every method above depends on the same underlying evidence, and it is almost always the evidence rather than the analysis that fails.

• A baseline programme that was actually agreed, with defensible logic and durations.
• Regular programme updates showing progress as it was understood at the time, not reconstructed later.
• Dated records of the events themselves: RFIs, submittals, instructions, approvals, inspections and deliveries, with the dates they were raised and answered.
• Evidence of the link between an event and a specific activity, which is the element most often missing.
• A record of what the team did in response, since mitigation efforts affect entitlement.

That fourth point deserves emphasis. A project may hold a perfect RFI log and a perfect programme and still be unable to demonstrate that RFI 214 was the reason the riser installation started eleven days late. The two records exist in different systems and nobody connected them at the time. Reconstructing that link two years later, from memory and email, is exactly what makes delay analysis expensive and its outcome uncertain.

A delay claim is what remains when nobody saw the delay coming. The signals were usually present weeks earlier: an approval ageing past its need by date, a subcontractor who never confirmed, a predecessor drifting, a delivery slipping. Individually each looks like noise. Together they describe an activity that is not going to start.

Prevention and entitlement pull in the same direction here, which is convenient. The records that let you act early are the records that prove your case later. A constraint with an owner, a need by date and a resolution history is both an early warning and evidence.

Practically, that means treating the lookahead as the place where delays are caught rather than the place where they are reported, and knowing which slipping activities sit on the critical path so that attention goes where the completion date is actually exposed.

This is the problem Playbook is built around. Approvals, documents, field updates and conversations stay attached to the activity they affect, so the causal link is captured while it is happening rather than reconstructed afterwards. The system can then flag which combination of signals threatens a milestone and explain the evidence behind that assessment. It will not tell you who is contractually liable, and it does not remove the need for expert analysis on a live dispute. What it changes is how much of the record exists before anyone starts looking for it.