Delay Analysis Masterclass: How Experts Prove Time Entitlement in Construction Projects

Why delay analysis is really about facts, not blame

In every claim meeting I have ever sat in, the loudest argument loses. Delay analysis is not about who shouts hardest, who has the senior contact at the client, or who tells the most convincing story in a steering committee. It is about logic, facts and a methodology that holds up when an independent reviewer tears it apart. Time entitlement is granted when the impact of an event on the critical path is proven with evidence — nothing else.

On real construction projects, the cause of delay is rarely a single dramatic incident. It is usually a chain of overlapping events: late design information, slow approvals, a procurement slip, a productivity dip, a weather window missed, then a subcontractor pulled to another job. Untangling that chain into a defensible Extension of Time (EOT) claim is the craft of delay analysis. This masterclass walks through how experienced project controls professionals actually do it.

The seven-step delay analysis process experts actually follow

Experienced delay analysts follow a disciplined sequence: collect documents, understand the project, identify delay events, analyse the impact, quantify the delay, prepare the report, then present and defend it. Skipping any step weakens the entire argument. The first step alone — collecting contracts, baseline schedule, correspondence, progress updates, site records and delay notices — usually determines whether the claim is winnable at all.

Understanding the project means reading the scope, the activity sequence, the logic, the constraints and the contractual key dates before touching the schedule. Identifying delay events means classifying every disruption — owner delays, design delays, late approvals, late information, site restrictions and others — with dates, evidence and references. Only after that foundation is in place does the actual impact analysis begin.

Types of delays: excusable, non-excusable, concurrent and neutral

Delays generally fall into four buckets. Excusable (compensable) delays are owner-caused and beyond the contractor's control — they typically support both time and cost entitlement. Excusable (non-compensable) delays are beyond the contractor's control but not the owner's fault either — these usually support time but not cost. Non-excusable delays are within the contractor's control and risk. Neutral delays are caused by third parties or force majeure and are normally treated under specific contract clauses.

Concurrent delays — where both parties contribute to the same period of impact — are the most contested category in practice. They are not a separate type so much as a condition that overlaps the others, and they require a careful analysis to decide whether the impact is fully compensable, partially compensable, or non-compensable.

The delay classification matrix

A clean classification matrix is one of the most useful tools an analyst can carry into a claim conversation. Excusable compensable delays are beyond the contractor's control and the owner is responsible. Excusable non-compensable delays are beyond the contractor's control but the owner is not responsible. Non-excusable compensable delays are within the contractor's control but the owner is still responsible (rare and contract-specific). Non-excusable non-compensable delays are entirely within the contractor's control — the contractor bears the risk. Concurrent delays depend on analysis.

The matrix matters because it forces clarity. Once each delay event is classified, the conversation moves from 'who is to blame' to 'what does the contract say about this category of event' — which is precisely where delay analysis should live.

Critical path impact: the only delays that earn time

Time entitlement is granted only when the delay impacts the critical path and extends project completion. A delay to a non-critical activity with sufficient float may absorb the impact entirely; the project finish date is unaffected, so no EOT is owed. A delay to a critical activity — or to a near-critical chain after float erosion — pushes the project finish out by the same amount, day for day.

This is why experienced analysts always look at two things first: the planned critical path at the time of the event, and the actual critical path after the event. If the critical path itself shifted because of the delay, that shift becomes part of the story. If float on a near-critical path was eroded across several updates, that erosion needs to be shown in the windows analysis, not buried.

As-Planned vs As-Built: where every credible analysis starts

The simplest and most widely accepted method is the As-Planned vs As-Built comparison. It places the planned critical path next to the actual critical path and identifies where, when and by how much the two diverged. On a building project the planned critical path might run Start → A → C → F. After execution, the actual critical path may have shifted to Start → A → B → D → F because design changes pulled different activities onto the critical chain. That shift, with the days of slippage attached, is the first half of the claim.

As-Planned vs As-Built works best on simple projects with clean baselines and clean as-built data. It is intuitive, easy to present and easy to defend. Its limitation is that it does not always isolate which event caused which day of delay when several events overlap. That is where the more advanced methods come in.

Common delay analysis methods: a comparison

There are five methods most senior practitioners rely on. (1) As-Planned vs As-Built is the simplest and most common, best for simple projects, easy to understand, but may not isolate causes. (2) Time Impact Analysis (TIA) inserts the delay event into the current updated schedule and measures the impact on the completion date — widely accepted, especially in forward-looking claims, but only as good as the update it is based on. (3) Windows Analysis breaks the project into time windows and compares total float at the start and end of each window — if float reduces, there is impact. It shows impact over time but the window size matters enormously. (4) The Fragnet (or Fragmented Network) Method uses critical path analysis around concurrent delays to isolate which event drove which days. It is powerful for concurrent claims but mathematically demanding. (5) The Collapsed As-Built (CAB) Method removes the delay events from the as-built schedule to show what would have happened without them — strong for complex updates, but requires very detailed logic and as-built records.

There is no single 'right' method. The right method is the one whose assumptions and data requirements match the project and the contract. On a monthly-updated megaproject, Windows or TIA usually dominate. On a smaller job with a stable baseline, As-Planned vs As-Built may be enough.

Window analysis in practice

Window analysis is one of the most respected methods because it tells the story chronologically. The analyst defines a series of windows — often monthly — and, within each window, compares the planned critical path and total float at the window start to the actual critical path and total float at the window end. Any reduction in total float on the driving path inside that window is impact attributable to the events that occurred in that period.

