In the summary of delay analysis methodologies featured in the last Trett Digest, I promised a more detailed review of each method in forthcoming issues. In this issue the as-built but for method is considered in such detail as to identify the principles. Issues such as multiple delays, concurrency, 'who owns the float', and the like are not considered.
The as-built but for method relies upon being able to reproduce the programme of works as it was actually built. In addition a detailed listing of the delays to each and every activity and the duration of those delays on the programmed works is essential.

The method relies upon logic linking the activities on the as-built programme including all the delaying events identified. The analysis proceeds by removing the delaying events, one-by-one, from the as-built programme and the difference in the overall programme duration before and after each removal is said to represent the critical delay due to the particular delay item removed. For example, if the last activity in the project happens to be a 5-day additional painting activity, then when this compensable delay is removed, the programme can finish 5 days earlier. Thus, but for the additional painting delay event, the programme could have finished 5 days earlier. Hence the term As-Built But For (ABBF) method.

Once ABBF analysis is underway, the programme no longer represents the real as-built programme but is only a simulation of what the as-built programme might have been had the delay events not occurred. This programme is sometimes referred-to as the Simulated As-Built Programme (SABP).

The process of removing delay events generally starts with the last event on the critical path. The SABP is re-analysed and a new critical path (or paths) is potentially established. The process is then continued until every such delay event has been removed. What is left at the end of the analysis is a programme which represents how the project could have been built had none of the delay events occurred.

As always, the accuracy of the analysis will depend on the quality of the information on which it is based. The more information that can be provided in support of any assumptions made (whether related to activities or logic links) the more credible will be the results produced. Such information will generally be gained from site records in whatever form they exist and the importance of accuracy, completeness and reasonable logic cannot be over-stressed.

Ideally and for the ABBF method to work properly, the as-built programme should be created by using the planned programme as the starting point and then be transformed into the as-built programme by building up delay periods, changes in sequence, changes in duration of contract works and additional work. This will help to produce not only a complete and accurate as-built programme but one which, at the end of the ABBF analysis, represents a reasonable (albeit) alternative 'Contract' programme.

I have provided a simple example of the As-built But For method below. The starting point is the original programme for the works identifying the original intention. It is often the case that this programme will satisfy contractual obligations in terms of form and content. However, this may not be adequate for the proposed analysis. Typically logic and resource requirements will not be identified and may have to be introduced by 'back fitting'. In so doing, a degree of subjectivity will have been introduced that may lead to questions being raised of the whole analysis.
For the purpose of this article the planned programme is a fairly simple one of 27 weeks overall duration and 11 activities as shown on figure 1. This programme contains logic but for simplicity, resources have not been considered here. Resource analysis will be the subject of a separate article.

Ideally programme changes from initial intention through to the 'as-built' programme should be identifiable and supportable by reference to relevant records. Figure 2 indicates the 'as-built' periods for activities on the original programme. The actual period taken to complete is 30 weeks.
Figure 3 shows how the 'as-built' activities are linked together. The logic adopted should be justifiable by reference to actual records. This is the part of the ABBF method that can attract the most criticism for its subjectivity. If the as-built programme is incomplete and/or is too large, then the logic can quickly become vulnerable to incorrect (or preferential!) interpretation. My advice here is to keep the as-built programme as simple as possible.

The reasons for any change in logic should be identified in a narrative in the same way that changes to activities can be identified. These changes in logic may need to be 'removed' from the SABP during the analysis in the same way as delay activities are removed - otherwise the final result may be a programme that does not work.

The critical path is identified in Figure 3 and differs from that envisaged originally i.e. it identifies 'float' on activity numbers 5 and 6. This model represents the 'as-built' programme.

The remaining task is to carry out time analysis simulations on this programme (the 'but for' part) to identify what would have happened had the delaying events not occurred.

In this example for brevity, all of the delay events are considered together. The first task is to effectively remove the delay events by setting their durations to zero.

Figure 4 demonstrates the result after 'zeroing' but before Time Analysis.
When the networked programme is re-analysed, the effect on the completion date can be identified. After the analysis the programme is as shown in Figure 5. It can be seen that this 'but for' analysis changes the critical path back to what was originally anticipated, and the overall duration collapses by 2 weeks to 28 weeks. Thus, 2 weeks delay to completion may be said to be attributed to the delay events.
What is left is 1 week of Contractor's 'culpable' delay (the original finish was week 27). 'Culpable' delay will be considered in a future Digest!

This example is, of course, over-simplistic. In reality there will always be numerous delaying events and in order to press a claim one would need to particularise the delay caused by each delaying event. This will require the ABBF procedure to be carried out for each event (that is to reset each activity duration to zero and re-run the time analysis at the end of each iteration). If the SABP is quite large (e.g. 1000's of activities) this could prove time consuming and really requires the use of CPA software with a programming language.
Although the principles of the ABBF procedure are straightforward, it may involve considerable time in development of the 'as built' programme for analysis purposes. Check list for this procedure:
1. Tender / initial programme - Logic linked and resourced if possible.
2. Regular updates of tender / initial programme with changes to working programmes documented and explained.
3. Records maintained of actual progress, resources, instructions etc.
4. As-built programme developed during project life
5. Identification of actual programme logic with delay related activities separately identified
6. Reset delay activities to 'zero' and re-analyse network.

Pros and Cons of the As-Built But For Method.
I think the three main strengths of the ABBF method are that:-
• The method is based on the as-built programme so it has a 'golden thread' of truth about it which the basic Impacted Method does not
• The 'process' is easy to understand
• The method can be automated giving the approach a degree of 'scientific' kudos.
The weaknesses, however, should be of concern:-
• The user can fall into the trap of relying on the result just because it appears to be 'scientific' and appears to model the 'truth' when it often is neither
• This method is dependent on subjective logic links which were never agreed in any Master Programme (or the like) - so are open to criticisms of subjectivity.
• If the ABBF analysis is performed with no user intervention - issues like mitigation and the relevance of the timing of alleged late information can be ignored - leading to unsustainable conclusions.
• In particular, removing delay events (and logic links) retrospectively (i.e. considering delay events in relation to the eventual as-built programme rather than the progress at the time the event occurred) does not reflect the way the works progressed - so may not be appropriate for most standard forms of contract (e.g. JCT).
• The credibility of this method relies on the accuracy and completeness of as-built programme so it can be a time consuming and very expensive approach.
In future articles, I will give further detailed examples of using delay analysis methodologies.
Roger D. Smith is an Associate Director (Planning)
Trett Consulting, Manchester Office.