Scheduling and the ‘Progress Override v Retained Logic’ Conundrum
With the growing use of project management software to analyse construction delays, comes the often overlooked question – how does the software really work? This is of course a pretty meaty query and way too big for a single article. But within it are some more manageable ‘bite-sized’ issues. One of these is programme scheduling and how out-of-sequence working is rationalized by the software during the scheduling process. Now whilst some might consider the usefulness of this topic limited to the planners’ amongst you, it is important to recognise its wider implications upon defining and quantifying critical path delays.
So what is ‘programme scheduling’?
In a nutshell, scheduling is the process of updating a programme to a certain date during the course of a project (often referred to as the ‘data date’) by incorporating progress information for all activities in the programme up to that point in time. On many projects this is done at least once a month, with the updated programme included in the monthly progress report. The process itself involves adding actual start/finish dates, the percentage complete, and remaining duration of individual activities that have in some way changed over the reporting period. Once this information is added, the programme is scheduled (or rescheduled), calculating new start/finish dates for all activities in the programme according to a bunch of preset logic rules defined by the operator.
The average construction programme invariably contains many thousands of these user defined logic rules. These rules transform a static bar chart into a much more useful dynamic model which can be gradually updated with progress and other changes to assist managing the project and tracking delays. These rules include things like:- (a) logic relationships between activities (e.g. task A must be complete before task B can start); (b) different working-day calendars for specific types of tasks; and (c) resource dependent activity durations.
In addition, they also include a choice between using the Progress Override or Retained Logic options when dealing with out-of-sequence progress of activities (i.e. when an activity progresses in advance of when it otherwise would have according to the prevailing logic rules). When the Progress Override option is chosen, work is allowed to proceed on the out-of-sequence activity immediately and the logic links from its predecessor activities are overridden. If the Retained Logic option is chosen, these predecessor links are not overridden and remain in force thereby governing when the remainder of the out-of-sequence activity will be carried out.
Figure-1 and 2 are included below to help show the difference between these 2 operations.
Figure-1 shows 2 activities, A and B, where activity A was planned to be fully complete before the start of B. This is known as a finish-to-start logic link.
Figure-2 then demonstrates how the software deals with the situation where, during the works, activity B starts before A is complete. If the Retained Logic option is used, the remaining duration of activity B is scheduled to occur after A is complete. In contrast if the Progress Override option is chosen, then the finish-to-start logic between activity A and B is ignored or overridden. In this case activity B is allowed to progress notwithstanding that A is not finished.
The end result is that the Progress Override option leads to an earlier projected finish date for activity B. It also means that activity A is no longer on the critical path at the time of the progress update.
The wider implications of this choice will hopefully become clearer after working through an example. Consider a hypothetical reclamation project with a contract duration of 8 months. Upon commencement the Contractor is to carry out preliminary site investigation of the seabed and then prepare a detailed dredging layout plan. Once this is approved by the Engineer, the Contractor is to proceed with dredging, followed by construction of a rock filled seawall. The final stage is to place sand fill behind the seawall up to formation level. The corresponding programme is set out in Figure-3 below.
Now consider the situation as at the end of Month-2. Say that site investigation and drawing preparation proceeded as-planned. However, whilst generally accepting the submitted dredging layout, the Engineer would not formally approve the drawing until he had ‘checked a few things’. In response the Contractor decided to proceed with dredging and make any minor amendments (if necessary) after final approval was received. By doing this the Contractor was able to progress dredging at the planned rate so that up to the end of Month-2 it was around 30% complete, and there was no actual delay to dredging.
The status at the end of Month-2 can therefore be shown in 2 ways. The first is shown in Figure-4a (using Progress Override) and 2nd in Figure-4b (using Retained Logic).
The most sensible view of status at the end of Month-2 is clearly that shown in Figure-4a. As soon as dredging commenced it became critical, and the ongoing late ‘formal’ approval of the dredging layout dropped off the critical path. The alternative view, shown in Figure-4b, is that progress of dredging was being critically delayed by late approval of the layout drawing. Moreover this delay already amounted to around 10 days. In this situation therefore, the Progress Override option provides the most sensible outcome.
Let’s now take the example a bit further. Assume that the dredging layout is finally approved early in Month-3, but the remaining dredging work is immediately suspended by the Engineer pending a comprehensive design review. Moreover this suspension remains in place up to the end of Month-6. Shortly after dredging is suspended, and with knowledge that this might last for several months, the Contractor carried out some preliminary filling work at the seawall trench. This was done to protect the small section of dredged trench from damage and siltation, and amounted to only 2% of the total filling. The 2 possible outcomes after rescheduling the programme are shown in Figure-5a (using Progress Override) and Figure-5b (using Retained Logic).
Figure-5a and 5b give a very different result compared to Figure-4a and 4b. This time the Retained Logic option produces the most sensible outcome (see Figure-5b). The occurrence of out-of-sequence filling in these circumstances should not override the prevailing logic. Clearly the critical issue affecting progress from the start of Month-3 to the end of Month-6 was the suspension to dredging, and this governed the earliest projected date for completing the Works.
The table below compares the different outcomes produced by the Retained Logic and Progress Override options. It is submitted that the most sensible result is that the 2 events have caused critical delay amounting to 110 days. Moreover this outcome is achieved by using a combination of the 2 scheduling options. Using only the Progress Override option underestimates the impact, whilst the Retained Logic function overestimates it.
The example above is a reminder that slavishly using one or other of the 2 scheduling options discussed here can lead to errors in defining the critical path, as well as the extent of critical path delays. If not treated carefully, this simple programming function can have significant consequences with respect to entitlement to time and money.
