Demonstrating delay: the longest path, evidenced

1. The question every tribunal asks

Strip the methodology debates away and a time claim must demonstrate three things: that completion moved; that it moved along the path that actually governs completion; and that the movement was caused by the event relied on. Most failed delay claims fail on the second and third — they prove lateness, not causation on the critical path.

2. Trace the longest path, not the loudest activity

The critical path is whatever chain of activities and logic actually drives the completion date — the longest path through the network — and it migrates as the project progresses. An activity with zero float in the baseline may be irrelevant by month six; the analysis must follow the path as it stood in each window, not as it was planned on day one.

Float behaviour is part of the story: an event that consumes float without moving completion is not (yet) critical delay — but it changes the project's resilience, and your contract or its PCs may say who owns that float.

3. Correlate events to the windows where the path moved

Causation is shown by correlation in time and in logic: the event happened in this window; the path ran through the affected activities in that window; completion moved by this amount in the same window. That correlation is exactly what contemporaneous programme versions plus a maintained event log make demonstrable.

4. Concurrency: address it, don't bury it

Where an employer-risk and a contractor-risk delay overlap, say so, and state the treatment applied — whether the contract prescribes one (check the PCs), or you adopt a recognised approach and apply it consistently. An analysis that visibly engages with concurrency is more credible than one that pretends the overlap is not there — and credibility is the currency these analyses trade in.

5. Present the analysis so it can be checked

Show the network versions used, the windows, the path in each window, the events mapped to each movement, and the arithmetic from movement to EOT claimed. The reader who can verify each step is a reader who can grant the claim — the same principle that governs the claim submission itself.