By the time a delay analyst is engaged, the most important decision in the analysis has usually already been made.
Not the choice of method. The choice was made earlier — every month a programme update was submitted and accepted, or wasn’t; every time a baseline was formally agreed with the Engineer, or simply assumed to be understood; every delay event that was documented as it happened, or left to be reconstructed later from memory and correspondence.
The analyst’s task is to select the method the evidence can support. But the evidence itself was fixed long before the analyst was ever called.
THE METHOD FOLLOWS THE RECORDS — NOT THE OTHER WAY AROUND
Delay analysis offers a hierarchy of methods, roughly ordered by how much they demand of the underlying records.
A simple comparison between the original programme and what actually happened asks the least of the evidence — a starting baseline and a reliable account of actual dates. It’s also the most fragile, because it assumes the original programme was realistic to begin with, an assumption tribunals routinely reject once they see how the project actually unfolded.
A period-by-period analysis, testing what drove the critical path within each reporting cycle, demands more: a programme update at every period boundary, ideally one the Engineer actually reviewed. Where those updates exist, this approach captures something the simple comparison cannot — that the critical path itself moves as a project progresses, and a delay that mattered in month six may be irrelevant by month nine.
The most rigorous approach — inserting each delay event into the programme at the moment it occurred, and measuring its impact against the project’s actual state at that point — demands the most of all: an accepted baseline, contemporaneous updates, and each delay event documented with dates and causation that can be independently verified.
None of these methods is inherently correct. Each is correct only when the underlying records can support it. Choosing the most rigorous method on a project that never maintained the records to support it doesn’t produce a stronger analysis. It produces a longer one — built on reconstruction rather than evidence, and vulnerable at exactly the point an opposing expert will press hardest.
WHY THE REAL DECISION HAPPENS MONTHS BEFORE ANYONE THINKS ABOUT A CLAIM
None of the decisions that determine which method will later be available look, at the time, like decisions about a future claim.
A monthly programme update is prepared, but submitted late, or not formally accepted by the Engineer — because the project is moving, the update reflects roughly what everyone already knows, and chasing formal acceptance feels like an administrative delay nobody has time for.
A baseline programme is agreed in principle at the start of the project, discussed in meetings, referenced informally — but never goes through the contractual acceptance process that would give it standing later. Everyone on the project team knows what the baseline is. Six months after practical completion, when a dispute has started and the people who “just knew” have moved to other projects, that shared understanding is no longer evidence of anything.
A delay event is absorbed into the working rhythm of the site — a late instruction, a design change, a sequencing conflict — without anyone formally recording when it started, what caused it, or how it affected the critical path at that moment. It gets solved, the project moves on, and the record of exactly how it was solved never gets written down.
None of these choices feel like they concern a claim. Nobody preparing a monthly report is thinking about cross-examination. That’s precisely why they’re made the way they are — and precisely why, months or years later, they determine what a delay analyst can and cannot prove.
THE ANALYST CANNOT INVENT WHAT WAS NEVER RECORDED
A skilled analyst can build a coherent, well-reasoned narrative from incomplete records. What a skilled analyst cannot do is make that narrative carry the evidential weight of a record that was never created.
The distinction matters more than it sounds. An analysis built on a reconstructed baseline — assembled after the fact from tender documents, emails and recollection — can look identical, on paper, to one built on a baseline the Engineer actually reviewed and accepted. The difference only becomes visible under scrutiny, when the opposing expert asks the analyst to demonstrate that the baseline was ever formally agreed, and the honest answer is that it wasn’t.
At that point, the sophistication of the method stops being an advantage. A rigorous method applied to a weak evidential foundation collapses under its own weight faster than a simple method applied honestly — because the more the method claims to demonstrate, the more it exposes exactly where the underlying evidence runs out.
WHAT THIS MEANS FOR HOW PROJECTS ARE ACTUALLY RUN
The practical implication isn’t about claims preparation. It’s about how programme administration is treated while the project is still live, long before anyone is thinking about a dispute.
Monthly programme updates need to happen on schedule, and need to go through whatever acceptance process the contract actually requires — not as a formality to file away, but as the record that will later determine whether a rigorous delay analysis is even possible. A baseline that exists only as shared understanding among people who happen to still be on the project is not a contractual baseline. It becomes one only once it’s been through the process the contract describes.
Delay events need to be documented as they happen — not because every disruption will become a claim, but because the ones that eventually do are indistinguishable, in the moment, from the ones that won’t. There’s no reliable way to know in advance which minor sequencing issue is a footnote and which is the first data point in a nine-figure claim three years later.
This is the same discipline that shows up, in different form, throughout contract administration generally: the position that matters is protected long before anyone knows it will be tested.
THE PRINCIPLE
The strongest delay analysis is not the one built with the most sophisticated method.
It’s the one built on records that were maintained as a matter of routine, long before anyone thought a claim was coming — because by the time the analyst is engaged, the method available is no longer a choice. It’s a consequence.
How ACC TRUST can support
ACC TRUST supports contractors and subcontractors in maintaining the programme and record-keeping discipline that determines which delay analysis methods remain available if a dispute arises, including:
- reviewing current programme submission and acceptance practice against contractual requirements;
- establishing processes for monthly programme updates that create genuine contemporaneous records, not retrospective reconstructions;
- identifying live projects where the baseline programme has never been formally accepted, while the gap can still be closed;
- structuring the documentation of delay events as they occur, before the underlying facts depend on memory;
- assessing, on live or completed projects, which delay analysis methods the existing records can actually support.
For support with contract administration, programme governance or claims strategy:
Explore ACC TRUST services:
→ https://acctrust.ro/en/services
Discuss a specific project:
→ office@acctrust.ro
About ACC Trust Insights
ACC Trust Insights is the knowledge centre for Commercial & Contract Governance, Project Delivery and Risk Management in complex construction, infrastructure and energy projects.
Explore all articles:
→ https://insights.acctrust.ro
ACC TRUST
Commercial & Contract Governance Advisory
Property · Infrastructure · Energy
office@acctrust.ro