Mirant v Arup [2007] - Observations

This post sets out some observations regarding the assessment of delay and critical path analysis contained in the UK case of Mirant Asia-Pacific Construction (Hong Kong) Ltd v Ove Arup Partners International Ltd [2007].

Background

This case involved a damages claim for breach of contract and negligence brought by the Contractor (Mirant) against its Designer (Arup) in relation to failed foundations of a major Boiler Unit constructed as part of a new power station in the Philippines. This was the 3rd in a series of proceedings between the parties, and primarily involved causation and the measure of damages.

The Contact works for the new power station commenced in February 1996 and were to be substantially complete in readiness for plant reliability trials by December 1998, i.e. with 34 months.

The settlement problem with the Boiler foundations arose in mid April 1997, shortly after erection of the steelwork superstructure had commenced – just over a year into the project. Over the next 2 months a way forward on remedial works was agreed, and these were carried out from June to early September 1997. By mid September 1997, erection of steelwork for the Boiler was back to where it was when the settlement problem was originally discovered.

Ultimately the judge found that whilst the Designer was responsible for the failed foundations, the ensuing delay to the foundations and subsequent steelwork was not a critical or dominant cause of delay to overall completion. It was held that other major civil works were already at least 3 months in critical delay when the foundation problem arose, and thereafter continued to worsen as the remedial works were carried out. As such, the damages claim was largely dismissed, with the Contractor only recouping the direct rectification costs.

Critical Path Analysis

In discussing Critical Path Analysis in general terms, the Court provided some useful guidance:-

• The critical path can be defined as “…the sequence of activities through a project network from start to finish, the sum of whose durations determines the overall Project duration” (quoted from BS.6079 – 2.2000 Part 2, 2.41).

• It is unlikely that the critical path can be identified inductively, i.e. by assertion, without the aid of critical path analysis using a relevant programme. This was particularly important in this case as various witnesses were convinced where the critical path lay without such analysis.

• There may be more than one critical path at a particular time.

• It was important to review not only critical path activities, but also those near the critical path to understand their potential to impact the project. Indeed, any retrospective delay analysis was only valid if it was comprehensive and took account of all activities.

• Float “…in a programming sense means the length of time between when an activity is due to start and when it must start if it is to avoid being on the critical path”.

• Critical path analysis is merely “…a tool which must be considered with the other evidence”. In this regard the “…evidence of Programming Experts may be of persuasive assistance”.

• Critical path analysis will “…identify at a given date which important aspects of the Project are falling behind the programme, particularly if they are on or close to the critical path, what if any is the impact on other aspects of the programme and where additional resources need to be placed. It will also demonstrate where activities are ahead of what is planned and enable a decision to be taken on whether planned activities need to be rescheduled”.

• Critical path analysis can also be used as “…a tool for analyzing, as at the given date, what has caused any delay that has occurred and what is the extent of that delay”.

• Two types of Critical path analysis are Windows analysis and Watersheds analysis. In essence “…they represent the division of the overall construction period into smaller periods into which each new set of corresponding progress can be entered into the programme and analysed”.

• Windows analysis compares progress updates of the works programme at regular intervals, normally monthly. These are effectively programme snapshots. This makes it easier to assess overall criticality and the effect of various events within each interval.

• Watershed analysis is similar, but the programme snapshots are less regular, coinciding instead with important project milestones (or benchmarks), which may be several months apart. This method was considered less accurate than the Windows approach because of the longer interval between programme reviews.

Delay analysis undertaken by the programme experts

With respect to the specific analysis carried out by the programme experts in the case, the Court made some further points worth noting:-

• The experts had a difficult task, in part because whilst there was a master programme and revisions thereto, there was apparently no regularly updated programme or critical path analysis of what was driving completion.

• Both experts carried out Windows/Watershed analysis. One expert used 3 programme snapshots, over a period of 19 months (up to 1st fire only). The other expert used 4 snapshots, over a period of 32 months (up to start of plant reliability trials).

• The Court considered one experts’ analysis flawed because it did not continue all the way through to completion (i.e. the start of reliability trials).

• The experts should be careful not to give too much weight to unsupported statements from witnesses of what they thought was on the critical path at any particular time.