Chapter 7: The six methods of delay analysis

The Protocol sorts the six methods in two ways. The first is where the analysis starts. What the Protocol calls cause and effect methods start from an event and then work out its effect. The other family, effect and cause methods, start from the critical delay and then look for its cause (SCL 11.4(a)).

The difference matters for a reason of ordinary causation. To prove after the event that one thing caused a delay, you have to rule out the other candidates, including the contractor's own problems. A method that models only the events the analyst chooses cannot do that. So when delay is assessed after completion, the Protocol says effect and cause methods are generally considered to be more forensically reliable, because they look at every potential cause. During the job the position reverses. The certifier has to decide an extension of time before the event's full effect is known. A cause and effect method gives an answer then, without making the certifier "wait and see". That is one of the main reasons the Protocol recommends time impact analysis during the works (SCL 11.4(a)).

The second sorting idea is perspective. Every method has to find the critical path and measure the delay. The Protocol treats these as two separate determinations, and each can be made from a different vantage point. The path can be found as it looked at the outset, as it looked while the job went on, or as it looks from the end (SCL 11.4(d)). The delay can be measured as a forecast of the likely effect, or as the actual impact on the as-built critical path (SCL 11.4(e)).

Time impact analysis and time slice analysis show how the two combine. Both find the critical path on a contemporaneous basis. But time impact analysis then forecasts the event's effect on the rest of the job, while time slice measures what actually happened within each period (SCL 11.4(f)). Whether the contract wants a forecast or a look back is the subject of chapter 6. Here it is enough that each method makes a fixed choice on both, and that the choice shapes its answer.

The table below follows the Protocol's own table (SCL 11.5), with a column added for where each method starts (SCL 11.4(a)).

The model project is the one chapter 2 builds. Its baseline programme runs from site clearance through piling, blockwork, roofing and M&E to final fit-out. The piling rig broke down in week 7, and piling took 6 weeks instead of 4: the contractor's risk. The employer's roof design information came 5 weeks late, having been forecast in week 13 as 4 weeks late. In week 21 the employer instructed an M&E variation that added 4 weeks of work. A second M&E gang won back a week. Fit-out ran 2 weeks long for want of labour: the contractor's risk again. The contractor issued an updated programme every four weeks, and the job finished in week 43.

Three of the six start from the event: impacted as-planned, time impact analysis and collapsed as-built. Each builds the imaginary job described at the start of this chapter, and each answers only for the events the analyst chooses to put in or take out.

Impacted as-planned is the simplest. The analyst adds a sub-network for each chosen event to the logic-linked baseline and recalculates. The movement in the planned finish is the delay (SCL 11.6(a)). It needs only the baseline and a list of events.

Its weakness follows from what it leaves out. It does not consider actual progress (SCL 11.6(a)), so it measures what the event would have done to a plan the job may already have left behind. If the contractor was running late for its own reasons, the event may have cost less time than the method shows. Ramsey J made the same point in Multiplex v West India Quay (TCC, 2006): the method may well show a greater extension than is required. That was an adjudication enforcement case, and he said he was not concerned with whether using the method was an error ([25]). The Protocol treats the method as enough to assess an extension of time only in limited circumstances (SCL 11.6(a)). Examples are where the contract dictates it, or where the events occur right at the outset of the works. On the model it finds 8 weeks, all the employer's (it inserts the roof delay at the 5 weeks it turned out to be). It never sees the piling rig or the fit-out labour, because they were never put into it.

Time impact analysis moves the same exercise into the life of the job. The analyst takes the updated programme current when the event arose, inserts the event's sub-network and recalculates. The delay is the event's effect on the then predicted completion dates. It is the method the Protocol sets out for deciding an extension during the works (SCL 4.12). On the model it finds 5 weeks, all the employer's. The roof information costs only 1 week, because by the week-12 update piling was already 2 weeks late and roof design had room to slip. The method also uses the roof delay as forecast in week 13, 4 weeks, not the 5 it turned out to be.

Its weak spots come from the same feature. Mitigation and acceleration already built into the update can conceal or distort the event's effect. And because the method forecasts, it usually does not capture the delay the event in the end caused (SCL 11.6(b)). That suits an extension of time decided during the works, but not a question about what actually happened. In Fluor v Zhenhua (TCC, 2018) the judge said a prospective analysis is the correct approach for an extension of time. The damages claim before him needed some form of retrospective analysis.

