It can often be challenging to discern, or identify, a critical path on often complex and complicated programming matters.  Once a critical path has been identified by a delay expert, it will undergo scrutiny from an opposing expert, adjudicator, or opposing counsel under cross-examination.

It is therefore of paramount importance to identify a robust critical path that is founded on sound logic, and is supported by the available evidence, such that it is resilient to intense scrutiny. For obvious reasons, identifying the correct critical path is the most important aspect of a delay report.

If the critical path is incorrect, and the opposing expert’s opinion is preferred, then a delay analysis which seeks to identify what caused delay upon that critical path, will simply fall into the ether, along with the instructing parties’ hope for a favorable adjustment via an extension of time award.

The purpose of this article is to provide some practical advice to help a layperson understand critical paths and how delay experts and analysts alike should go about identifying one.

What is a critical path and how is it calculated?

The simplest definition of a critical path can be found within the SCL Delay and Disruption Protocol, as follows:

“[The critical path is] The longest sequence of activities through a project network from start to finish, the sum of whose durations determines the overall project duration”.^[1]SCL Delay and Disruption Protocol, 2^nd Edition, page 62

This definition is perhaps appropriate for a prospective or retrospective critical path, but does not tally with a contemporaneous critical path. Furthermore, this definition perhaps simplifies what can often require months of hard work and numerous detailed analyses to determine what was actually critical. From experience, this simple concept is often convoluted once a delay analyst is immersed within the detail. Furthermore, the critical path can often be difficult to determine, say on projects with limited contemporaneous and/or programming information.

Moreover, as the project progresses, the SCL definition of the critical path needs to be considered contemporaneously. For example, 6 months into the project, the critical path will not be the longest sequence of activities from start to finish, but will be the longest sequence to completion from that point in time, which considers progress achieved to date and any delay events known about at that time which might cause a future sequence to be extended, thereby extending the project completion date.

With the above points in mind, it is important to understand the evolution of critical path analysis. I do not wish this article to become too much of a history lesson, but I think it is relevant to have a brief overview of its humble beginnings. As most construction planners, programmers and delay analysts will be aware, computers use the precedence diagram technique to establish the critical path.

As far as I have been able to ascertain, critical path analysis was first used in the UK in the 1950s by the ICI Group and the Central Electricity Generating Board when it undertook the renovation of its major power plants.^[2]About Time, Delay Analysis in Construction, page 24 Interestingly, the first building project to utilise the critical path method was the ill-fated Twin Towers in New York in 1966.^[3]https://en.wikipedia.org/wiki/Critical_path_method

Back in the 1960s and 1970s, however, the time and effort required to manually input the information into a slow mainframe computer meant that it was out of reach for small to medium-sized firms.

It was only in the late 1980s when off-the-shelf personal computers became readily available, along with the introduction of planning software, that programmes with the ability to demonstrate a critical path became more commonplace.

I shall now provide an example as to how one would calculate a critical path using the precedence diagram technique, to help a layperson understand how programming software performs a critical path calculation.

The evaluation of a critical path through a project was, and remains to be, determined via mathematical calculations using precedence diagrams, which considers interdependencies between activities, as follows:

As seen above, this is a simple example of a project with just five activities. The critical path has been determined by calculating which activities have zero ‘total float’, as explained below, and is represented by the red boxes. Total float is defined as the time by which an activity can be delayed without affecting the project completion date.

If the total float for an activity is zero, then an activity is deemed to be critical.^[4]I would also note that total float can also turn into negative values if dates are constrained within the programme. Constraints can be added in the native planning software to ensure that activities … Continue reading

The first calculation used to establish programming float is to undertake something called a ‘forward pass’, which uses the planned activity period to determine the ‘early start’ and ‘early finish’ dates. In the first activity above, this is 3 weeks, so the early dates for Activity A are 0 and 3. When doing a forward pass, the highest ‘early finish’ figure is passed to the next activity in the sequence (as seen by Activities C and D, where 14 is carried forward, not 9). This is done to calculate the ‘early start’ and ‘early finish’ dates for all activities.  The total duration from the three forward passes to calculate the early finish date in this instance is 19 weeks (as seen by the top-right box in Activity E). 

