Delay analysis is not about “Computer Says” – it’s all about the facts!
There are several well-known and reliable methods of delay analysis that can be utilised when a project suffers delay, when you are required to demonstrate your entitlement to an extension of time or when dealing with a delay in start-up (DSU) or business interruption claim (BI) under an insurance contract or policy.
While much has been written about these techniques and how to apply them in theory, this is only part of the challenge when undertaking a delay analysis. All too often we come across delay analyses that forget one thing, what actually happened! Typically, we come up against a totally theoretical analysis, overly reliant on the results from the planning software analysis without any understanding of what actually happened on the project. We term this as a “computer says” analysis.
Put simply, this is where the delay analysis is wholly reliant on the results from the planning software and bears no relation to how the works were actually undertaken or the actual (not theoretical) effect each event had on the project. It may come as shock to a few of you out there, but some programmes or schedules do not necessarily reflect the way the work was actually carried out on site or may be of insufficient detail to accurately understand the effect of certain events.
But hang on, factual investigations are of primary importance when looking to unpick or prove what has happened. The delay analysis only forms part of that investigation and should not be the only analysis that is produced; it should be based as far as possible on contemporaneous evidence of what actually happened on site during the progress of the works and is really only as reliable or accurate as the data upon which it is based.
I would argue that of primary importance in any delay analysis are the project records. (I know it’s a radical thought, but you would not believe how often we see claims that ignore these critical contemporaneous records). This can be progress reports, letters, emails, minutes of meetings, drawing issues and drawing approvals to verify as built dates and sequencing and to further prepare event fragnets. After all, it’s these documents that tell the real story of what happened on site and are invaluable when analysed in conjunction with the delay analysis to prove your point. By adopting this approach and modifying your programmes or schedules to reflect what actually happened, your analysis will more likely reflect reality.
Don’t forget facts are a good thing! The more factually based your delay analysis is, the more robust it is likely to be.