The method the contract asks for.

The method the contract asks for.

The fragnet is the same. The event is the same. The arithmetic is the same. One thing changes, and it changes almost everything.

Instead of inserting the delay into the original baseline, you insert it into the programme as it stood immediately before the event happened — updated with actual progress to that date, with the logic and remaining durations as the project then understood them.

Look at what that fixes. Last week's method could not see the contractor's own performance, because the model contained no performance at all. This one starts from a programme that has already absorbed nine months of it: the slippage, the resequencing, the durations that turned out longer. The event lands on the job as it actually was.

What the change buys

Four things, and they are the reason this method is preferred wherever assessment happens during the works.

It runs on contemporaneous intentions rather than original ones. Logic and durations for the remaining work reflect what the team believed at the time, not what somebody hoped before the site was cleared.

It uses the dynamic critical path. Week 4 established that criticality belongs to a moment; this method asks the question at that moment rather than assuming the baseline's answer held for three years.

It can be done while the job is running, which means the answer arrives when it is still useful and when the people who know what happened are still on site.

And it corrects itself. At each update the programme is reset to actual progress, so an error in one window does not compound through the next. The analysis is re-anchored to reality every month, which is a property none of the purely theoretical methods have.

Why the two protocols argue about it

Week 9 introduced the two reference documents. This is the method they disagree about, and the disagreement is more interesting than a technical dispute.

The SCL Protocol is a prospective document. It expressly prefers this technique for estimating the impact of change as the project runs, and the principle underneath it is that entitlement ought to be claimed and settled while the event is still recent. The purpose is to stop disputes maturing into the kind of exercise this track exists to describe.

The American guidance is expressly forensic. It gives equal weight to all the techniques and declines to say which ones courts prefer, or which are more accurate.

So each is criticised for exactly what the other considers a virtue: the Protocol for leaning too heavily on one method, the American document for refusing to lean at all. Both criticisms are fair, and neither is a reason to ignore either. Before arguing about which is right, find out which question your opponent is answering.

What it still cannot do

The improvements are real. The method remains, at bottom, a model.

It still produces a theoretical answer to a hypothetical question: what this event was forecast to do, from where the job then stood. That's a better hypothetical than last week's, and it still isn't a measurement.

It cannot identify actual concurrent delay. It can show approximate concurrency — where employer and contractor events overlap in a window — but a predictive model cannot, by itself, establish what genuinely ran alongside what.

And there is a consequence for the money that people discover late: a prospective result may not line up with the cost records at all. You have an entitlement expressed in forecast days, and a ledger expressed in what was actually spent, and reconciling the two is work nobody budgeted for. Both of the methods in this phase so far share that problem.

Cause-based and effect-based

It is worth naming the family properly here, because it explains the shape of the rest of this phase.

This method, last week's, and the subtraction method still to come are all cause-based: you identify the events and let a model calculate their effect. The methods built from the as-built are effect-based: you start from what happened and work back to the most likely cause of each piece of it.

Cause-based methods are cleaner to explain and easier to attack on their assumptions. Effect-based methods are harder to explain and harder to dismiss, because they begin with facts. That is the trade the second half of this phase is about.

What doing it properly costs

Here is the part that gets underestimated in fee proposals and overestimated in optimism.

The method needs a programme updated to the moment before each event. Where monthly updates exist, some of that is free. Where they don't, the analyst has to build intermediate programmes — assessing percentage complete, remaining durations and any logic revisions for every activity, at each of those moments. Records rarely support that to the day, so each intermediate programme carries its own judgements, and every one of them has to be transparent or the whole thing collapses.

With a handful of large events that's manageable and defensible. With sixty small variations it becomes a project in its own right, and the honest advice is to use something else.

One more rule worth carrying: the longer the window and the longer the fragnet, the more the result drifts from what the as-built eventually shows. Short windows keep the analysis honest, because the correction at each data date is small enough to be seen.

The rule that catches people

A quiet consequence of the self-correcting property, and it works against the contractor.

At each update, the programme is reset to actual progress. Gains and losses arising from the natural progress of the work are not employer events — and delay in a window that nothing explains is, by default, the contractor's. Silence isn't neutral in this method. It's an allocation.

Which is another way of saying that a thin update series does not merely limit your options. It hands over the unexplained months.

Even the prospective contract has doubts

One last complication, and it is a useful corrective to the idea that prospective assessment is settled.

The NEC family is the most committed to forecasting: compensation events are assessed on forecast cost for work not yet done, with a defined division between forecast and actual. It's the prospective philosophy expressed as a contractual mechanism rather than as guidance.

Even there, the question is live. A Northern Ireland High Court decision has favoured assessment on actual cost over forecast in the circumstances before it, and the commentary treats it as significant rather than an aberration.

Take from that only what it will bear. Prospective assessment is a strong principle with a real tension inside it, and anybody who tells you the profession has settled which way to look hasn't been reading.

Practical insight

On your current job, take the single largest variation or delay event of the last year and try this properly, once.

Find the last programme update issued before that event. Check it is the submitted one, and that you have the native file. Then build the fragnet: what the event required, what it came after, what it held up. Insert, re-run, and write down the movement in the forecast completion date.

Then compare that number to what you claimed at the time, if you claimed anything. The gap between the two is the most instructive number in this exercise. It's usually a gap, and it's usually in the direction of having claimed too little, too vaguely, and too late.

The exercise takes a morning. It also tells you whether your update series can support the method at all, which is worth finding out on an event that isn't yet in dispute.

Key takeaways

✔ The only difference from last week's method is the insertion point: the programme as it stood immediately before the event.

✔ That single change lets the contractor's own performance into the model and puts the question on the dynamic critical path.

✔ The analysis re-anchors to actual progress at each update, so errors don't compound across windows.

✔ The SCL Protocol prefers this method because it is trying to prevent disputes; the American guidance declines to prefer anything because it is trying to analyse them.

✔ It remains a model: still a hypothetical, still unable to establish actual concurrency, and its forecast days may not reconcile with the cost ledger.

✔ It suits a few large events; with many small ones each needs its own intermediate programme and the analysis becomes a project.

✔ Unexplained delay in a window defaults to the contractor, so gaps in the update series give ground away rather than merely limiting options.

What's coming next

This method asks its question one event at a time. The next one asks it one period at a time, taking the job in slices and finding out what was driving in each — the technique that runs directly on the update series Phase B spent a week defending, and the one that comes closest to describing the job rather than a model of it.