Once the forward pass has concluded, a backward pass is carried out using planned activity duration to calculate the ‘late start’ and ‘late finish’ dates. The starting point for the backward pass is to use the same early figures in Activity E. This time, however, the lowest figure is passed backwards to determine the ‘late’ dates. In the example above, one can see that the ‘late start’ dates of Activities B and D are 3 and 8.  Using the backward pass, the lowest figure (i.e., 3) is passed back to determine the ‘late finish’ figure of Activity A. 

What does all of this mean? Well, as noted above, any difference between the early start and late start (within an activity) is referred to as total float. When there is no difference between the early and late dates, this means the activity is critical, as it has no float.

As projects become more complicated the number of activities can get into the thousands and, if properly prepared, these activities should all be logically linked. Such programmes become unwieldy, such that manual calculations to ascertain the critical path using the precedence diagram technique (as seen above) becomes impractical. Hence, the reliance upon popular programming software such as Primavera P6, which calculates the forward and backward passes with a click of a ‘re-schedule’ button and calculates the critical path in a matter of seconds.

How are critical paths used when undertaking a retrospective delay analysis?

As explained above, the larger the project, the more detailed and complex the programmes become. Often, certain contracts stipulate that programmes need to be updated^[5]Updated’ in this sense refers to the programmer or planner entering progress information or data into the programme, usually on a monthly basis, and is referred to as the data date. on a monthly basis during the course of the works as a management tool to monitor the status of the works. 

When programmes become unwieldy it can be difficult to identify any slight modifications made in a monthly update, such as increasing an activity duration, shortening other activities, or changing the logic links to create a critical path that might be strategically beneficial.^[6]I would note that specialist software is available to identify any subtle differences introduced from one from programme to another. As noted within the SCL Delay and Disruption Protocol, where there are concerns in relation to the reasonableness or validity of the programmes, an as-planned versus as-built windows analysis would be best suited, as this method is less reliant on programme software. This type of analysis seeks to determine the contemporaneous critical path.

Alternatively, where the programming information is deemed to be “reasonable, realistic and achievable and properly logically linked”^[7]SCL Delay and Disruption Protocol, 2^nd Edition, para 11.6(d)., a time slice analysis can be carried out to determine the contemporaneous critical path. The type of delay analysis to be undertaken is very much dependent on the type and quality of the available information.

Placing sole reliance on contemporaneously updated programmes to form a view of the critical path is not recommended. The data contained within the contemporaneous programmes must be validated by reference to the facts. Sometimes, contemporaneous programmes might not to be properly logic linked and cannot be used dynamically to calculate the critical path without intervention (which I also note is to be discouraged, unless absolutely necessary). It is for this reason that certain types of delay analyses, such as the as-planned versus as-built windows methodology, places less reliance on the programming software and the critical paths contained therein.^[8]SCL Delay and Disruption Protocol, paragraph 11.5(d).

Contemporaneous programmes can be used, however, to demonstrate a change in sequence, acceleration measures, or even introduce activities following a formal instruction or change, which may well alter the contemporaneous critical path. This is why contemporaneous programmes can be used to form the start or end date of a window^[9]I.e., a period of time being analysed of analysis.

In my experience, it is preferable when undertaking a retrospective delay analysis to establish the contemporaneous critical path as opposed to a prospective or retrospective critical path.^[10]SCL Delay and Disruption Protocol, paragraph 11.4(d). For example, a prospective critical path would be used in an impacted as-planned delay analysis. In this method, a suitably logic linked baseline programme will be impacted by delay events to establish the effect on the completion date. 

As stated within the SCL Delay and Disruption Protocol, the limitations of a prospective critical path is that “it does consider actual progress and changes to the original planned intent”.^[11]SCL Delay and Disruption Protocol, paragraph 11.4(a). The protocol does go on to note, however, that this type of analysis might be appropriate as dictated by the contract, or where delay events occurred at the beginning of the works.^[12]SCL Delay and Disruption Protocol, paragraph 11.4(a).