Done well, a windows analysis reads like a timeline of decisions and events: in March the critical path ran through the structural frame and lost 5 days because of late rebar deliveries; in April it shifted to MEP rough-in because a design change pulled HVAC ducts ahead of fire protection. Each window earns or denies time on its own evidence rather than relying on a single end-of-project comparison.

Concurrent delay logic: full, partial and no concurrency

Concurrent delay is the area where most claims rise or fall. The framework I use is simple. If only one party's delay impacts the critical path during the period under review, there is no concurrency — full impact is compensable to the affected party. If both parties' delays impact the critical path during overlapping but not identical periods, concurrency is partial — impact must be apportioned and is typically partially compensable. If both parties' delays impact the critical path over the same period in the same way, concurrency is full — the impact is usually treated as non-compensable, with time often granted but cost denied.

Typical concurrent delay examples on construction projects include design delays running alongside poor productivity, late approvals running alongside rework, site-access delays running alongside resource shortages, and late drawings running alongside late material deliveries. The party seeking time extension must prove that the delay was not concurrent and impacted the critical path. Without that proof, even a real delay can fail to convert into entitlement.

Delay analysis documentation: the golden rule

The golden rule of delay analysis is brutally simple: what is not documented, did not happen. The strongest claims are almost always supported by the same recurring evidence stack — an approved baseline schedule, properly maintained progress updates, the as-built schedule, contemporaneous delay notices and correspondence, daily site records, change orders and approvals, calendars and weather records, and the delay analysis report itself.

On live projects I push teams hard on contemporaneous records — notices issued within contractual timeframes, daily reports signed by site engineers, RFI logs with date stamps, and procurement registers tying late deliveries to specific activities. These are not bureaucracy; they are the raw material the analyst will need months later when the dispute heats up.

A sample as-planned vs as-built impact

Consider a simple building example. Foundations were planned to finish March 1 but actually finished April 10. Structure was planned to finish May 30 but actually finished July 15. MEP rough-in was planned to finish July 29 but actually finished September 20. Finishes were planned to finish September 27 but actually finished November 15. Total slippage at the finishes activity — the controlling end-date — is approximately 49 days.

That 49-day headline is only the start of the analysis, not the end. The job of the analyst is to walk through each window, identify the events that consumed float or extended the critical path, classify them, and link days of impact to specific events. Forty-nine days of slippage might be 30 days of owner-caused excusable delay, 12 days of concurrent delay and 7 days of contractor risk — or any other split that the evidence supports.

Quantifying the delay: time impact, extended dates and supporting evidence

Quantification is more than producing a number. A defensible quantification states the time impact, the new extended date that results, and the evidence that supports both. Time impact is normally measured in working days against the project calendar, not raw calendar days, because schedules calculate against working calendars. Extended dates must reflect the corrected critical path after the analysis, not just the original baseline shifted by the headline delay number.

Supporting evidence is where junior analysts often stop short. Each day of impact should be traceable to a specific event, a specific activity, a specific update, and a specific record. The further the claim travels — internal review, client review, expert review, tribunal — the more this traceability matters.

The delay claim success checklist

Across the claims I have seen succeed, the same checklist appears almost every time: a valid baseline schedule, properly updated schedules throughout, contemporaneous records, clear delay notices issued on time, a clearly identified cause, an impact that is logically proven, a delay that is properly quantified, and mitigation efforts that are documented in writing. Miss any one of these and the claim weakens; miss two and it usually fails.

Mitigation duty is the item most often forgotten. Even a perfectly proven owner-caused delay can be reduced or denied if the contractor cannot demonstrate that reasonable steps were taken to absorb or mitigate the impact — resequencing, working in parallel, deploying additional resources where economically reasonable, or accelerating non-critical work.

Experts follow this framework

Senior delay analysts work to a repeatable framework. Understand the contract first — every clause about EOT, notices, concurrent delay, float ownership and disruption matters. Gather reliable records. Build and update the schedule on a disciplined cycle. Identify delay events as they occur. Analyse the impact with the right method. Quantify the entitlement clearly. Prepare a clear, logical report that a non-planner can follow. Defend the analysis with confidence — facts, then logic, then evidence, then entitlement.

This is the difference between a planner who 'tracks delays' and a project controls professional who can prove time entitlement. The first manages a register; the second wins or saves real money for the project.

Common mistakes that sink delay claims

The first common mistake is no baseline — without an agreed baseline, there is no delay, because there is nothing to measure against. The second is irregular schedule updates, which makes any retrospective analysis fragile. The third is missing or late delay notices, which most contracts treat as a partial bar to entitlement. The fourth is confusing slippage with critical-path impact; a delay to an activity with float is not automatically a project delay. The fifth is ignoring concurrent contributions, which exposes the claim to immediate counter-argument.

The sixth — and most expensive — is presenting opinion as analysis. Strong claims are built on records, not opinions. Document today, prove tomorrow.

Expert tips and final reminders

Delay analysis is a skill, not a software. Good software helps; it does not replace judgement. Stay objective and professional — analysts who are seen as advocates lose credibility quickly, while analysts who are seen as honest gain weight even when reporting bad news. The more solid your analysis, the stronger your claim. Good analysis means a fair extension; poor analysis means lost time.

You don't get paid for what you do — you get paid for what you can prove. Master the facts. Prove the impact. Earn the extension. That, in one line, is the operating philosophy of every senior delay analyst worth listening to.

Key takeaway

Delay analysis is both an art and a science. It requires technical skill, attention to detail and the ability to tell the story with facts. Pair this masterclass with the Planning & Scheduling track, the Earned Value Management framework, the Primavera P6 learning path and the PMO Reporting pillar to see how delay analysis fits into the wider project controls system, and use the PMMilestone calculators to test schedule and cost performance scenarios on your own projects.