Why Retrospective Analysis Carries Weight

Once a project is finished, the programme stops being a plan. It becomes a record.

That shift is where many delay analyses lose traction. Prospective methods are useful during delivery. They let teams model potential impacts and respond while there's still time to act. Once the work is complete, those models compete with actual events, and courts tend to prefer the latter - not because prospective analysis is flawed, but because hindsight removes the guesswork it was built to manage.

This was made clear in V601 Developments v Probuild [2021] VSC 849, where Justice Digby emphasised that delay should be assessed retrospectively using as-built facts. The reasoning is straightforward. When the evidence exists, it should be used.

Retrospective analysis follows the real sequence of events. It shows what happened, when it happened and how it affected completion. It deals with the project as it was delivered, not as it was planned. That doesn't mean models disappear entirely - they still assist in structuring the analysis. But they need to align with the record, and where there's a conflict, the record carries weight.

This aligns with earlier authority. In Kane Constructions v Sopov [2005] VSC 237, the Court worked through delay claims in detail, testing each against contemporaneous records and the evolving critical path. The analysis was grounded in fact, not abstraction.

Methodology choice reflects the same logic. Windows analysis, one of the more common retrospective techniques, breaks the programme into defined periods and tests progress against the record for each - staying close to what was actually built, not what was forecast. It sits alongside a handful of other retrospective methods, including retrospective longest path and collapsed as-built analysis, each answering a slightly different question about cause and effect. What they share is a starting point in what actually happened, rather than a model of what should have happened.

Time impact analysis sits a little differently. It's a strong tool prospectively, where the question is what a delay event is likely to do to the programme going forward. Applied retrospectively, on a project that's already finished, it can end up testing a theoretical run of events against a record that already tells a fuller story. That's part of why industry guidance has shifted away from treating it as the default once a project is complete, and toward a broader menu of methods depending on what records exist and what the dispute needs to prove.

“No single method suits every case. The right one depends on the contract, the quality of the programme updates, and what’s actually being tested.”

Real projects are rarely clean. Activities overlap, sequences change, resources move, and a retrospective analysis needs to deal with that complexity rather than smooth it out. Where analyses rely on idealised sequences, they struggle. Where they reflect actual progress, they tend to hold - and that only works if the underlying records are good enough to reconstruct that progress accurately.

That's the part that gets underestimated. A retrospective analysis is only as strong as what was captured during delivery: site diaries that record more than the weather, progress photos taken consistently rather than when someone remembers, updated programmes issued on a regular cycle, and delay notices sent when the contract requires them, not months later once a dispute has started. None of that is complicated. It's just easy to let slip when the project is moving and the paperwork feels like it can wait.

It can't. By the time an expert is engaged, the site has usually moved on, the people involved have moved on, and memory is doing the job that records should have done. An analysis built on gaps invites challenge, because there's nothing for it to stand on beyond the analyst's own reconstruction. An analysis built on a solid contemporaneous record can be tested, checked and, where necessary, defended - because it's simply describing what happened, not arguing for a version of it.

Delay is not proven by theory. It's proven by showing what actually happened, and why it mattered - and that case is only as strong as the record kept while it was happening.

None of this is really about the dispute itself. It's about what happens well before one exists. Programmes updated on a genuine cycle, notices sent on time, records kept as a matter of routine rather than reconstructed under pressure - these are project management habits, not legal ones. But they're exactly what determines whether a retrospective analysis, if it's ever needed, has something solid to work with. The projects that come through a dispute with the least friction are usually the ones where nobody had to go looking for the record. It was already there.

---

At Accura Consulting, our team of experts work with clients to create a tailored solution to problems. If you have an issue and want expert support, get in touch.

---

Back to News and Insights

Related News and
Insights from Accura