Description

This is another method that uses project segmentation by windows. However, unlike APABW, it depends on the contemporaneous schedules issued by the contractor.

Updates are used to quantify delays or gains in the work fronts and to identify the activities that form the critical path. It is a retrospective method because delays are analysed after they have already occurred. The definition of the critical path is based on the progress forecasts on the dates when the updates were shared and agreed by the parties.

It requires an electronic version of the baseline agreed between the parties, periodic contemporaneous schedules of sufficient quality and enough information to explain the cause of critical delays.

It is an observation-based methodology, because delay events are not created or removed; instead, updates are compared with each other without modification. There is a variation of this method in which, because the updates are not of sufficient quality and there is enough reliable information, the analyst reconstructs the contemporaneous schedule and then uses it in the analysis. Reconstructing or modifying schedules carries the risk of not being accepted because of impartiality concerns. It is also easily criticised by the other party unless there is a large amount of information supporting the recreated schedule.

Because contemporaneous schedules are used and the logic may have changed, it is considered a dynamic-logic method. The intervals used are usually monthly, or fortnightly for short projects. These are the most common intervals agreed in construction contracts for submitting updates.

Each programme shows the contemporaneous critical path, taking into account changes in activity logic and possible acceleration or delay recovery measures. Therefore, delays can be analysed against the real project critical path at that particular time, provided the schedule is prepared realistically and not for commercial purposes.

Because of the dependence on schedules created throughout the project, software has been developed to detect changes between two schedules in relationships, durations, calendars and other elements, in order to check whether the planning reflects reality.

Example

The following images illustrate the process for carrying out the analysis with this method.

First window: a delay to structure A moves the forecast project completion four calendar days later.Second window: structure B becomes critical and adds one calendar day to the project delay. Third window compares updates 2 and 3: architecture B is on the critical path and the arrow indicates two calendar days.Final window: actual execution matches update 3 and adds no delay to the forecast completion date. Overall baseline-versus-actual comparison: seven calendar days of delay, comprising four, one and two days in the first three windows.

Steps to follow

To perform delay analysis using this methodology, the following steps should be followed:

  • Locate the programmes used to measure progress and delay events. The validity of each one must be checked and the critical activities identified. Not all updates may be usable in the analysis, but all of them must be considered.
  • Compare each update with the next one in order to determine which events may have impacted the critical path. It is important to verify that completed activities reflect the real progress of the project and that the planned sequences and durations are reasonable, realistic and achievable.
  • Identify changes in the critical path between what was planned and what was actually executed, as well as changes in construction logic and activity durations.
  • Identify who is responsible for the delays and time gains in the period studied.
  • Continue until project completion and add the results from each previous period to obtain the total impact on the project.

Problems with using the plan as a commercial tool

Time Slice Analysis is a temporal segmentation technique widely used in expert reports for delay analysis. However, when carrying out the analysis, its complexity must be considered because it is a hybrid delay analysis method.

It can be defined as hybrid because, on one hand, it uses updated programmes (modelling), and on the other hand it compares those programmes with what actually happened (observational). Updated programmes can be considered modelled because they may include prospective changes, whether acceleration or delay.

Consequently, it combines prospective and retrospective elements to analyse delay events and project critical delays comprehensively. The technique is based on comparing the impacted or rescheduled programme with the updated programme within each time interval, in order to clarify the excusable and compensable delay periods. It should be noted that its application may not be advisable in situations where the contractor alters durations and relationships between remaining activities to show better project progress than actually exists. Unfortunately, this situation is more common than it should be.

Example with activities A, B and C: updates include delays and recovery plans; actual completion is ten days later than the baseline.

In the first window, Activity A has been completed; however, instead of taking 10 days, it has taken 15 days. Therefore, the project has been impacted by 5 days of critical delay. The contractor, in order to maintain the contractual date and without having performed a delay analysis to determine who is responsible for those 5 days, decides to reduce the duration of the next activity. The total delay at the end of the first window is: 5 days for Activity A and minus 5 days for Activity B; therefore, total delay is 0 days.

In the second window, Activity B has been completed; however, instead of taking 5 days, it has taken 15 days. Therefore, the project has been impacted by 10 days of critical delay. The contractor, in order to try to maintain the contractual date and without having performed a delay analysis to determine who is responsible for those 10 days, decides to reduce the duration of the next activity. The total delay at the end of the second window is: 10 days for Activity B and minus 8 days for Activity C; therefore, total delay is 2 days.

In the last window, Activity C has been completed; however, instead of taking 2 days, it has taken 10 days. Therefore, the project has been impacted by 8 days of critical delay. The total delay at the end of the project is: 2 days corresponding to the second window and 8 days for the last window; therefore, total delay is 10 days.

Because of unjustified reductions in activity durations, the project's critical delays are 2 days due to Activity B and 8 days due to Activity C, even though Activity C is the only activity that was completed within the time agreed in the baseline.

To avoid this situation, all relationship and duration changes that have been made could be analysed so that those modifications are considered and the conclusion can be reached that 5 days correspond to Activity A and 5 days to Activity B. That enormous additional work means that, if the updates have been substantially altered, As-Built vs As-Planned Windows Analysis is a better option.

Strengths

  • It allows possible replanning to be considered, provided it is done realistically and not for commercial purposes.
  • It is the most appropriate method for analysing delays and their causes while the project is in execution.
  • If the updated programmes are reliable, they provide a large amount of information that is easy to understand. The credibility of the analysis can also be improved if it is shown that the parties involved used the updates for decision-making and project management.
  • It allows delays to be assessed on the contemporaneous critical path, provided that activity dates, relationships and durations are not manipulated.
  • If contemporaneous programmes do not need to be recreated, it is a quick method to execute and, thanks to segmentation, a high level of detail can be achieved in the analysis.

Weaknesses

  • It depends entirely on schedule updates, which are normally not very reliable. Contractors commonly use schedules as a commercial tool and the quality level is usually not as high as in the contractual programme.
  • If updates do not exist, they must be recreated, making it a slow method that is easy to criticise. Expert personnel in the most common planning software is also required.