Share:

Assembled from a variety of sources, and with thanks to all, this simple outline is one that I hope can be useful as an initial guide for the site or project team.

Introduction

Delays are common. Delay claims are common. They usually arise as a result of events causing progress to slip. They are better settled as soon as possible. Resisting the Owner’s calls to await completion – ‘to see how things turn out ‘ – will improve Contractor’s position and is consistent not only with the SCL Protocol but also the intent of the latest FIDIC contract forms.

Of course, the first step before setting out on a full delay claim is to establish:-
1. what delay has actually been suffered,
2. who is responsible and
3. whether such a claim is indeed feasible and supportable.

At this early stage, it is not necessary to consider costs. Eventually, they will fall out of the result of study almost as a matter of arithmetic, being, for the most of course, a function of the actual delay suffered and agreed. In any event, costs are not the meat of this article.

1.1 Assemble data

The first step in data assembly should be the Monthly Progress Reports. If these have been properly prepared, and not amended by the Owner’s site representative so that they in effect become his report up to the Owner, they will provide a snapshot of the project’s progress and problems encountered in a crisply chronological manner.

The data assembled should also include the Original Baseline Schedule (OBS) and the Project Execution Plan (PEP). The better versions for present purposes are those first submitted.

There is some debate about whether the selected OBS should or must have been approved or not. Given that the process of Owner’s approval can sometimes take months, with comment after and on comments, my general position is that the first submitted schedule is the key document and correct starting point. Logically, that more closely represents the methods upon which the contract price was based.

2.1 Review Original Baseline Schedule (OBS)

Reference to “original schedule” is deliberate. Any revised schedules submitted during the Works are best ignored for analysis of delay claims. Revised schedules at Owner requests are invariably retrospective in that the revised schedule starts from commencement and adjusts planned progress to suit (approximately) as built status at revision date.

2.1.1 Identify how the work was planned to be executed

Together with the PEP, it should be possible to establish from the OBS the originally planned manner and sequence of the Work. This is important as it permits later comparison with the actual schedule and sequence of the Work. Without this it could be difficult to demonstrate that (a) the planned sequence and timing has been altered and (b) that such alterations were not the result of forces outside the control and responsibility of the Contractor.

2.1.2 Evaluate resources (manpower, equipment and material)

In essence, were the resources – labour in particular – adequate for the planned work?

2.1.3 Identify errors in original plan

Apart from inadequate resources, errors might be found in:
a. Float, if any
b. Critical path
c. Logic – leads, lags
d. Planned productivity

3.1 Construct as-built schedule

This may be time consuming to prepare but is an essential tool in delay analysis.

3.1.1 Plot where, when and how the work was actually executed.

In doing this, seeking blame is not the game. Facts are required.

The basic data should be available from the monthly progress reports (MPR). The as-built schedule can show only the start, duration and end of an activity, perhaps also demonstrating periods – gaps – when no work was performed. Logic links will necessarily be absent.

3.1.2 Identify actual manpower used

This data should be available from the MPR’s. It should be non-contestable having been reported regularly. There should be both weekly and monthly records, broken down at least into trades and perhaps also in work areas.

3.1.3 Determine actual sequencing of work

This should appear clearly from the as-built schedule. However, given the probability of events that delay certain activities, leading to broken sequences or non-sequential working, it may be possible to determine that the cause was an intervening event or events.

4.1 As-built schedule analysis

The purpose here is to seek differences between the work ‘as-planned’ and ‘as-executed’ together with the reasons, whether they be relevant events (the fault of the Owner) or otherwise.

4.1.1 Perform critical path schedule analysis

By introducing logic links to the as-built programme it should be possible to determine where the (as-executed) critical path lay.

4.1.2 Study and identify delay events

Review of actual vs planned start dates (and durations) will indicate clearly the activities delayed. The cause of each delay will be evident from other documentation, which might include project memory, MPR’s, correspondence and meetings. A simple layout may be prepared in tabular form as visual demonstration. (NB – not part of this article but available on request).