Collapsed as-built analysis works in reverse. The analyst takes the chosen events out of a logic-linked as-built programme and recalculates. The earlier finish is a hypothesis of what might have happened had the delay events not occurred. It is the but-for test done with a programme, and it needs no baseline.

The difficulty is the programme. A detailed logic-linked as-built programme is rare (SCL 11.6(f)), so the analyst usually has to add logic to the record, and the added logic becomes the target. A Scottish judge accepted that an error in one logic link can vitiate the whole programme (City Inn (Outer House) [38]).

The method also has a floor. It measures only incremental delay, because the finish will not collapse further than the next near-critical path. On the model, take out both employer events and the job finishes in week 38: 5 weeks for the employer. Take out the roof information alone and it finishes only 2 weeks sooner, because blockwork, late after the piling, is next in line. Taken out one at a time, the four events save 2, 3, 0 and 2 weeks. That makes 7, not the 9 weeks the job overran.

The other three start from the delay: time slice windows, as-planned versus as-built windows and retrospective longest path. None of them builds an imaginary job. Each finds where the critical path slipped and then reads the records for the cause, so each sees the contractor's delays as well as the employer's.

Time slice windows analysis is the first of the Protocol's two windows methods. The analyst checks, or rebuilds, a series of updated programmes, typically at monthly intervals. Each one shows the critical path in its period and the critical delay status at the end of it (SCL 11.6(c)). The analyst then reads the records to find what caused each period's delay. Where there is a sound contemporaneous programme, Akenhead J said in Walter Lilly v Mackay (TCC, 2012), the experts take what are called time slices (usually every month).

The method is only as good as the updates. The analyst must verify that each one reflects the actual progress of the works and that its forward part is realistic. On the model it finds all 9 weeks: 6 for the employer and 3 for the contractor. It catches the piling delay while piling was critical, and it credits the contractor with the week the second gang won back.

As-planned versus as-built windows analysis is the second windows method. It divides the job into windows framed by updates, milestones or major events. In each window the analyst finds the critical path by a common-sense and practical analysis of the available facts. Actual dates along that path are compared with planned ones, the records are read for causes, and the windows are added together. It needs the least of any method: a baseline, not necessarily logic-linked, and as-built data. The Protocol says it is usually applied when the baseline or the updates are doubtful or too few (SCL 11.6(d)).

Because criticality is found by judgement rather than by software, the analyst has to set out the reasoning (SCL 11.6(d)), and that reasoning is where the method is attacked. On the model it finds 9 weeks: 5 for the employer and 4 for the contractor. Because it uses actual dates, the contractor's recovery is already netted off the variation.

Retrospective longest path analysis starts at the end. The analyst verifies or builds a detailed as-built programme, then traces the longest continuous path backwards from the actual completion date. The key dates on that path are compared with the plan, and the records are read for causes.

The path it finds is the chain that happened to finish last. That is not always what was holding up the job at each earlier moment. The Protocol warns that this as-built critical path is not the same as the contemporaneous path the windows methods find (SCL 11.6(e)). It names the result as this method's limitation: its more limited capacity to recognise and allow for switches in the critical path. On the model the traced path runs through the design chain and roof design, and the method finds 7 weeks for the employer and 2 for the contractor. The piling rig gets no delay at all, although it held up the job from week 6 to week 12.

Thomas Barnes v Blackburn with Darwen shows the blind spot at trial. It concerned a bus station, and was decided in the TCC in 2022. The contractor's expert said he had used the as-planned versus as-built windows method ([108]). In cross-examination he explained, I worked backwards from the completion finishes works.

The steel-framed walls round the central hub finished after the roof coverings. So he treated the walls as critical and discounted the roof coverings from the outset ([137]). The roof had in fact started late, for reasons that gave the contractor no extension ([131]). The judge found his core analysis was deficient. The Council had called it a "retrospective longest path analysis" ([43]), but that was its submission, not the judge's finding.

The six are not a closed list. The Protocol names other methods that may suit particular cases, among them time chainage, line of balance and earned value analysis.

Different methods give different answers because they measure different things, not because someone has made a mistake. There are four reasons for the spread, and each follows from a feature already described.

