Take the delay out. See what remains.

Take the delay out. See what remains.

Week 2 introduced the but-for test as the ordinary way of thinking about causation: remove the event, and ask whether the delay still happens. This method is that test turned into a procedure.

Build a programme of what actually happened. Identify the delay events inside it. Then pull them out, one at a time, and let the calculation tell you when the job would have finished without them. The distance between that date and the real one is the claim.

It is the most immediately persuasive idea in the subject. Nothing hypothetical is inserted. Nothing is projected forward. You start from facts and remove things, which feels like the opposite of modelling.

That feeling is worth interrogating, because it is where the trouble lives.

What it does not need

Something unusual first, because it explains why this method survives at all.

It requires no baseline. Not a weak one — none. A job with no accepted programme, or one so defective that Week 5's checks fail it outright, can still be analysed this way. It also requires no update series.

Of everything in this phase, this is the only method that needs neither the plan nor the contemporaneous record of the plan. It needs one thing: an as-built good enough to carry logic. That makes it the technique of last resort which isn't, in itself, a bad answer.

The residue rule

Now the property that makes this method behave differently from every other one.

You collapse the events you have identified. Anything you have not identified stays in the programme, still pushing the completion date out. And if a piece of the remaining delay cannot be shown to be the employer's, it is treated as the contractor's.

Read that as an incentive rather than a rule, because that is how it operates. The analyst is pushed to find and model every delay event that can be found — including the contractor's own, because leaving one out doesn't hide it. It simply sits in the residue, and the residue is presumed to belong to you.

That is an unusual and rather healthy pressure. Most methods reward selective attention. This one punishes it.

The static logic problem

Here is the technical objection, and it is the one that decides whether the analysis holds.

To collapse anything you first need as-built logic: an arrow saying this activity waited for that one. Week 7 established that those arrows are inferences rather than records. This method then does something the earlier ones don't — it makes them load-bearing, because the collapse propagates through them.

And the logic stays fixed. It is the same before the collapse and after it. But a job without the rock would not have been built in the same order; the contractor would have resequenced, taken different work first, moved the rig somewhere else. Remove a delay in reality and the critical path shifts. Remove it in this model and the critical path is held in place by arrows drawn from a job in which the delay did happen.

So the method answers what the recorded sequence would have produced without the event — not what the contractor would actually have done. Those are different questions, and on a job with any real resequencing they give different answers.

The order you remove them in

One more thing sits underneath the arithmetic, and it is easy to miss because the software never asks.

Done well, the collapse is iterative: you remove the employer's events and read a date, then remove the contractor's and read another, and the comparison between those runs is what separates the two parties' contributions. That is the method at its best, and it's the reason it can isolate one from the other at all.

But when both sets of events overlap the same stretch of programme, the sequence in which you strip them out changes what each one appears to have caused. Take the employer's out first and the contractor's delay is left holding the date. Take the contractor's out first and the employer's is. Neither run is wrong; they are answers to slightly different questions, and a report that shows only one of them has quietly chosen a side.

Show both. Where they differ is not a flaw in your analysis — it is the overlap itself, surfacing, and it is the subject the next phase opens with.

Three things it cannot see

Following from that, a short list worth having in mind before choosing it.

It cannot tell you what anybody intended at the time. There is no contemporaneous view in it at all; every judgement is made looking backwards from the end.

It cannot identify the contemporaneous critical path — which path was actually driving in March. That information lives in the updates, and this method does not use them.

And it cannot distinguish a contractor pacing its work — deliberately slowing because something else was holding the job anyway — from a contractor causing critical delay. Both look identical in an as-built, and the difference between them is worth a great deal of money.

Where it belongs

The honest summary in the literature is that there are more situations where this technique doesn't apply than situations where it does. That is a strong statement about a method in common use, and it comes with a sensible qualification: it suits work that runs as a line.

On a tunnel, a road, a pipeline or a bulk earthworks job, the as-built logic is close to self-evident. You cannot line a section before you have driven it. The arrows are given by the work, not by the analyst, and the central weakness largely dissolves.

On a building with a dozen trades working in parallel, in a sequence that changed four times, the arrows are the analyst's opinion. The subtraction is then being performed on that opinion, with CPM arithmetic lending it a precision it hasn't earned.

The practical test is one question: on this job, would two competent analysts working independently draw the same as-built logic? If the answer is obviously yes, the method is available. If it is obviously no, everything downstream is contestable.

Running two on purpose

One piece of advice from the literature that applies well beyond this method.

Where acceleration or an early completion programme is in issue, it is worth deliberately running both a modelled technique and one built only on as-built data, and putting both in front of the tribunal. Not as hedging — as information. Two methods resting on different assumptions give a decision-maker a range and, more usefully, show where the assumptions are actually doing the work.

If both methods land close together, that convergence is the strongest thing in your report. If they diverge badly, you have learned something important about your own case before the other side explains it to you.

Practical insight

You can test whether this method is even open to you in half an hour, without building anything.

Take ten consecutive activities from a disputed period and, for each, write the reason it started when it did. Not the date — the reason. Waiting on the preceding activity. Waiting on a delivery. Waiting on access. Crew was elsewhere.

Now count how many of those reasons come from a document rather than from somebody's recollection. If most of them are documented, you have as-built logic and this method is genuinely available. If most are recollection, you can still produce the analysis — the software will not stop you — but what you will have produced is a collapse of your own assumptions, and it will be described that way by the person reading it.

Key takeaways

✔ The method makes the but-for test mechanical: build the as-built, remove the events, read the date that remains.

✔ It needs no baseline and no updates, making it the only technique here that survives having neither.

✔ Unidentified delay stays in the collapsed result and, if it cannot be shown to be the employer's, is treated as yours.

✔ That rule rewards finding every event, including your own, which is unusual among these methods.

✔ As-built logic is inferred, and this method makes those inferences load-bearing by collapsing through them.

✔ The logic stays static while a real job would have resequenced, so the answer describes the recorded sequence rather than the likely one.

✔ Where both parties' events overlap, the order of removal changes the result; run it both ways and show the difference.

✔ It suits linear work where the arrows are given by the job, and is contestable everywhere else.

What's coming next

Five methods, five sets of assumptions, five defensible answers. That is the phase, and it ends by facing what it has built: two competent analysts, the same records, and numbers weeks apart. Next week is why that happens, why it is not evidence of bad faith, and what a claim can do about it — which turns out to be more than most reports attempt.