| Date | 26 April 2006 |
|
|
| Judgment | |
|
|
| The Issue | The impacted as-planned method of delay analysis relies upon the imposition of delaying events onto the planned programme and can be used for prospective as well as retrospective delay analysis. |
|
|
| Implication |
This approach is quite simple to apply in practice and can easily be understood, but if it is used for retrospective delay analysis without reference to what actually happened then it is likely to be easily criticised. |
printIn this the third in my series of articles on delay analysis, I consider the impacted as-planned method of delay analysis. This is an approach to modelling delay that relies upon the use of the planned programme and can be used for predicting the effect of an event upon the completion date i.e. for prospective delay analysis as well as retrospective delay analysis. The method The impacted as-planned method utilises the planned programme and impacts delay events onto it. With the delaying events identified and impacted onto the programme in chronological order, the programme is re-calculated to establish the completion date. This process continues until all of the delays have been impacted. The difference between the original completion date and the completion date on each increment of the impacted programme represents the period of delay attributable to the delaying event. The impacting of events on the planned critical path may change the planned critical path as the events are impacted. The approach does not therefore rely upon an analysis of the as-built programme or critical path. However, where this approach is used for retrospective delay analysis, it will obviously be more credible if the outcome of the analysis is cross-checked with any as-built information that is available.  In the programme above, I have used the same basic information as in my previous article but added an activity 4 that is concurrent with activity 3. In the planned programme, activity 4 must be complete before activity 3 can start but has float of 5 days. The delay to the completion of activity 4 of 8 days is impacted onto the programme and uses up the float and causes a critical delay to the completion of the project of 3 days. The as-built programme would not normally be available, but is included above to highlight some of the issues described below. Selection criteria Because in principle this method does not rely on as-built information it can be used for prospective or retrospective delay analysis. A credible retrospective delay analysis should in my view be founded on what has actually happened. However, regrettably, there are many projects that do not keep sufficient records from which to prepare detailed as-built programmes. The SCL Protocol (2002) suggests that this method may be appropriate where there is a good planned programme that has not been updated with progress and the as-built records are poor or nonexistent. This method may also be selected where budgetary constraints limit the extent to which a fuller and more detailed method of analysis may be adopted. Issues This method requires the planned programme to be verified and ideally to be a relatively close reflection of the actual sequence of work. The further the planned programme diverges from the as-built sequence of events, the less credible this method of analysis becomes. The basis upon which the duration and the consequences of a delay are measured should be as credible as possible and ideally be related to the actual resources that were on the site at the time of the event. Since actual progress is not considered, this approach may not demonstrate what actually caused the delay to the project. Instead, this method assumes that the identified delays are causal. It assumes that in every case they are the dominant cause of delay, but this may not be the appropriate approach to resolving causation and in circumstances where there was in fact a concurrent culpable delay, this approach may lead to the wrong result in relation to the concurrent event. The other principal issue is that delays impacted on a sub-critical path may become critical by using up and exceeding the available float in that path, which may not reflect the progress on the real critical path that reflected how the project was built. These points are illustrated by a comparison of the result shown by the programme above and the as-built data. In the as-built situation, activity 2 started late and took 4 days longer such that activity 3 did not actually start until 8 February rather than 2 February resulting from the above analysis. Thus it is likely that the delays to activity 2 were in fact critical to completion rather than the delay to activity 4. On the other hand depending on the sequence of events, it may be that in fact the delay to the completion of activity 4 arose before the actual 4 day delay to the completion of activity 2, in which case the impacted as-planned analysis has properly identified a 3 day critical delay to the project. Advantages The method is relatively simple to undertake, to present and to comprehend, and therefore probably the cheapest critical path analysis based method of analysing delay that may be undertaken. This can also be a useful way of providing simple illustrations of individual events. It can also be a useful approach to separating out the likely effect of an event that has a complex interaction with other events. Disadvantages It is entirely reliant on the validity of the planned programme and can yield different results depending on how events are added to the programme and how any associated logic changes are made. The absence of any as-built information probably means that the durations of each of the delays are theoretical rather than having been extracted from the actual records. However, it should be observed that this a common problem with delay analysis, regardless of the methods adopted, since it is not uncommon to find that it is necessary to make an assessment of the duration of an event based on an assumption about resource utilisation. Further, as already mentioned, the fact that it takes no account of as-built progress means that it totally ignores any contractor culpability that may be concurrent with or subsume the effect of the events alleged to have caused delay. In summary, this approach is quite simple to apply in practice and can easily be understood, but if it is used for retrospective delay analysis without reference to what actually happened then it is likely to be easily criticised.
CJ-0616
|
|||
|
© Brewer Consulting |
|||
 |
|||