Chapter 2: The programme: critical path and float

The standard vocabulary comes from the Society of Construction Law's Delay and Disruption Protocol (2nd edn, 2017). The Protocol is guidance, not law, but courts and experts use its words. It defines a programme as a tool that divides the works into a series of activities, each with a duration and logic links to the activities before and after it. Together they form a network. It is otherwise known as the schedule.

A logic link says how two activities depend on each other. The ordinary link is finish-to-start: activity B cannot start until activity A has finished. Start-to-start and finish-to-finish links also exist, and a link can carry a lag, such as the time concrete needs to cure (SCL Protocol, Appendix A). The logic is what turns a list of tasks into a model. Change one duration and the software can work out everything else that moves.

The bar chart on the site office wall is only the picture. The Protocol notes that one programme may be depicted in a number of different forms, and the bar chart is the commonest. A bar chart printed to PDF shows where the bars sit. It does not show why they sit there. The logic, the working calendars and any imposed dates live in the planning software's own file, the native file. That is why the Protocol asks for the programme in its native form, not just as a PDF (1.43), and why chapter 14 spends time on files.

Modern standard forms ask for exactly these ingredients. FIDIC's 2017 Red Book requires the programme to show all activities, logically linked, with earliest and latest dates, the float and the critical path (Sub-Clause 8.3(g)). NEC4's Engineering and Construction Contract requires each programme submitted for acceptance to show the order and timing of the operations and provisions for float and time risk allowances (cl 31.2). Chapter 16 compares the forms.

The guide uses one invented project throughout, and it is illustrative only. It is a four-storey office building with thirteen activities, measured in weeks. Six are design activities and seven are construction. Each design activity releases a construction activity: Roof design must finish before Roofing can start, M&E design before M&E installation, and so on. The contractor plans to finish in week 34. The contract requires completion by week 36. Step through the live figure below to see it first as bars, then with its logic.

Why does the longest chain fix the finish? Every activity has to be done, and linked activities have to be done in order. So the job cannot finish before the end of its longest chain, however quickly everything else goes. That chain is the critical path. The Protocol defines it as the longest sequence of activities through a project network, the sum of whose durations sets the overall project duration. There may be more than one. A delay to any activity on it will, without acceleration or re-sequencing, extend the job. The Protocol calls that a critical delay.

Judges reason the same way. In Walter Lilly v Mackay (TCC, 2012) Akenhead J took two outstanding items of work. A will take 20 weeks and B will take 10. It is A which is delaying the work, because B will finish first. B could take 19 weeks and it would still be A that held up completion ([378]). He said that looking to the longest sequence is the approach most delay experts use when there is a usable baseline programme.

Finding the path is arithmetic, done in two sweeps through the network. The forward pass starts at week 0. It gives each activity its earliest start and earliest finish, on the rule that an activity starts as soon as everything before it has finished. The backward pass starts from the end date and works back. It gives each activity the latest start and latest finish that would not delay the end. The gap between an activity's latest and earliest dates is its float. The chain with no room to move is the critical path. The Protocol calls these calculation rules the critical path method (Appendix A).

On the model project the forward pass reaches week 34 through the construction chain. Site clearance takes 6 weeks, Piling 4, Blockwork and walls 5, Roofing 5, M&E installation 7 and Final fit-out 7. That is 34 weeks with no slack, so the chain is critical. The design chain runs alongside it with a little room. Roof design can finish in week 14, but Roofing cannot start until week 15 anyway, because Blockwork and walls runs to week 15. So Roof design has one week to spare.

Software marks as critical the activities with zero float. That works on a fresh programme measured to its own finish. The Protocol's test is more general: activities with the least float are generally considered to be on the critical path (8.1). The difference shows once a job falls behind a fixed date. The float figures then go below zero, and the critical path is the chain with the lowest value, not the one showing zero. AACE International, an American cost engineering body, takes the same view (29R-03, s.4.3.A.2). It reports that most practitioners regard the longest path as the true critical path (s.4.3.A.1).

Float is room to slip, and three kinds matter. The first, total float, is how far an activity can slip without delaying the end of the job. The second, free float, is how far it can slip without delaying the next activity. Total float belongs to a chain; free float belongs to the activity alone. On the model project, Pile design, Blockwork design, Cladding design and Roof design each show one week of total float, but none has any free float. It is the same week, shared along the chain. Whoever uses it first uses it for everyone downstream. The third kind is the gap between the planned finish in week 34 and the contract completion date in week 36. AACE calls this project float. It is also called terminal float.

