Two years later, in a room full of lawyers.

And here's the thing nobody tells you at the start of a career: the boring discipline was the point. Every dull monthly update, every actual date taken from a diary instead of a phone call, every change you insisted on logging — all of it was you, quietly, building a witness.

Delay is easy. Cause is everything.

Forensic analysis has three parts, and only one of them is hard.

The plan is what the contract says you agreed to do. The reality is what the site records show actually happened. And the variance is the space between them.

Anybody can prove the project was late. Both sides already agree it was late. Nobody is paying lawyers to establish that.

The question — the only question — is: which specific event caused which specific days, and whose event was it?

"We were 45 days late and it was all your fault" is not an argument. It's a feeling with a number attached, and it will be taken apart in an afternoon.

Cut the project into windows

The method that actually works is unglamorous, and it's why your monthly updates matter.

You slice the project into periods — usually your update cycles — and you ask, of each one: how much delay was created in this window, and what happened in it?

Look at what falls out. February: twelve days, because the facade specification changed while the units were already in fabrication. March: five days of exceptional rain — nobody's fault, and probably excusable under the contract. April: eighteen days, because your steel subcontractor was late. May: four days waiting for level 3 to be handed over. June: six days of rework after a failed inspection.

Sixteen days theirs. Twenty-four days ours. Five days nobody's.

Now sit with that, because it's uncomfortable and it's the whole lesson. You caused more of the delay than they did.

And it is still the strongest position you can possibly be in. Because you can prove the sixteen. You walk in with a month-by-month account that survives scrutiny, and you own what's yours before anyone forces you to. That is what a credible witness looks like — and credibility is the only currency in the room.

The alternative — claiming all 45 days — gets your entire submission treated as advocacy rather than analysis. You'll lose the sixteen days you actually deserved, along with everything else.

They come for the baseline first

Before any of that, though, there's a fight you have to win, and most people don't see it coming.

The other side's expert will not begin by arguing about delay. They will begin by attacking the baseline itself — because if they can discredit the plan, every calculation built on it collapses, and the delay analysis never even happens.

Did you actually use this schedule? If it was issued at contract award and never updated again, it wasn't a plan. It was a formality, and formalities don't get compensated.

Is the logic complete? Open ends and loops — Week 11 — mean the critical path was never real, so no delay to it can be proven.

What are these hard constraints doing? Week 9 and Week 17. A pinned date isn't a calculation, it's an assertion. And an assertion is not evidence of anything.

Does the critical path make sense? If it runs through the car park, nothing built on top of it survives.

Every one of those questions was decided years earlier, by people who had no idea they were preparing evidence. That's the uncomfortable truth of this profession: your claim is won or lost during execution, by a planner doing unglamorous work that nobody thanks them for.

The clue in the RFI log

One tool worth knowing, because it finds causes that a Gantt chart cannot.

Pull your RFI log and plot it by month. You are looking for clusters.

A sudden spike of technical queries in one area — forty RFIs about the level 4 slab in March — is a fingerprint. It means the information the site needed wasn't there, people were guessing, and work was stopping and starting while they waited.

And the delay that spike caused won't appear in the programme in March. It shows up in June, as a subcontractor who "underperformed," because that's when the consequences land.

RFI clusters are how you connect the two — the causal link between a design that wasn't ready and a delay everyone blamed on the trades. The Gantt chart shows you when things went wrong. The RFI log often shows you why.

Whose float is it?

And one question that decides more claims than most people realise.

An activity has ten days of float. The client's late information consumes eight of them. The project doesn't finish a day later — the float absorbed the hit.

Is that a delay?

It depends entirely on who owns the float — and that is a contractual question, not a technical one. Some contracts say float belongs to the project, and whoever needs it first may use it. Others say it belongs to the contractor, and consuming it is compensable even if the end date holds.

Find out what your contract says. Do it now, while it's an interesting question, and not in two years when it's an expensive one.

You cannot reconstruct a contemporaneous record after the fact. You cannot go back and remember, honestly, what the float was in March. A schedule maintained in a panic, twice a year, when disaster strikes, is a document with holes in it — and every hole is a place where the other side gets to tell the story instead of you.

Practical insight

Assume, from today, that your current schedule will one day be read aloud by a lawyer.

Then ask what changes. Would you write a note explaining why that activity slipped, while you still remember? Would you accept a verbal instruction without logging it? Would you let a hard constraint sit in the model for another month?

Nothing in that list is difficult. All of it is boring. And all of it is worth more, two years from now, than anything else you did this month.

Key takeaways

✔ Proving there was a delay is trivial; proving what caused it, and whose it was, is the whole job.
✔ Windows analysis apportions delay period by period against the contemporaneous record.
✔ Owning the delay that's genuinely yours is what makes the rest of your claim credible.
✔ Claim everything and you'll be treated as an advocate, not an analyst — and you'll lose.
✔ The other side attacks the baseline first: was it used, is the logic sound, why the constraints.
✔ A claim is won during execution, by a planner nobody was thanking at the time.
✔ RFI clusters expose causes a Gantt chart can't show — the drift arrives months after the queries.
✔ Float ownership is contractual. Read your contract now, not in two years.
✔ Gaps in your update history are places where the other side gets to tell the story.

What's coming next

The claim is settled. The building stands. And the project is about to make its final, most predictable mistake.

Everyone leaves. The best people are pulled onto the next job the week the last milestone lands, the paperwork is left to whoever is slowest to escape, and every hard-won lesson from three years of work evaporates into nobody's memory.

Next week: closeout — the two gates a project has to pass before it's actually finished, and why the most valuable data your company will ever own is the data it throws away at handover.