4.1.3 Analyse planned vs actual manpower

When reviewing planned manpower, it should be the original plan that forms the base. It is probably the case that overall the manpower has increased, but that is not the whole story.

For example, in the early stages, manpower might in fact be less than planned, due to delays elsewhere preventing start of work. There could be productivity issues, usually the result of external events, but also under-estimating may be to blame. Idle manpower might be observed where an activity is delayed by another activity, itself delayed by an external event. In brief, the reason should be sought and found.

4.1.4 Identify sequence changes

Sequence changes (i.e. change in planned method of operation) should be very obvious from the as-built schedule. Typically, they can arise from
(i) direct instruction from the Owner,
(ii) Contractor’s correction of the original schedule,
(iii) attempts – instructed or otherwise – to introduce measures of acceleration or mitigation including working in parallel rather than series,
(iv) late approvals by the Owner or deliveries (of Owner-supplied material) forcing change
(v) other project-specific causes

4.1.5 Isolate critical delay periods

Attempt to isolate critical delay periods (sometimes called ‘windows’): these may have arisen at any time during execution, but of special interest would those in the early stages or where the possibility of mitigation or recovery was not possible.

5.1 Research causal factors

This follows on from item 4.1.2, where the delay events, whether relevant or not, were identified

5.1.1 Identify relevant documents

The obvious documents are typically:
(i) Change Notices (CN’s), rejected CN’s and overlooked changes that never became CN’s.
(ii) Correspondence, especially ‘hidden’ instructions to change
(iii) Minutes of meetings
(iv) Confirmation of verbal instructions
(v) MPR comments
(vi) Comments on 3D model reviews (especially later stages when the operations people start making changes)
(vii) Summary of document transmittals (where design review period exceeded).
(viii) Sequence changes instructed by Owner
(ix) Comments from HAZOP meetings

5.1.2 Interview project team

This is important and needs to be done before the team has left site and moved away. It is later difficult to recapture that project memory.

5.1.3 Prepare chronology

The chronology can be gleaned from the history – written and verbal – and entered onto a form set up along the lines of a very simple table. This will fall into place in chronological order: for a complex project it may take some time to assemble but will be found to be a document of high value and from a factual point of view, incontestable.

From this, every activity delayed is identified and easily explicable to the Owner. If the results become over-lengthy or complex, concentrate on those events with major impact.

5.1.4 Determine responsibility

On the chronology can be assigned responsibility for the delay event.

6.1 Preliminary overview

At this stage, with the as-built schedule analysed for the cause and effect of the various delay events, it should be possible to summarise the findings.

6.1.1 Prepare demonstrative graphics

These findings can probably be summarised graphically. Typically, this could be done by discipline or by zone.

6.1.2 Identify and organise supporting data

For present purposes the supporting data is that which the demonstrative graphics were based upon.

6.1.3 Allocate responsibilities of the parties

Having established the extent of delay, and the party responsible for each delay event, it should now be possible to look at the delay suffered, establish how much is concurrent and how much is solely due to the Owner.

6.1.4 Decide claim strategy

Now is the time to settle the strategy. With the knowledge of how much delay has been suffered – and why – the decision to prepare and submit a claim for EoT can be tackled. Strategic questions to answer might include:-

(i) Can contractor be absolved from a claim for damages for delay (whether liquidated or un-liquidated)?
(ii) How much of the delay can truly be shown to be the responsibility of the Owner?
(iii) What would be the likely amount?
(iv) How long to prepare? Is a ‘fully detailed’ or ‘quick and dirty’ submission preferred?
(v) Is there a time bar in place? Have notices been submitted in time? Or even at all?
(vi) Have any rights been waived by formal agreement? Were they known rights or unknown rights? (Rights unknown cannot be waived).
(vii) If extension of time is rejected by Owner, unjustly rejected, what action would be considered?