Which end date is float measured to? Planning software measures float to the programme's own finish, week 34, unless the planner imposes a finish date. The live figure does the same. It shows Roof design with one week of float and shows the two weeks up to week 36 separately, as project float. The Protocol's glossary measures total float to the contract completion date instead. On that definition Roof design has three weeks. Check which one a float figure uses before you argue from it.

Float can also hide inside an activity. A contractor that expects its own trades to lose time may pad their durations. The Protocol calls this activity float, and its time risk allowance is the same idea: contingency for risks the contractor carries itself. Padding inside a duration never appears in a float column. The Protocol also accepts contingency shown as separate activities, and says either approach is prudent planning (8.7).

Criticality is not a fixed label. It is the result of a calculation, and the answer changes whenever an activity takes longer or shorter than planned. Suppose the employer is late with information the roof designer needs, and Roof design takes 8 weeks instead of 4. The first week disappears into Roof design's float, and nothing else moves. The next three weeks push Roofing, M&E installation and Final fit-out back, and forecast completion moves from week 34 to week 37. The critical path has switched. It now runs through the design chain (Pile design, Blockwork design, Cladding design and Roof design) into Roofing, M&E installation and Final fit-out. Site clearance, Piling and Blockwork and walls were critical a moment ago. Now they have three weeks of float.

This is where the arithmetic becomes law. An extension of time needs delay to completion caused by the event relied on. That is ordinary causation. The first week of late roof information caused no delay to completion: the job would have finished in week 34 either way. An event that causes no delay to completion earns no time for it. The other three weeks did delay completion, and those are the weeks the contractor can claim. The Protocol puts it the same way: delays that move completion must, by definition, reside on the critical path (11.4(b)). How many of the three weeks become an extension depends on the clause, as the next section shows.

A programme can have two critical paths at once. Delay Cladding on the model project by 4 weeks and it uses all its float. The finish stays at week 34, but two chains now run into Final fit-out with no slack: one through Cladding, one through Roofing and M&E installation. Delay Cladding by 8 weeks and the finish moves to week 38.

Real projects show the same movement over months. Thomas Barnes v Blackburn with Darwen (TCC, 2022) concerned a new bus station. Remedial work to the steelwork of its central hub was delayed, and so were the roof coverings. The Council's delay expert said that until around 9 December 2014 there was enough float in the following work for the steelwork delay to be non-critical ([141]). Before that date the roof drove completion; after it, the steelwork did. Asked by the judge, he accepted that it was possible to have more than one critical path ([142]). That was the expert's answer to a question, not a finding of the court. In Tata v DBS (TCC, 2024) Constable J found that neither expert's analysis identified the true critical path; both workstreams were likely contenders for criticality from the third window onwards ([221]).

Chains close behind the critical one are called near-critical paths. They have so little float that a modest delay would make them critical. They matter most in concurrency: AACE says the purpose of quantifying them is to reduce the effort of identifying and analyzing potential concurrent delays. The Protocol uses the phrase but does not define it. AACE offers four criteria. Under one of them, the analysis interval, a monthly interval gives a threshold of 30 calendar days above the critical path's float (s.4.3.B).

Whether experts should analyse near-critical paths at all is contested. In Santos v Fluor, a 2025 first-instance decision of the Supreme Court of Queensland, the parties had agreed a delay method taken from the Protocol. The court noted that the Protocol's windows analysis does not require the identification of near critical paths. It held that the referees could treat one expert's reliance on them as a reason to reject his evidence more generally (Part 12 [361]), though they had not found that it invalidated the rest ([362]). That decision is persuasive at most in England. I know of no English decision on the point.

A moving path brings two more warnings. First, the activity that finishes last is not necessarily the one that delayed the job. The last activity often takes exactly as long as planned; what matters is what delayed its start. The final clean of a site is usually last, but rarely the cause. Akenhead J made the same point in Walter Lilly: it is not necessarily the last item or area of work which is finished last which causes delay ([379]). He also said you cannot identify the last of a number of events and say it caused the overall delay. You have to consider what critically delayed the works as they went along ([365]).

Second, nobody can read the critical path straight off the as-built dates after the event. The past path has to be inferred from the record rather than calculated. AACE therefore calls the activities that drove completion the controlling activities, not the critical ones (s.4.3.C). Chapter 7 describes the methods experts use to do that.

Finding the critical path tells you which activities were driving completion. It does not by itself tell you why they were late, or who was responsible. In Thomas Barnes the judge accepted the float analysis from a theoretical delay analysis viewpoint, but held that it did not answer the question of causation. Both the steelwork and the roof were in fact holding up the hub finishes over the same period ([140], [143]). The law requires no particular technique: it is for the court to decide as a fact what delayed the works and for how long (Walter Lilly [377]). Chapter 6 takes that up.

