On time, and losing money.

On time, and losing money.

Picture the version of this job where everything works. The rock is found, the notice goes in on time, an extension is granted without argument, and the team pulls the programme back together. The building is handed over on the contract completion date.

Everybody congratulates each other. And the net margin of $48,163 is gone anyway, because for seven months the work was done in the wrong order, in half-finished areas, by crews who moved four times a week and never got a clean run at anything.

Nothing in the previous eighteen weeks finds that money. Every method in Phase C measures movement in a completion date, and the completion date never moved.

What disruption actually is

Disruption is what happens when the orderly flow of work breaks up: continuity lost, sequence scrambled, an operation turned into a series of interruptions. The Protocol frames it as disturbance or hindrance to the way a contractor would normally have worked, leaving the job less efficient than it would otherwise have been.

Delay can cause disruption and disruption can cause delay, and they frequently arise from the same events. They are still not the same thing, and the difference is not academic.

Read that grid carefully, because it contains the whole argument for this phase. A delay may cost you nothing at all — it lands on an activity with float, the completion date holds, no damages run. Disruption is the reverse: once it is established, it always has a direct financial consequence, because inefficient work costs more to do.

The top-right box is the one that goes unclaimed. Finished on time, worked badly, money gone. No extension of time was ever due and none was ever applied for, so nothing in the project's paperwork records that anything happened.

Three ways it stays invisible

It helps to know the mechanisms, because each one produces a different-looking job.

The disruption lands on non-critical work. Activities with float are interrupted, resequenced, worked in fragments. The completion date is untouched, so no extension arises, and the only trace is that those activities consumed far more hours than they were priced at.

Or it lands on critical work and gets absorbed. More resources are applied, the date is protected, and the delay never materialises. Week 18 covered what that costs; the point here is that the cost is real even when the acceleration argument is unavailable.

Or everything simply takes longer than it should, everywhere, all year. Nobody can name a day when anything went wrong. The job finishes when it was always going to finish and the final account is a disaster.

Concurrency does not settle it

Here is a point worth carrying out of this week even if nothing else sticks.

Week 16 established that concurrent contractor delay generally moves a prolongation claim out of the compensable column. Time survives; money doesn't. That rule is about the completion date, and it applies to costs that flow from the completion date moving.

Disruption behaves differently. Once loss of efficiency is established, it carries a direct and measurable financial consequence even where concurrent or co-contributory culpable factors are present. Your own failings do not simply cancel it the way they cancel prolongation.

That does not make it easy, and it is emphatically not a way round the concurrency problem. What it does is move the fight. On a prolongation claim, concurrency is fought on entitlement. On a disruption claim, the contractor's own contribution is fought on quantum — how much of the lost efficiency is attributable to which cause — which is a harder argument but a live one rather than a closed one.

The same three questions, and a harder middle

Week 2 set out the sequence: liability, causation, quantum. Disruption asks the same three and the second is where these claims die.

Entitlement is usually not the problem. Everyone accepts that late information, restricted access or a stream of variations disrupts work; the principle is not seriously contested.

Causation is the hurdle. You have to link a specific employer risk event to a specific loss of efficiency in specific work, and the loss is spread thinly across months. There is no moment where the disruption happened. There is a hundred mornings where a gang arrived and found something in the way.

And the Protocol's answer to that difficulty is a technique rather than an argument, which is next week's subject.

Bundled, and lost

One structural mistake accounts for a large share of disruption claims that fail, and it happens before any analysis starts.

The two claims get merged. A single submission asks for an extension of time and, in the same breath, for the additional cost of working inefficiently, with one narrative and one set of figures covering both. It feels efficient. It is how most claims arrive.

The trouble is that they are proved from different things. The delay half stands on a programme and a critical path. The disruption half stands on hours and outputs, and has no interest in the critical path at all. Bundled together, the disruption argument inherits every weakness of the delay argument — and a concurrency point that legitimately kills the prolongation takes the disruption claim down with it, even though, as above, it should not have.

Keep them separate. Two sections, two sets of evidence, two conclusions. The delay claim can fail entirely and the disruption claim still stand.

Why this is harder than delay

It is worth being honest that demonstrating disruption sits closer to an art than a science — considerably more so than analysing delay.

Delay analysis has a network to calculate in. Whatever the disputes about method, there is a model, a critical path, and arithmetic that produces a number. Productivity has none of that. No software takes your programme and returns how much efficiency you lost.

Nor is there a single event to point at. The loss accumulates across hundreds of small interruptions, most of which nobody wrote down because individually none of them seemed worth a letter.

Which leaves one route. The proof is hours: booked by trade, against an activity, in a location, on a date. Cost & Cash Week 10 built the ledger those hours land in, and Week 6 argued the allocation sheet was the most valuable and worst-kept record on any site. This is the week that argument was for.

Without those records a disruption claim does not become harder. It becomes a different and much weaker kind of claim, which is where the rest of this phase goes.

Practical insight

Take one activity on your job that has clearly cost more than it was priced at, and try to answer a single question: how many hours went into it, and how many were in the estimate?

That comparison alone is not a disruption claim — it is the weakest form of the argument and the other side will say your estimate was wrong. But it tells you the size of the problem, and it takes an afternoon.

Then ask the harder question: can you split those hours into a period when the work ran normally and a period when it didn't? If you can, you have the beginnings of something considerably stronger.

And if the honest answer is that your records cannot separate the two, that is the finding. Fix it this month, on the activity with the most people on it, before the disrupted period you will eventually want to prove has already happened.

Key takeaways

✔ Disruption is interruption to the flow and sequence of work, leaving it less efficient than it would have been.

✔ A delay may cost nothing; disruption, once established, always carries a direct financial consequence.

✔ Work can be disrupted on a job that finishes exactly on time, and that loss is the one most often never claimed.

✔ It hides in three ways: on non-critical work, absorbed by extra resources, or spread thinly across the whole job.

✔ Concurrency does not defeat a disruption claim the way it defeats prolongation; it moves the fight from entitlement to quantum.

✔ Bundling the two claims into one submission lets the delay argument's weaknesses sink the disruption claim with it.

✔ Entitlement is rarely the problem — linking a specific event to a specific loss of efficiency is.

✔ There is no network and no software; the proof is hours booked by trade, against an activity, in a location, on a date.

What's coming next

If the loss cannot be calculated from a model, it has to be measured by comparison — and the strongest comparison available is not with an estimate, an industry study or another project. It is with your own crews, on your own site, during a period when nothing was in their way. Next week is the measured mile: how it is built, what makes a comparison period clean, and why it is the technique the guidance points to first.