An example of a prospective critical path (without delay events) for a house project can be seen as follows:

Logically, the critical path in this prospective as-planned programme proceeded through the foundations, walls, and after a week of roof installation, through the internal fit-out activity. 

At the other end of the spectrum is a retrospective critical path. This method adopts a view at the end of the project and seeks to identify the longest path (i.e., critical path) through the course of the works via the as-built activities. 

Using the same theoretical example, a retrospective critical path, which takes into consideration what actually happened, would produce a different critical path, as follows:

The first step in identifying the retrospective as-built critical path, is to create a detailed as-built programme.  The critical path is then traced back from the last activity to identify the longest continuous path. As seen in this example, during the course of the works the windows experienced a lengthy delay which, seemingly, went on to delay the internal fit-out activity. As noted within the SCL delay and disruption protocol, a limitation of this method is “its more limited capacity to recognise and allow for switches in the critical path during the course of the works”.^[13]SCL Delay and Disruption Protocol 2^nd Edition, paragraph 11.6(e).

Having established how prospective and retrospective critical paths are considered, this leads me to the contemporaneous critical path, which is also referred to as the actual critical path. 

As the name suggests, the contemporaneous critical path seeks to establish the longest sequence to completion during the course of the works. At various points in time, the contemporaneous critical path considers progress achieved to date and considers information known at the time, that might affect the sequence looking forward, thereby establishing the longest sequence to completion. This approach to identifying the critical path was endorsed by Mr Justice Akenhead in the eminent Walter Lilly vs Mackay case. The judgement noted:

“[The Claimant’s expert] had regard to the likely longest sequence of the outstanding work on a monthly basis as being the primary pointer to what was delaying the work at any one time. This was a wholly logical approach and, indeed, is the approach used by most delay experts when there is a usable baseline programme from which to work”.^[14]Walter Lilly & Company Ltd v Mackay & Anor [2012] EWHC 1773 (TCC) (11 July 2012), paragraph 378

My preference is to ascertain the critical path contemporaneously using the as-planned versus as-built windows analysis, however, the SCL protocol also notes that the contemporaneous critical path can be established using a time slice analysis.^[15]SCL Delay and Disruption Protocol 2^nd Edition, paragraph 11.6(c). The key difference between these two methodologies is that the as-planned versus as-built analysis is less dependent on programming software.

Using the as-planned versus as-built analysis, a review of the contemporaneous facts helps to identify the switch points in the critical path. In this instance, and continuing with the theoretical example, if a contemporaneous view was taken, say on 8 February 2021, then this might provide a different critical path once more. 

Hypothetically, if the contemporaneous documents on 8 February 2021 revealed the contractor had been informed the windows had been delayed by a week (from 1 to 8 February) but that it would commence with the internal fit-out as-planned, as the breather membrane on the roof provided some weather protection, then, logically, the critical path would have remained through the roof, followed by the fit-out works, as follows:

Obviously there are lots of factors and scenarios that can affect the critical path, but these examples simply demonstrate how the critical path can differ depending on the delay method employed, even on a simple project.

The takeaway from the above examples is that there are differing methods in which to establish the critical path, which is dependent upon the information made available to a delay analyst. On balance, if the facts and data are readily available, the identification of the contemporaneous critical path is my favored approach, aligning with the above endorsement of Mr Justice Akenhead.

How is the critical path determined if the programming information is poor?

A common problem faced by delay experts is that the available programming information might not contain sufficient logic links and might not include all the required activities to complete the works.

This is not to discount programming software in delay analysis, they remain to be extremely useful in terms of identifying a critical path, when used with care, sound logic, and contain appropriately correct^[16]AACE International, Recommended Practice, Forensic Schedule Analysis 29R-03 states:“3. Dates of significant activities should be accurate to 1 working day, and dates of all other activities should … Continue reading as-built data.

