Delay Rarely Starts Where You Think It Does

Delay is often presented as a single event. A variation is issued, access is late or a drawing does not arrive when expected. From there, attention quickly turns to the number of days supposedly lost. On most projects I have worked on or analysed, the reality is less tidy.

A drawing arrives late and a work front cannot start. The contractor resequences the works and moves the crew elsewhere. By the time the drawing arrives, those resources are committed to another area. Returning to the original sequence then affects other activities, perhaps consuming available float or changing the path to completion.

By the end of the project, the event being blamed for the delay may be several steps removed from the point at which the programme first started to move.

That is why understanding delay requires more than identifying events and attaching periods of time to them. The sequence between the event and the eventual effect matters.

“The event receiving the most attention at the end of a project may not be where the delay really began.”

Finding the beginning of the delay

Late design information provides a useful example.

If a drawing was issued three weeks late, it is tempting to describe this as a three-week delay. Before reaching that conclusion, I would want to understand what was happening on the project during that period.

The affected work may have been critical, but it may also have had float. The contractor may have been able to progress elsewhere or resequence the work. Resources could have been reassigned and, when the drawing eventually arrived, may no longer have been available. There may also have been other events affecting the same work.

The date of the drawing tells us when one event occurred. It does not tell us the extent of the delay caused by it.

This is where cause and effect becomes important. The analysis has to follow the consequences through the project rather than stopping at the original event.

Criticality changes as the project develops

The baseline programme is an obvious place to start, but it cannot be assumed to represent the critical path throughout the works.

Construction projects change continuously. Actual progress differs from planned progress, activities are resequenced, mitigation measures are introduced and float is consumed. An activity that had considerable float early in the project may later become critical, while something originally shown as critical may cease to drive completion.

This matters when analysing an event that occurred months after the baseline was prepared.

Finding the relevant activity in the original programme and establishing that it was critical at that point does not necessarily establish that the event delayed completion. The analysis needs to consider the state of the project when the event occurred and how the path to completion developed afterwards.

“Criticality is a project condition at a point in time, not a label permanently attached to an activity.”

The programme needs to be tested against the records

Programme analysis is central to much of the work we do, although I would be uncomfortable reaching conclusions from the programme in isolation.

The contemporaneous records often explain why the programme moved.

Site diaries can show where crews were actually working. Progress reports may record emerging access or design problems. Correspondence establishes when information was requested, discussed and eventually supplied. Photographs, procurement records, instructions and meeting minutes can fill in parts of the story that are difficult to see from a programme update alone.

There will inevitably be imperfections in those records. Programmes are not always updated properly and site records are rarely created with a future delay analysis in mind. Part of the forensic exercise is therefore comparing the available sources and determining which account of the project is supported by the evidence.

The software is useful in that exercise, but it cannot undertake that judgement for the analyst.

The problem with broad narratives

On a heavily delayed project, it is easy to understand how a broad narrative develops. There may have been hundreds of variations, repeated late information, access problems and significant disruption. The project then finishes months later than originally planned.

The missing part is demonstrating how those circumstances produced the delay being claimed.

Australian decisions have repeatedly illustrated the difficulty with approaches that aggregate events and consequences without adequately establishing the individual causal relationships. John Holland Construction & Engineering Pty Ltd v Kvaerner R J Brown Pty Ltd remains relevant when considering the evidentiary problems associated with global approaches.

Kane Constructions Pty Ltd v Sopov [2005] VSC 237 similarly involved detailed consideration of individual delay and extension-of-time issues. More recently, V601 Developments Pty Ltd v Probuild Constructions (Aust) Pty Ltd [2021] VSC 849 has provided further useful guidance on delay analysis and the importance of examining what actually occurred on the completed project.

The practical point for me is that complexity does not remove the need to explain causation. If anything, a complicated project makes that explanation more important.

“A six-month overrun does not explain six months of delay. The analysis still has to show how the project got there.”

Following the project as it drifted

When I review a delayed project, I am interested in when the programme first started moving away from the planned sequence and what happened from that point onwards.

Sometimes there is a clear dominant event. On other projects the position develops gradually as several events interact with decisions made in response to them.

That distinction matters. Resequencing, for example, may reduce the immediate effect of one delay while creating consequences elsewhere. A crew moved to protect progress in one area may later be unavailable in another. Float may absorb an event initially and only become significant when a subsequent event occurs.

By following the project chronologically, those relationships become much easier to understand. Projects rarely lose several months in one moment. More often, they drift away from the plan through a series of events and consequences.

Good delay analysis explains that drift: where it started, how it developed and, most importantly, which parts of it actually affected completion.

---

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