This second part of the article considers ‘actual based’ methods of delay analysis, contrasts the theoretical and actual based methods and discusses what factors affect the selection of the appropriate method.
Actual based methods
These methods are characterised by the fact that they focus on determining the delay periods and then assessing which event(s) caused that delay.
As-planned vs as-built method
This is probably the most common method and it compares the original programme intent and the as-built programme to enable an assessment of where delays occurred in any particular period of time. This method is ideal for those projects where it is easy to identify where the main delays arose, for example, from a high level barchart comparing as-planned v as-built activities. This methodology also lends itself to the analysis of relatively small programmes (say up to 50 activities) which can be considered on one page and so viewed altogether. For most complex project disputes, however, this method is only useful for an initial pass.
Having identified delay periods, the next stage is to establish which delay events caused the particular delay periods, how these delay events competed with other concurrent events and whether the delay periods were critical at the time. This may require a more sophisticated methodology.
The main advantages of this method are its simplicity; the fact that it considers what changed in terms of planned intentions; and that it is a ‘visual’ methodology with no manipulation (in contrast with the as-built but for method). It is a relatively low cost methodology and is particularly useful in identifying where the main delay periods probably arose.
The main disadvantage is that for complex projects, with competing delay events and large numbers of activities, the method may not be rigorous enough.
Windows/snap-shot or update method
This method is a more rigorous version of the as-planned vs as-built method but follows the same basic philosophy, that is considering when and where actual delays where incurred. The main refinement is that critical path analysis is used to assess criticality, delay and indeed mitigation.
The as-planned and as-built programmes are first established, along with any revised programmes (each programme must be compatible with the others so that they may be readily compared i.e. they must have generally equivalent activities). These programmes (or the original as-planned programme at least) are then logically linked so that they become critical path programmes. The as-planned programme becomes the model. The overall project duration is then divided into periods in order to make the analysis more incremental. In practice, the increments coincide with the frequency of the progress reporting cycle, say monthly, or with
major milestone events.
For each time period or ‘window’, the duration, progress and logic of the work actually carried out in that month (from the as-built programme and progress records) are imposed onto the as-planned model. If any major planned programme revisions were made in that period, these should also be introduced into the model. The model is then time analysed. The end date is the result of actually progress achieved to date (i.e. up to the end of the window) and planned durations and logic for the remaining work. The difference between the end date from this analysis, and the end date from the previous window or snap-shot, represents the period of delay or mitigation which arose in the current window. Having identified a period of delay or mitigation in the period in question, the remaining task is to assess the causative event or events. This can be done in a variety of ways; by detailed visual inspection (i.e. expert assessment), by creating, impacting and analysing sub-nets (e.g.small critical paths that model a single programme activity in greater detail). The strength of this approach is that it forces the analyst to consider actual progress and revised programme intent in a logical manner. It produces a result which cannot be easily rejected as contrived because it is practical rather than theoretical. Issues such as mitigation, criticality, concurrency and dominance are all taken into account in a transparent manner, leading to better understanding of what occurred and the circumstances at the time.
Impact/update method
This method is an enhancement of the previous method, but is very similar to it. Whereas the window/update method establishes delay or mitigation n each window period and leaves the assessment of causation as a separate debate, the impact/update method introduces the causative event into the delay analysis. That is to say, this method applies events to the as-planned model on a month by month basis (the windows) to derive the monthly entitlement but then considers the actual monthly production, i.e. to contrast the contractor’s actual performance, in terms of culpable delay or mitigation.
A delay schedule is drawn up before the analysis proceeds and this will list the delay events alleged to give rise to the contractual entitlement. For each of the window periods, the delay events that are alleged to have arisen in the period in question are impacted on the planned model and time analysed. The resultant project end date at the end of the window will reflect the notional entitlement, at that time, to an extension of time. The contractor’s culpable delay events that are alleged to have arisen in the period in question may also be impacted on the model and time analysed. The resultant project end date will reflect the additional delay, if any, caused by the contractor in that month.
Following analysis, the progress records are imposed on the planned model and the programme time analysed again. The resulting end date will represent the overall delay to completion actually occurring in that window period. This will allow for excusable delay events, compensable delay events, culpable delay events and contractor’s mitigation due to changes in programme or faster progress.
From these two exercises (the planned model time analysed with delay events and the planned model analysed with actual progress), the analyst is provided with information on causation which can then be debated as to dominance, concurrency, mitigation and so on.
This is a comprehensive method of analysis based on critical path analysis. It considers actual progress and revised programmes, allows for matters of concurrency, dominance and mitigation to be debated, and limits the degree of initial subjectivity to the logic links within the model.
However, the weakness in the method is that it can be expensive to carry out and requires good as-built records. Furthermore, the courts have implied that the assessed time impact of early delays could diminish later on in the programme. This method is recommended by the Society of Construction Law for prospective delay analysis, i.e. for use during the live project.
The methods contrasted
Having described the various methods under the two headings of theoretical based and actual based, I suggest that the methods fall into four basic groups, identified by the approach:
1. The first approach applies to most of the theoretical methods. A model of what was planned is produced, ignoring how the project was actually constructed, and actual events are imposed on the model to see how they may have influenced the end date. Any extended completion date is said to give rise to an entitlement to an extension of time.
2. The second approach is the ‘but for’ methods, which create models of planned intentions or the as-built project and seek to address causation on the basis of assumption. If the employer had not imposed this event or constraint on the contractor’s performance, when would the works have been completed? The fact is, the event or constraint was imposed and the standard forms of contract ask for the consequences of it.
3. The third approach, which historically has been the most widely used and from my experience, is what the lawyers prefer, is the as-planned vs as-built method. Two models of the project are overlaid on each other and the analyst seeks to explain the causes of the variance (possibly using another methodology).
4. The final approach is to re-live the life of the project by considering the programme in incremental stages, by using the window/update or impact/update methods. What these methods are attempting to do is consider events at the time they arose and consider what was the likely entitlement at each month. This can be contrasted with the as-planned vs as-built method which seeks to justify the overall plan with the overall as-built in one step. These update methods are the most extensive analyses.
Choosing a method
What factors may affect the selection and approach adopted?
Firstly, the nature of the project or claim, or the case one is seeking to explain often influences the approach to be taken. Where the case is primarily concerned with justification of time, the more theoretical methods (particularly those relying on critical path analysis) are helpful. However, if the claim is for money as well, an approach based on what actually happened is warranted. This is because recovery of money suggests a positive assertion which the claimant then has the burden to prove in a positive way (and there is an appropriate standard for this). For example, the contractor will have to show what actual resources were on site during the actual delay period, not some theoretical resource level during some notional delay period. However, a more theoretical approach may be acceptable to support the negative of a loosely asserted fact, alternatively to demonstrate mitigation or and although it can be used for analytical purposes by itself, it is said to be cumbersome. Artemis is a powerful package with an integrated database for forensic analysis of project records. However, Microsoft Project only requires a few hours of hands-on learning before it can be used; Artemis requires specialist training courses and years of experience. In addition, one costs £250, the other £5,000. Note also that each software package has its own procedures, rules and methods of operation. Therefore, each delay analysis methodology may have to be applied in a different way. This is important to note if writing method statements for delay analysis. They should not be written around one specific package.
The fourth issue to note is that delay analysis, particularly when using critical path analysis, is fraught with manipulation. For example, a slight but unjustifiable adjustment to logic links can be difficult to identify but can produce the appropriate result for one party. Another typical manipulation is the manner in which events are analysed. A common one is the introduction of additional work by increasing the appropriate activities by a proportional amount equivalent to the extra work. Such approaches usually exaggerate the case. Another example is the sequence in which acceleration.
Secondly, instead of analysing your case by one method, consider using two approaches. In fact, a sign of a potentially weak delays are entered onto the programme.
“Quite often, the approach taken in delay analysis is dependant on the status of the records”
Quite often, the approach taken in delay analysis is dependant on the status of the party’s case is the adoption of a theoretical methodology that does not rely at all on a more factually based presentation.
Thirdly, methodology is often affected by the available software. For example, Microsoft Project, Power Project and Pertmaster are critical path analysis tools but require other software packages for processing data. Primevera is said to be a very good forward planning tool records, or lack of them. This is a governing factor, not just of the methodology selection, but also of the depth of the investigation. An aspect of depth of investigation concerns the numbers of programme activities to be analysed. Although this issue is case specific, my experience is that ten activities are too few and many hundreds of activities too many. On a fairly large project, I would attempt to analyse up to 100 activities. In fact, experience also indicates that programmes with many hundreds or thousands of activities are far too complex to sensibly analyse.
Another point to note is that there needs to be equality between the level of activities being analysed and the progress details available to measure progress. This certainly applies when one is considering the as-built situation which is, more often than not, advisable. There is no point in seeking to measure the progress of a thousand activities on a planned programme if records were only kept of a hundred. In these situations, the approach to take is to produce an as-planned vs as-built comparison which is to the highest level of available consistent detail. For example, consider a ten storey building with then planned activities per floor. Progress has been monitored per floor, but not by activity. In this case, the as-planned vs as-built comparison would be by floor, but where delay is apparent on any particular floor, this can be investigated by seeking to develop the events on the ten activities by reference to other records.
An alternative situation is where the planned programme provides insufficient detail to enable proper analysis of the actual circumstances. In this case, it is normal to develop sub-nets of the planned programme, which analyse in greater detail the manner in which certain aspects of the works would have been constructed and the sequence and timing. In this way, a more intensive analysis is only carried out during those periods where the high level analysis indicates that deeper investigation is warranted. It is not necessary to produce the entire plan or the entire as-built in greater detail.
I have noted above that the most common approach to delay analysis is to contrast the as-planned with the as-built programme and seek to explain the variance. However, it is still necessary to justify the reasonableness of the plan. Otherwise, an alleged delay can be challenged on the basis that there was no delay, only an optimistic plan! This is a point missed from many delay claims. Not only should the claim rely upon the planned intent, but detailed method statements should be used to justify it.
One of the most frustrating situations in delay analysis is having a project which has been delayed but where there is no clear cause. There are lots of potential events: instructions, variations, access problems, resequencing, drawing amendments etc. However, when analysed, each perhaps contributes to a frustration or disruption to progress but there is no major event delaying the project. I believe the Ascon case was of this type. In such situations, it is tempting to apply less robust methodologies, such as the global or net impact methods, in order to demonstrate entitlement (because, for example, changes were repeatedly made and the last instruction, contrasted with the plan, indicates a considerable delay).
Balfour Beatty v Chestermount put paid to this type of approach. The McAlpine Humberoak and Ascon cases have both confirmed that wholly theoretical calculations are unlikely to succeed.
In such cases (that is, where there are many small issues) what is required is an analysis of the actual, realistic impact of each item. This can be a costly process as well as inconclusive, since the individual impacts to not justify the total overrun. With the inability of delay analysis to justify the period of delay, the contractor must argue that the combination of all events resulted in disruption or dislocation to the programme, which itself is measured by the difference between the derived entitlement and the actual. In the Ascon case, it appears that this approach was not successful.
Summing up
The first point to note is that there is often no certain answer to a given set of facts. This is partly because the theories and principles upon which we build our case are incompletely developed, as well as being inexact. Applying the same facts to the different methodologies results in different allocations between excusable and inexcusable delay.
Another point to recognise is that construction contracts frequently throw up the most complex set of related circumstances and to disentangle these into a clear chronology and logic can be difficult, if not impossible. Available records only tell part of the story and memory has to fill the gaps, but opposing parties have contrary recollections of the facts. Hence it is the norm, rather than the exception, that one has to analyse project delays based on two sets of asserted facts. Each set of facts produce different conclusions.
A third point to note is that extension of time clauses in contracts are not prescriptive. They are drafted in a general way and it is not industry practice to pre-determine how delays should be analysed, either in terms of methodologies or in dealing with such factors as float and concurrency. Even if clauses were more prescriptive, the facts of the case would still be argued over.
Case law can be helpful in deciding how to approach delay analysis but often it is so case specific that the facts on your project never quite relate to the decided case. Of course, there are those who say that, given a set of circumstances and a particular contract, there is only one definite, certain answer and outcome, and the other side are clearly wrong! However, one of my colleagues often tells the story of an arbitration case where they lost the issue they knew they would win, but won the issue they considered they would lose. I am sure many
have similar experiences; I do not think my colleague’s experience is unique. It is necessary to acknowledge, therefore, that in delay analysis there is often no clear solution, either in methodology or law. To allege otherwise is generating mythology.
So, how can we maintain a critical attitude towards the case, particularly when some members of the team hold clear and unambiguous views? There are a number of recommended measures.
Firstly, appreciate that the methodologies do have an order of merit. A delay analysis using the global or net methods will produce a result that is closer to mythology than fact, whereas the impacted/updated programme methods, if applied properly, are preferred as they seek to address what occurred/or should have occurred at the time.
A second important step is exemplified by the comment of a Technology and Construction Court judge in a recent case. He said to the delay expert: ‘I hear what you say about the results of your analysis, but, standing back from the facts of this case, have you tested your methodology?’ The point being made was that, if your analysis is built on a particular methodology, you must test its robustness. This can be carried out in several ways. For example, one technique is to employ what has been referred to as the extreme case rule. Apply extreme conditions or circumstances to the analysis. If the methodology holds good for both situations (i.e. it produces sensible, logical answers) it can be more confidently relied upon as being robust. This rule is used by some arbitrators when weighing up the parties’ alternative approaches.
Another test is the small change rule. In this test, small changes are made to the methodology or the analysis to see what happens to the results of the delay impact. For example, if small changes are made to the programme logic, do you get significant changes in the results arising from minor changes to the methodology or the analysis. Such changes may demonstrate a weak methodology.
Finally on critical views, it is important to emphasise that the starting point of delay analysis is the parties’ contract and the contract terms relating to programme, progress, delays and extensions of time. For example, is there an agreed programme; what are the obligations in regard to updated programmes; what is the base case programme; how are delays notified; were particulars provided; is there a condition precedent clause? Very simply, there may be a very strong case in fact, but if a contractor has failed to register its entitlements, will this affect the prosecution of its delay claim or its defence of the liquidated damages claim?
Conclusion
To conclude, methodology is defined as a body of practices, procedures or rules used to engage in an inquiry. Mythology means story telling. The delay analysis methodologies in use today each contain a set of rules which in themselves can be applied in a subjective way. It is not difficult to manipulate a methodology to arrive at the ‘required’ answer. There are many related issues that influence the analysis and these involve the application of personal experience and judgement. Hence, one analysts’ view of a given set of facts will result in a different conclusion from another analyst.
There is no preferred delay analysis methodology suitable for all cases, although some methodologies are more robust than others. The more theoretical the methodology, the weaker the analysis. It is always better to demonstrate what actually occurred, although theoretical approaches can be helpful (particularly for the issues of mitigation and acceleration) but the results should be tested. The extreme case or small change rules are useful techniques for testing the methodology.
The methodologies do not tell you what the results mean, for example, in terms of contractual liability. It is necessary to interpret the meaning of the results. Remember also that delay analysis is only part of the evidential matrix.
Although I believe that delay analysis can be an extremely important aspect of many cases, it is not as precise a science as some suggest. In my view, it is as much an art as a clinical, analytical study. In order to demonstrate this point, I have included a small case study – the Switchroom. I have also included four potential answers, but these are not the only possibilities. I look forward to being told what the correct answer is.
Tony Farrow is an Executive Director and is based at Trett Consulting’s office in the Netherlands
This article was originally published by the Society of Construction Law.
Further information about the SCL and a number of other papers are available on SCL’s website at www.scl.org.uk.