When an employer's event uses up float, who bears the loss? The contractor says it planned the float in, as a cushion against its own mistakes, so it owns it. The employer says the contractor needs more time only if the contract completion date is at risk, so the project owns the float. The Protocol records both arguments and notes that float "ownership" causes particular arguments in disputes about extensions (8.1).

The clearer way to see it is that float is not property. It is the gap between two dates, and the real question is which date the extension clause protects. An extension moves the date from which liquidated damages run. HHJ Humphrey Lloyd QC put its purpose this way in Royal Brompton [246], discussed below: to avoid the contractor being liable for liquidated damages for delay it is not responsible for. It also fixes a new date, so both sides know where they stand. Suppose the clause asks whether the employer's event will delay completion beyond the contract completion date. An event that only uses float causes no such delay, so causation gives nothing, and on that wording the float is likely to be spent first. Suppose instead the clause asks whether the event makes the contractor's planned completion later. The same event does cause that delay, and time will probably follow. The Protocol draws the same line between the two kinds of wording (8.2).

JCT Design and Build 2016 wording is of the first kind. The amended JCT Design and Build 2016 clause quoted in Mace v Baltic (TCC, 2026), clause 2.25.1.2, asks whether completion is likely to be delayed beyond the relevant Completion Date ([44]). JCT withdrew its 2016 edition on 31 March 2026 in favour of the 2024 edition.

NEC4 is of the second kind on its face. A delay to the Completion Date is assessed as the time by which planned Completion is later than planned Completion as shown on the Accepted Programme (cl 63.5). Measured that way, the contractor keeps the gap between its planned Completion and the Completion Date. That is a reading of the words, consistent with the Protocol's analysis (8.2), not a decided point. FIDIC's 2017 Red Book gives an extension if and to the extent that completion is or will be delayed (Sub-Clause 8.5). It does not say whether delay is measured against the Time for Completion or the programme's planned completion.

On the model project the difference is two weeks. Treat the late roof information as an employer's risk event, with no other delay and no concurrency. Roof design takes 8 weeks, and forecast completion moves from week 34 to week 37. Under the JCT-type wording, completion is delayed beyond the contract date of week 36 by one week. The extension is one week, to week 37. Under the NEC4 wording, planned Completion moves by three weeks, so the Completion Date moves three weeks, to week 39. The contractor keeps its two weeks of project float. Same event, same programme: one week or three, depending on the words.

Where the contract gives no clear answer, the Protocol recommends a default. On that default, an extension should be granted only to the extent that the employer's delay is predicted to reduce to below zero the total float on the critical path (Core Principle 8). Float is not for the exclusive use or benefit of either party unless the contract says so (8.5). So, on the Protocol's approach, there is no extension merely because an employer's delay takes away float on a particular activity (8.6). The Protocol says this is consistent with current judicial thinking, but it cites no case. Nor does it say that "the project owns the float". It gives that only as the employer's argument (8.1).

American practice has a firmer default. AACE treats network float as a shared commodity between the owner and the contractor, absent contrary contract terms, and project float as owned solely by the contractor (s.4.3.E). That is US practice, not English law.

No English court has given a general answer. Two first-instance judgments come closest, and both are narrow. Royal Brompton v Hammond (TCC, 2002) is a later judgment in the hospital litigation described in chapter 8. HHJ Humphrey Lloyd QC considered the JCT clause used on that project, which measured delay against the completion date. If there is unused float there for the contractor's benefit (rather than held for provisional sums and the like), he said, the architect is bound to take it into account. The employer is ultimately entitled to the benefit of float the contractor does not need. But he suggested the architect should tell the contractor that, if later events that carry no extension would put it into liquidated damages, an extension not exceeding the float would be given ([246]). These were remarks, apparently in passing, in a negligence claim against the employer's own consultants.

Ascon v McAlpine (TCC, 1999) is about sub-contractors, not an employer. The main contractor's programme had five weeks of float. The main contractor argued that it could use the float to absorb its own delays and other sub-contractors' delays in preference to Ascon's. HHJ Hicks QC held that argument misconceived. The float protected the main contractor from liquidated damages. Having taken that benefit against the employer, it could not claim against sub-contractors as if the float did not exist ([92]). In a tentative example about sub-contractors equally at fault, he added that the allocation should not be in the gift of the main contractor ([93]). He decided the point without dealing with concurrent liability or contribution ([94]).

Ownership and criticality are different questions. In Thomas Barnes the contractor's counsel answered the Council's float evidence with a principle from Keating. A contractor cannot be criticised for using up float, since float is for the benefit of all the parties ([144]). The judge said that was not an answer to the point that the float kept the steelwork delay non-critical until 9 December 2014. Who bears the loss of float is one question. When an activity became critical is another.