The first is that the methods ask different questions. A forecast and a look back can part company because the contractor tried to accelerate, re-sequence or redeploy resources in between (SCL 11.4(e)). When a prospective extension and a retrospective assessment differ, the Protocol says this is only to be expected and does not necessarily indicate an error (SCL 12.3). The second is that they use different inputs. Cause and effect methods measure only the events the analyst chooses to model. On the model, impacted as-planned and time impact analysis never look at the contractor's delays, so every week they find is the employer's.

The third is that they find different critical paths. The path at the time and the path traced back from the end are different things (SCL 11.6(e)), and a method that sees only one of them will miss delay on the other. The fourth is how they treat recovery and the next path in line. Methods that use actual dates net off the contractor's recovery automatically; methods that forecast do not. Collapsed as-built stops at the nearest near-critical path.

A real case shows the spread at full size. In 2019 the Supreme Court of New South Wales decided White Constructions v PBS Holdings. The question was whether late approval of a sewer design had delayed a residential development. The two delay experts agreed the as-built programme, then disagreed on method, and on how each had applied the other's ([15]). The claimant's expert used as-planned versus as-built windows and found a critical delay of 240 calendar days ([16]). The defendant's used collapsed as-built and found that at best the job would have finished only 19 days earlier ([17]). Hammerschlag J observed that both cannot be right, and that it was not inevitable that either was.

The judge took advice from a court-appointed adviser, agreed by the parties. Acting on it, he held that neither method is appropriate in that case, and decided causation on the facts. Two cautions keep the case in proportion. It is a single Australian judge at first instance, and the delay findings were an alternative: the claim had already failed because no breach was proved ([179]). A later Queensland court treated White as a decision on its own facts, not a statement of principle (Santos v Fluor [2025] QSC 184, Part 12 [334]-[336]).

Different methods do not always diverge. In Great Eastern Hotel v John Laing (TCC, 2005) the two experts approached their analyses differently ([67]). Yet the principal critical path determined by each expert was broadly similar, and so was the total delay ([68]). So the spread is a reason to ask which question each method answered, and how well it used the records.

Names do not help as much as they should. AACE International publishes the American counterpart to the Protocol, and it says that current usage of these names throughout the industry is loose and undisciplined. It lists "windows analysis" as a common name for five of its nine methods (AACE 29R-03, MIPs 3.2 to 3.5 and 3.7). English judgments show the same looseness. In Costain v Haswell (TCC, 2009) the experts treated "time impact analysis" and "windows slice analysis" as one method ([176]). In Mirant v Ove Arup (TCC, 2007) the judge accepted a textbook's view that windows are not a method in themselves ([131]).

So when an expert says windows analysis, ask which one. AACE's own division is a good place to start: is it observational, reading the programmes as they were, or modelled, inserting or taking out events and recalculating (AACE 29R-03, s.1.4)?

Because each method answers a different question from different records, no single method can be right for every case. The Protocol's first edition preferred time impact analysis. The second edition says there is no longer a preferred delay analysis methodology where the analysis is done long after the event. Time impact analysis remains its recommendation during the works. AACE goes further and says it is impossible to recommend one method as the "best" (AACE 29R-03, s.5).

Instead, the Protocol lists what should drive the choice: the contract, the nature of the events and of the project, proportionality, the time available, the records, the programme information and the forum (SCL 11.3). Most of that list is about evidence.

In practice the records choose first, and the table above shows how. Three methods need a logic-linked baseline: impacted as-planned, time impact analysis and time slice. Two of them also need updates or progress information. Collapsed as-built needs a logic-linked as-built programme, which the Protocol says is rare. If the contractor never kept a properly linked programme, the field narrows to as-planned versus as-built windows and retrospective longest path, unless someone adds logic to the record. That is why chapter 14 on records matters as much as this one.

The contract may choose too. The Protocol treats a method dictated by the contract as one case where even impacted as-planned may be enough to assess an extension of time (SCL 11.6(a)). AACE says a contract that mandates a method takes the choice largely out of the hands of the forensic schedule analyst. More often the contract fixes the question rather than the method. Some clauses call for a forecast of the likely delay. Others, like the milestone clause in Tata below, ask what actually caused a date to be missed. An analysis that answers a different question will not help, however well it is done, as the next section shows.

