Delay analysis methods: what each one needs from your programme
By Roman Bazelchuk | NEC Accredited Project Manager | APMG Project Planning and Control
Founder, NEC Planning Solutions Ltd
A delay claim is being prepared, and the first argument is about method. Each side favours the one that suits its case, and a lot of expert time can go on defending the choice.
The Society of Construction Law Protocol lists six delay analysis methods. Which one is available to you is decided by the records you kept, not by which you prefer. And on an NEC4 contract run as written the question rarely arises, because clause 63.5 already sets how delay from a compensation event is assessed.
Much of what is written about delay analysis is written by lawyers, for lawyers. It is good on what each method proves and what a tribunal has made of it. It says far less about the half that decides whether any of it is possible: what the programme has to contain, and what records have to exist, before a method can be run at all.
That gap matters because the decision is made years before anyone reaches for a method. A project that kept logic-linked monthly updates has most of the methods open to it. A project that kept a baseline and a photograph album has far fewer, and rarely the one it would have chosen. By the time the dispute arrives the choice has already been made by the filing cabinet.
This piece covers what the six methods are, what each one needs from the programme, and why NEC narrows the field to one until the contractual process breaks down. It does not re-cover the NEC machinery itself, which is set out in the guide to NEC delay analysis and extension of time.
The six methods, and the question each answers
The Protocol's second edition, published in 2017, lists six methods. It also dropped the first edition's preference for time impact analysis where the analysis is done long after the event.
Impacted as-planned asks what effect an event would have had on the completion date assuming everything else went exactly as planned. It models cause into a baseline and never looks at what happened afterwards, which is both its speed and its weakness.
Time impact analysis asks what the likely effect of the event was, judged from the moment it arose. It impacts the event into the programme as it stood at that date, so it is prospective in outlook but contemporaneous in position.
Time slice windows analysis asks what the actual critical path was through the works and what caused delay to it. It divides the job into windows and reads the critical path from the updates as they were at the time.
As-planned versus as-built windows analysis asks the same question, but builds the answer from the baseline and the as-built record rather than from contemporaneous updates. Same destination, different vehicle, and it is the one to reach for when the updates are thin.
Retrospective longest path analysis asks what the as-built critical path was, viewed from the end, and what caused the delay to it. Both the critical path and the impact are determined after the fact.
Collapsed as-built asks the but-for question: absent the event, when would completion have been achieved. It removes events from a logic-linked as-built programme and observes what the date does. It is sometimes called modified as-built or but-for analysis.
Delay analysis methods and what each needs from the programme
This is the part the legal commentary leaves out, and it is where a claim is usually won or lost long before anyone argues about method.
Impacted as-planned needs only a logic-linked baseline and a set of events to model. It is the least demanding method and, not coincidentally, the least persuasive, because it takes no account of what actually happened. A tribunal is likely to ask what the job was really doing.
Time impact analysis needs the baseline, the update programmes or progress information to bring it forward to the date of the event, and the events themselves. Without genuine updates it collapses into impacted as-planned wearing a better name.
Time slice windows analysis needs the baseline and a run of update programmes across the period. The updates are not supporting evidence here, they are the method. Where they were produced late, produced in batches, or produced without logic, the method cannot be run honestly.
As-planned versus as-built windows analysis needs the baseline and as-built data rather than updates, which makes it the practical choice on a job where the updates are unreliable but the site records are good.
Retrospective longest path analysis needs a baseline and a credible as-built programme. Collapsed as-built needs an as-built programme that is logic-linked, which is a considerably higher bar, because many as-built programmes are built as a record of dates rather than as a network.
Read that list against your own project and the picture can be uncomfortable. Time slice windows, the method that reads the critical path from the record as it was, depends most heavily on disciplined monthly updating. Which is the same discipline that keeps a programme from losing its integrity in the first place.
Your records choose the method, not your preference
The Protocol's second edition is explicit that no single method is preferred for retrospective analysis. One size does not fit all, and the choice turns on the facts of the case and what evidence exists.
In practice that resolves into a simple test. Where contemporaneous updates were kept properly, time slice windows is open. Where they were not but the baseline and the site records are good, as-planned versus as-built windows still works. Where both are weak, the field narrows to retrospective longest path or collapsed as-built, both of which are reconstructions and both of which invite the other side to reconstruct differently.
So the decision that determines your method was taken in month three of the project by whoever did or did not insist on a proper monthly update. Few people saw that as a strategic decision at the time. It was a programme update that felt like administration.
NEC4 has already chosen: clause 63.5 and the prospective test
On an NEC4 contract the menu is mostly theoretical, because the contract prescribes the method. Clause 63.5 assesses delay to the Completion Date as the length of time planned Completion is later than planned Completion on the Accepted Programme current at the dividing date. That is a prospective, time-impact-shaped test, applied to a programme fixed by a date the contract defines, and the mechanics of building that assessment are a separate exercise from choosing between methods.
The consequence is worth stating plainly. On NEC you do not select a method. You operate one, event by event, as the job runs. The Protocol's six become relevant mainly where that operation has failed.
It also inverts the usual advice. Elsewhere the counsel is to keep good records so that you can later choose a strong method. Under NEC the records serve the assessment as it happens, and the reward for keeping them is that you are unlikely to need the menu at all.
When the menu becomes live again
Three failures put an NEC job back into retrospective territory. There is no Accepted Programme, so under clause 64.2 the Project Manager assesses each event on its own assessment of the programme for the remaining work. Events were notified but never assessed, so entitlement accumulated unpriced. Or notification was missed entirely and the clause 61.3 clock ran out, leaving an argument about what should have happened rather than an assessment of what did.
At that point the contractual method is unavailable and you are back on the Protocol's list, choosing from whatever your records will support. The irony is that the projects most likely to arrive there are the projects least likely to have the updates that open the better methods.
Which is why the remedy is procedural rather than forensic. Getting a programme accepted and keeping it current is not paperwork, it is the difference between an assessment the contract recognises and an argument about what the programme should have shown.
The view from the desk
Method selection has become the glamorous part of delay analysis and it deserves less attention than it gets. I have seen more claims fail on the state of the programme than on the choice between windows and but-for, and I have never seen a strong method rescue a weak record.
My position is that the method should be treated as an output of the project's record-keeping rather than an input to the claim. Decide in month one how the programme will be updated and what will be retained, and the method available in year three follows from that. Decide nothing, and the method will be chosen for you by whichever reconstruction your opponent can afford to fund.
And on NEC specifically, the ambition should be never to need this article. A contract operated as written produces an assessment per event, agreed and implemented, and leaves nothing for a method to resolve. Reaching for the Protocol on an NEC job usually means the machinery was not run.
Download the six methods reference
All six SCL Protocol methods on one page: the question each answers, what each needs from the programme and the records, whether it is prospective or retrospective, and what to watch for. Direct download, no sign-up.
FAQ
What are the six delay analysis methods in the SCL Protocol?
Impacted as-planned, time impact analysis, time slice windows analysis, as-planned versus as-built windows analysis, retrospective longest path analysis and collapsed as-built analysis. The second edition of the Protocol, published in 2017, lists all six and makes clear that no single method is preferred for analysis carried out after the event.
Which delay analysis method is best?
There is no best method in the abstract. The Protocol's position is that the choice depends on the facts and on the evidence available. In practice the records decide: good contemporaneous updates open time slice windows, a good baseline and good site records open as-planned versus as-built windows, and where both are weak only retrospective longest path or collapsed as-built remain.
Does NEC require a particular method?
In effect, yes. Under the NEC4 ECC, clause 63.5 assesses delay as the movement of planned Completion against the Accepted Programme current at the dividing date, which is a prospective assessment made event by event rather than a retrospective reconstruction. The Protocol's list becomes relevant only where that contractual process has broken down.
What is the difference between time impact analysis and impacted as-planned?
Impacted as-planned models the event into the original baseline and ignores what happened afterwards. Time impact analysis models it into the programme as it stood at the date the event arose, so it accounts for progress and for earlier events. Without genuine update programmes, time impact analysis collapses into impacted as-planned.
Can delay analysis be done without update programmes?
Yes. Where the baseline and site records are good, as-planned versus as-built windows still works. Otherwise the options narrow to retrospective longest path analysis or collapsed as-built, both of which reconstruct the position after the fact and are easier for an opponent to challenge. Collapsed as-built also needs a logic-linked as-built programme, which many projects never produce.
About the author
Roman Bazelchuk is the Founder of NEC Planning Solutions Ltd, a UK project planning and controls consultancy supporting contractors with NEC programme compliance, compensation event assessments and live project controls. He is an NEC Accredited Project Manager and holds the APMG Project Planning and Control qualification, with a BEng in Mechanical Engineering and postgraduate training in Planning and Control.
NEC Planning Solutions provides contract-aware planning support through a QA-governed delivery model, helping project teams keep programmes accepted, current and commercially useful from tender through to live delivery.
Facing a delay claim and unsure what your records will support?
NEC Planning Solutions establishes which methods your programme and records allow, then builds the forensic delay analysis on the one that holds, with the evidence trail behind it.
To start, send the baseline, the update programmes you have, the contract and its Options, and the question you need answered.