An alternative method to identify a critical path is by applying common-sense combined with an analysis of the available facts.  This approach comes to the fore when a project is complex and the programmes become unwieldy, such as is often the case for industrial processing plants.

Of importance when identifying the critical path on such projects is to have a logical understanding of how the project was planned to be built and how the different systems interact with one another, for example, the planned approach may well have followed the following sequence: foundations, steelwork, pipework and mechanical plant following by testing and commissioning. If a particular element of mechanical plant is severely delayed, one needs to consider the knock-on effect this had on a particular system and the effect this may have had on testing and commissioning.

Good practice is to have an understanding of how the project was actually built.  A comparison between the as-planned intent and the as-built data is very useful and is a simple exercise which helps to discern the critical path and to identify potential windows of time to undertake the analysis (e.g., identifying when a key element of the works completed, such as foundations, which allowed the succeeding steelwork to commence). It can also be used to measure the extent of delay by comparison to the as-planned intent from a baseline programme.  A health warning here would be to note that the most delayed activity does not automatically mean that it would be critical. 

If the contemporaneous programmes have been ‘sense checked’^[17]In accordance with the SCL Protocol, see paragraph 11.6(c), this would require that “future sequences and durations for the works are reasonable, realistic and achievable and properly logically … Continue reading, the sequences with the smallest total float can be reviewed and interrogated to whittle down the longest sequences through to completion at various points in time (i.e., identifying the top five or so sequences with the lowest total float). This provides a list of candidate critical path contenders such that one can monitor these sequences as progress was achieved, which should be able to be established from data obtained from the contemporaneous documents.

Whichever type of delay analysis is being carried out, one needs to apply common-sense. From experience, a useful tool to help identify the critical path is to logically understand and compare which area of a project had the largest amount of measurable work remaining to undertake at various points in time. This could be pipework, linear meterage of road, railway line, welds etc. For example, if there were 3 independent sections to a railway line project, let’s call them lines A, B and C. If from the outset of the project, the designed lines had the following lengths:

A = 95Km

B = 25Km

C= 75Km

In any event, this common-sense principle seeks to understand which line had the largest amount of work to do at the start and throughout the course of the works (i.e., a practical analysis of the available facts). In this theoretical example, line B (i.e., the smallest line) could have become critical if no progress was made on this line, whilst good progress was made on lines A and C. The creation of an as-built programme would highlight which of the three lines went on to complete last, thereby, demonstrating which line was critical as the project neared completion.

A review of the contemporaneous records can also assist to determine the critical path. The records might identify which section was going to complete last by providing a schedule of forecast completion dates. Obviously if the contractor, or client, was stating that the critical path proceeded through a certain area, and it aligns with the delay analyst’s opinion, then this would be certainly be referred to and included within the expert’s report in order to bolster his / her opinion.

The documents can also sometimes oppose a delay expert’s opinion. If a contractor, or client, was reporting that the critical path was elsewhere and this differs from the expert’s opinion, it is advisable that this should be addressed this the expert’s report, albeit sound and logical reasoning would be required to explain why the contemporaneous view is deemed to be incorrect.

Conclusions

Taking the above into consideration, I submit that when delay experts are considering the critical path, they should:

• Have an understanding of how critical paths are determined using precedence diagrams to determine total float values.
• Appreciate that sole reliance upon the programming data is not advisable.
• Err on the side of caution in relation to contemporaneously updated programmes.
• Validate the accuracy of the progress or as-built data being entered into the programme to ensure that it provides appropriately accurate results. Factually accurate data is of paramount importance.
• Understand how the project was planned to be built versus how it was actually built.
• Appreciate that the most reliable critical path is one that is determined contemporaneously.
• Break the period of analysis into a sensible number of windows of analysis.
• Apply a common-sense approach to the critical path and keep it simple, wherever possible. 

Undertake a practical analysis of the available facts and review all of the available information. The critical path should not be derived from one avenue of investigation, and should be the result of pulling all the threads of information together to form a robust and fully considered opinion.

---