Whatever the method, the Protocol sets an overriding objective: the conclusions must be sound from a common sense perspective (SCL 11.2). The test I would apply before any report is served is simple. Does the analysis find a large critical delay that nobody noticed at the time? A large critical delay shows itself at the time, in meetings, reports and letters. If none of them mentions it, the likelier explanation is that the analysis is wrong. In Tata v DBS, a 2024 TCC case about an IT contract, one expert's analysis did exactly that. Constable J held that a delay no witness and no document had identified reflects its unreliability.

Before either side spends heavily, the Protocol recommends that the parties try to agree an appropriate method (SCL 11.8). It suggests that a failure to consult might be taken into account on costs. That is the Protocol's own suggestion, and no reported decision applying it has been found. The choice itself is the expert's. AACE says it should be the analyst's, not the client's, though it expects the analyst to recommend it to the client and its lawyers first (AACE 29R-03, s.5).

The law's approach follows from the nature of the question. Whether an event delayed completion is a question of fact. The party that says it did has to prove it, and an expert's analysis is evidence towards that proof, not a substitute for it. Akenhead J said in Walter Lilly that it must be for the Court to decide as a matter of fact what delayed the Works and for how long. He said both experts' approaches there, one to a lesser extent, "involved in reality doing the exercise that the Court must do": a factual analysis of what probably delayed the works ([381]). The Protocol is consistent with this. It does not claim to be a statement of the law, and it must give way to the contract and the governing law (SCL Introduction, para B). Three consequences follow.

The first is that no method is required, and loyalty to a named one is not the test. In Thomas Barnes each side attacked the other expert's method. The contractor's expert was said not to have followed the method he named. The Council's expert was cross-examined on the basis that time slice analysis was more suitable for a prospective than a retrospective analysis ([108]). The judge found that both arguments had some force ([109]). But he declined to treat the Protocol's list as a set of rules ([110]):

Nor would he attach much importance to whether each expert had loyally followed the method he selected ([109]).

Fit and execution still count. A method that is manifestly inappropriate for the particular case, or a material departure from the stated method without a proper explanation, can reduce the weight given to the expert's opinion ([110]). The judge preferred the Council's expert despite some force in the complaints about him, finding his evidence overall more convincing ([46]).

The second consequence is that the analysis must answer the question the contract asks. In Tata v DBS clause 7 required a backward-looking analysis of why a milestone was actually missed ([199]). The contractor's expert's first analysis tracked movements in the forecast go-live date across successive plans, treating them as a proxy for actual critical delay ([171]). He did not consider whether a forecast delay later became an actual one ([172]). Constable J held that this kind of prospective analysis does not adopt a recognisable and logical method for the question the clause asked ([199]). He found one of the expert's approaches circular, because its value depended on the very conclusion the expert arrived at ([175]). The Court of Appeal later heard an appeal on a different point only (DBS v Tata (CA) [3]).

The third consequence is that an analysis is only as good as the records it was run against. The contractor's expert in Thomas Barnes had the roof records. The judge said that had he read them with the care the Council's expert did, he could not have failed to observe the delay in starting the roof works. Yet he did not even include the roof coverings as a possible critical activity ([133]). In Great Eastern Hotel one expert's theory about the critical path "collided with reality on site", in documents and photographs he chose to ignore ([308]).

The tribunal decides the facts, but it will not build the claimant's case for it. In Tata neither expert's analysis gave a reliable basis for the court to carry out its own as-planned versus as-built exercise ([220]). The contractor had not discharged the burden of proving when it would have met the milestone ([222]). The judge added that he might have been tempted to make adjustments if the contract had not required a date to be proved ([222]). The burden of proof is taken further in chapter 6.

The same holds in adjudication. An adjudicator may not make good the gaps in one party's case without giving the other side a proper chance to deal with that. So an adjudicator who intends to use a method neither party put forward ought to inform the parties and to obtain their views (Balfour Beatty v Lambeth (TCC, 2002)).

Other courts take the same line. In White the judge acted on the view of the court's adviser. A method's appearance in the Protocol does not give it any standing, and a logical method's absence does not deny it standing ([191]). That is an Australian decision, and persuasive only.

A word on weight. Every English decision on method in this chapter was made at first instance. Such decisions are persuasive and often followed, but they do not bind other High Court judges or the Court of Appeal. I know of no English appeal decision on the choice of a delay analysis method.

Chapter 15 follows the analysis into the hearing. The same analysis decides whether two delays were concurrent, the subject of chapter 8.