Under a completion-date clause, the order of events matters. If the employer's delay comes first and uses up all the float, a later contractor's delay that would otherwise have been harmless puts the contractor into liquidated damages. The Protocol spells out this effect (8.3). On the model project, late roof information stretches Roof design from 4 weeks to 7. Forecast completion moves from week 34 to week 36, the contract date, so no extension is due. Later the contractor loses a week on Final fit-out. Completion slips to week 37, and one week of liquidated damages follows. Without the employer's delay, the same lost week would have finished the job in week 35, inside the contract date.

Two related points belong to other chapters. The Protocol recommends that a contractor prevented by the employer from finishing early should in principle be paid the costs directly caused, though it gets no extension. That applies only if the employer knew of the plan to finish early when the contract was made, and the plan was realistic and achievable (chapter 13). And a contractor that deliberately slows non-critical work to match an employer's critical delay is using float by another name: pacing, covered in chapter 8.

A project produces many programmes, and it matters which one you use. The tender programme shows how the contractor priced the job. After award the contractor proposes a baseline programme, the plan against which progress will be measured. In the Protocol, once the certifier accepts it, it becomes the Accepted Programme. Each month or so the programme is brought up to date with actual progress and any revised logic, and becomes an Updated Programme. The final update should show the as-built programme. That may be no more than a bar chart of actual start and finish dates, with no logic at all (SCL Protocol, Appendix A). NEC4 uses "Accepted Programme" differently: each programme the Project Manager accepts replaces the last (cl 11.2(1)).

Each update is a snapshot of where the critical path ran on that date. The Protocol treats the most recent Updated Programme as the primary tool for assessing an extension during the job (4.7). It says float is best identified from a properly prepared and regularly updated programme (Core Principle 9). So no version should be overwritten (1.59), and each should be kept in its native file. The standard forms build updating in. NEC4 requires a revised programme at the interval stated in the Contract Data, showing actual progress and how the contractor plans to deal with delays (cl 32.1, 32.2). FIDIC 2017 requires one whenever the programme ceases to reflect actual progress (Sub-Clause 8.3).

When the updates stop, the analysis gets harder. In Walter Lilly both experts accepted that the absence of a contemporaneous critical path programme from February 2007 was an underlying problem ([380]). Chapter 14 deals with keeping the record.

Is falling behind the programme a breach of contract? Usually not. The contractor's main obligation about time is to finish by the completion date. The contract prices lateness at that date, usually through liquidated damages. How the contractor gets there is its own business unless the contract says otherwise. Courts are slow to add interim obligations by implication, because a term is implied only where the contract does not work without it. A contract with a completion date and liquidated damages works without one. Staughton J stated the general principle in GLC v Cleveland Bridge, as quoted in Leander [33]. In his words, a contractor is entitled to plan and perform the work as he pleases, provided it finishes by the time fixed in the contract.

Leander v Mulalley (TCC, 2011) shows the principle at work. Leander was a groundworks and concrete-frame sub-contractor on a development in Lewisham. The sub-contract documents included an Activity Schedule with dates. Mulalley, the main contractor, withheld £131,078.12, saying Leander had not kept to those dates ([1]-[2]). By the hearing Mulalley accepted that the dates were not contractually binding; the judge later called the opposite assumption untenable ([59]). Mulalley argued instead for an implied term to proceed regularly and diligently, measured against the schedule. Coulson J refused to imply it. All the authorities pointed the same way: the courts have been very reluctant to imply terms about the timing of performance before the completion date ([39]). Mulalley also argued that Leander's work was obviously on the critical path. The judge's answer was that in the absence of any agreed and binding programme, the critical path might lie anywhere ([53]).

A contract can make the programme bite. FIDIC 2017 says the Contractor shall proceed in accordance with the Programme, subject to its other obligations, and lets the employer's people rely on it when planning their own work (Sub-Clause 8.3). NEC4 uses the Accepted Programme to time the employer's own obligations. Failing to give access, or to provide something, by the date shown on it is a compensation event (cl 60.1(2), (3)). The Project Manager may refuse a programme that is impracticable or unrealistic (cl 31.3). Where the Contract Data identifies no programme, a quarter of the Price for Work Done to Date is retained until the contractor submits one. That first programme must show the information the contract requires (cl 50.5). Even an accepted programme is not, in the Protocol's view, a contract document or a warranty that it can be achieved (1.57). Chapter 16 compares the forms in detail.

The extension of time machinery in chapter 3 puts these ideas to work. Whether to forecast delay or look back at it is the subject of chapter 6. How experts find the critical path after the event is in chapter 7.