Application Issues of Impacted As-Planned Schedule for Delay Analysis

Abstract

Most construction projects are delayed, and many are subject to claims or disputes. Therefore, delay analysis is a critical component of any construction project to determine who is responsible for delays. This research examines four different techniques for estimating delay impacts using the impacted as-planned (IAP) method. A sample network was introduced as an example to discuss several concerns. The advantages and limitations of each approach were identified, and recommendations were given for each approach. When inserting an activity or activities representing delay events in IAP, it is necessary to use both constraints and logical relations among delay events, their logical predecessors, and successors. Constraints representing the actual date of delay events are the simplest and easiest. However, constraints should not be used in “single insertion” and “inserting only owner- or contractor-caused delay” approach. In addition, in the case of using constraints, it is critical to ensure that the impact of delay events is less than the duration of those delay events. Constraints should be avoided in this scenario, and delay events should be logically connected to their logical predecessors and successors without constraints. This study also identified through an example that inserting delay events only by logic can cause wrong analysis results. The results of this study will be helpful for delay analysts in identifying what kinds of problems occur in IAP methods and how to prevent those problems.

1. Introduction

The main objective of this study is to identify practical issues in applying impacted as-planned (IAP) delay analysis method and to suggest improved approaches to them. Currently there are some disputes on how to apply the IAP delay analysis method in practice. So, this study reviews what kind of different IAP approaches are being used, and investigates what their advantages and limitations are through a sample project network, and suggests how to improve those problems. Most construction projects are delayed [1,2,3,4,5]. Many of them are the subject of allegations or engage in legal battles. As a result, almost every construction project includes construction claims [5,6]. Delay analysis is a critical component of every construction project since it determines who is accountable for delays. There are various techniques for analyzing delays such as as-planned vs. as-built, impacted as-planned (IAP), as-planned but for, collapsed as-built, window analysis, time impact analysis, etc. Each technique has pros and cons in analyzing the delay.

Several researchers have investigated those techniques. By assessing the research related to delay analyses from 1982 to 11 February 2021, two primary research areas were detected in this field, namely, improving the delay analysis methods and resolving the disputes before they occur [7]. Bubshait and Cunningham [2] evaluated three delay measurement techniques (as-planned schedule method, as-built schedule method, and modified as-built method (time impact analysis)) and found that each delay analysis technique may have different results of delay. Stumpf [8] looked at schedule delay analysis and showed how results differed. Kao and Yang [9] compared four windows-based delay analysis methods to identify their advantages and limitations, in terms of the perspectives of use prerequisite, functional capability, analytical procedure, and accuracy of analysis results. Kim et al. [10] suggested that the result of delay analysis was differently produced depending on the type of baseline schedule, update program using as-built data or not, and approach to dealing with concurrent delay and acceleration measures. Based on a case study, Braimah [11] analyzed delay investigation techniques and identified problematic issues and their improvement needs. Arditi and Pattanakitchamroon [12] evaluated the benefits and drawbacks of commonly used delay analysis methods, as well as the impact of several factors on the selection of a delay analysis method. Although much research has been directed toward improving the use of these delay analysis approaches, the continuing difficulties associated with such claims suggest the need for additional empirical analysis into the extent of use of the approaches, their success rates in dealing with delay claims resolutions, and the obstacles affecting their appropriate implementation in practice [13].

Certain considerations must be addressed while selecting a proper delay analysis method because each delay claim is unique, and its characteristics will define which delay analysis method to implement [14]. When selecting analysis methods, it is important to consider the timing of delay analysis and the quality of available data and documents because the delay effect must be quantified using reliable data [15]. The availability of contemporaneous documentation, the quality of available schedules, and the existence of updated schedules are important factors in selecting a delay analysis technique.

There are so many cases where impacted as-planned (IAP) schedule method is the only possible option to analyze delays and who are responsible for the delays. The IAP is not recommended for dispute resolution in courts. However, many construction projects still have only baseline schedule without as-built schedules, which are routinely evaluated, monitored, and updated as a project progresses. In this instance, the sole alternative is to use the IAP. In applying IAP, however, different approaches in their details are being utilized in practice. Each approach has advantages and limitations. This research recognizes and examines some problems in applying IAP to dispute resolution and suggests how to solve them. This research outcome is projected to be helpful for delay analysts in recognizing what kinds of problems occur in IAP methods.

To achieve the research objectives, this study identifies and categorizes four different techniques which are being applied in delay analysis as the name of IAP, and introduces a sample network schedule which is simplified to analytically compare and assess four techniques. With the sample network, a scenario was given about how works have progressed. Based on the sample network and the scenario, delay analyses by four techniques were performed. In discussion, the results of the analyses, the pros and cons of each technique were compared, and the recommendations were given.

2. Impacted As-Planned Method

SCL (Society of Construction Law) [16] defines the IAP method as introducing delay event sub-networks into a logic-linked baseline programme, and its recalculation using CPM (Critical Path Method) programming software to determine the prospective influence these events have on the anticipated contract completion dates revealed within the baseline programme. The numerous delays are structured as activities in IAP and added to the as-planned CPM schedule in chronological order, revealing how the project is being delayed by one delay at a time [17]. For delay analysis, this method simply employs a baseline (as-planned) schedule. The number of delayed days is equivalent the variance between the completion dates of the schedules before and after the impacts [11]. This method does not measure the effect of actual work performed but heavily relies on the validity of a baseline schedule [18]. The basic steps to implement IAP are as follows [14,19]:

• Identify “un-impacted schedule” for delay analysis.
• Insert or add an activity or activities (fragnet) into the “un-impacted schedule” to represent the impact of the delay(s).
• Calculate the new schedule created by the “un-impacted schedule” with the fragnet or activity inserted. The resultant network is considered the “impacted schedule”.
• Compare the project completion date of the impacted and un-impacted schedules to determine the impact of the inserted fragnet(s).

3. Four Approaches

The IAP method is used to calculate the hypothetical impact of those inserted activities on a network by adding or inserting activities that represent delays or changes into a network. AACE (Association for the Advancement of Cost Engineering) International [14] recommends global or stepped insertion. This research focuses on chronological, stepped insertion since it is more generally used. In practice, delay analysis professionals use various approaches in adding or inserting the fragnet (an activity or activities representing the delay(s)) into an as-planned schedule. They can be divided into four categories. The first method involves inserting a single delay event into an as-planned schedule without additional delay events. The second approach is to insert delay events into a network in a chronological order based on the logical relationship with their predecessors and successors, without regard for the delayed events’ actual dates. The third approach is to insert delay events into the network in a chronological order based on logical relation and using constraints based on the actual date of delay events. The fourth approach is to insert delay events caused by only the owner or only the contractor into the as-planned schedule. This research reviews the issues in applying these approaches and identifies improvement needs.

3.1. Sample Network

To analytically assess and compare these techniques, a sample network is introduced. Since a real project network cannot be introduced in this paper, the problems which were identified in the middle of analyzing real big complex projects having up to 5000 activities were dealt through the sample network. A sample network was used for simplification and the instinctive understanding; The schedule is as revealed in Figure 1. It is made of activities A, B, C, D, E, F, and G. Its total project duration is 40 days. Its critical activities are A, B, C, D, and G. Activities E and F have 5 days of float.

The project started as planned, but in the middle of the progress, three delayed events happened. “Delay event 1” was affected by the owner delaying the authorization on the shop drawing for “activity E”. It hindered the start of “activity E” for 10 days from the 11th to the 20th date. Furthermore, the contractor had a labor problem (“delay event 2”), which hindered the start of activity C for 5 days from the 16th to the 20th date. In the progress, the contractor completed “activity F” 3 days earlier than planned. After the finish of activity F, the owner ordered a change (“delay event 3”), which happened for 5 days from the 38th day to the 42nd day, impacting the start of “activity G”. Figure 2 revealed the as-built schedule. The project was 7 days late, as it turned out.

3.2. Inserting a Single Delay Event

To quantify the impact of a single delay event, several researchers and delay analysts argue that it should be put into an as-planned schedule without any other delay events [20]. There are always a lot of delays in real projects. Therefore, inserting all delay events into an as-planned schedule chronologically and analyzing the impact of each delay event sequentially is difficult and time-intensive. For simplicity and convenience, this simplified approach is utilized in practice.

The delay event or the fragnet is connected to logically relevant predecessors and successors when only a single fragnet is inserted into an as-planned schedule. At each evaluation, the impact of each delay event is calculated. The effect of all delay events can be analyzed by repeating this process. The total estimated delay of a project is obtained by adding all delay effects together. The ratio of owner- and contractor-caused delay can be calculated. This approach assumes that the estimated total delay should be equal to the actual delay of the project. Therefore, the summation of the owner-responsible delay is evaluated by multiplying the ratio of owner-caused delay to the actual delay of the project. The contractor-caused delay is also calculated through the same process.

The general process for determining the impact of a delay is as follows: Firstly, only “delay event 1” is added to the as-planned schedule. Figure 3 shows the outcome. It takes 45 days to complete the job. The completion of the project is delayed as much as 5 days. The owner is responsible for the delay, which is classified as the “excusable and compensable (EC)” delay.

Next, as shown in Figure 4, “delay event 2” alone is added. Its total project duration becomes 45 days. Its estimated completion date is delayed 5 days. It is analyzed that “delay event 2” has 5 days of impact. The contractor is liable for the delay, which is classified as “non-excusable and non-compensable (NN)”.

“Activity F” was completed 3 days earlier than as-planned. However, it is not reflected in IAP; only delayed events are added to the as-planned schedule. As shown in Figure 5, the IAP schedule by only “delay event 3”, its total project duration is 40 days. There is no delay because there is no change in the project duration according to the analysis.

In this analysis, (owner-caused) delay event 1 and (contractor-caused) delay event 2 have 5 days of impact respectively when a single delay event is inserted without any other delay events. All of the delays are added up to 10 days. Owner-responsible delay (EC) is calculated by multiplying actual delay by owner-caused delays divided by the sum of all delays caused by the owner and contractors. The same method is used to compute the contractor-responsible delay (NN).

Owner-responsible delay (EC) = 7 × 5/10 = 3.5 days

(1)

Contractor-responsible delay (NN) = 7 × 5/10 = 3.5 days

(2)

This approach is simple and easy to implement but may have some problems. This approach would count the impact of each delay event. As a result, it cannot reflect concurrent delays. This approach would also fail to account for the cumulated impact of previous delay events or any changes. As a result, this approach assumes that the sum of all delays is equal to actual delay of the project and that there is no acceleration.

3.3. Stepwise Insertion without Using Constraints

All delay events are incorporated step-by-step and chronologically into an as-planned schedule using the approach. A delayed event or a fragnet should only be placed into the as-planned schedule by connecting them to logically linked predecessor and successor activities according to Kim and Kwon [21], and constraints should not be used. As shown in Figure 6, they are pointing out that if the delay event (the activity X) is added into the network by using constraints based on its actual start and finish date, the delay of the project completion could be overestimated.

This approach requires adding the delay event with its duration into the network and connecting it to its logical predecessor and successor without changing anything of the as-planned schedule and without considering the actual start and finish date of the delay event. As the constraints reflect the actual date of each delay, but the as-planned schedule does not reflect updated actual progress, this approach needs only the duration of the delay event and logical relation should be employed and that constraint on the delay event should not be given.

The process to analyze delay impact in stepwise insertion without constraints is as follows: The IAP schedule by “delay event 1” is the same as Figure 3. The project is delayed as much as 5 days. The owner is liable for the delay, which is classified as an “EC” type. Figure 7 shows the IAP schedule by “delay event 1” and “delay event 2” on the planned schedule. As delay event 1 modified the critical path, there is no extra delay. Therefore, delay event 2 does not have an extra impact on the duration of the project. Here, delay events 1 and 2 are identified as concurrent delays, which is the type of “excusable and non-compensable (EN)” delay.

“Delay event 3” happened for 5 days, and it had an impact on the start of activity G (Figure 8). To calculate the impact on the duration of the project, the delay event should be added to the as-planned schedule. The delay event 3 happened after “activity F” and had an impact on the start of “activity G”. Activity F was completed 3 days earlier than planned. However, the IAP does not consider the actual performance of the as-planned schedule, as well as the actual start and finish date of the delayed event [17]. Therefore, the delay event 3 connected just to activity F as its logical predecessor and activity G as its logical successor.

Figure 8 shows the IAP schedule by delay event 3. In addition, the project is 5 days behind schedule. The owner is responsible for the delay, which is classified as an “EC” type. It is analyzed as the total delay of this project is 10 days: 5 days are concurrent delays and 5 days are owner-caused delays.

3.4. Stepwise Insertion with Constraints

This approach is to insert an activity or activities reflecting delay events into an as-planned schedule in chronological order by using constraints assigning the date that the delay events happened. As shown in Figure 9 and Figure 10, in step-by-step insertion using constraints, the as-planned schedule is impacted by delay events 1 and 2. The project is delayed 5 days. They are concurrent, which is the type of “ENs” delay.

“Delay event 3” caused by the owner’s change order happened from the 38th day to the 42nd day of the project. The delay event was inserted by using constraints reflecting the actual start and finish date. Therefore, Figure 11 shows the IAP schedule. Delay event 3 has 2 days of impact on the duration of the project. The owner is responsible for the delay, which is the type of “EC” delay. Therefore, the total delay of the project is 7 days. It turns out that concurrent delay is 5 days and owner-caused delay is 2 days. The result is the same as its real progress.

The as-planned schedule in step-by-step insertion contains most delay events and changes that occurred before any single delay event to be analyzed. Even if the as-planned schedule was updated with changes or delays, there is still a potential that the as-planned schedule does not incorporate all the network’s earlier delays or changes. That is, the as-planned schedule may differ from the most recent as-built schedule. As shown in Figure 6, as pointed out by Kim and Kwon [21], inserting delay events with constraints could lead to an overestimate of the impact of a delay event. When the delaying events are added to the network by using constraints based on its actual start and finish date, the delay of the project completion could be overestimated. This type of overestimation, on the other hand, can only occur when the completion delay is greater than the duration of the delay event. This kind of problem can be prevented by making sure that the delay of the completion is less than the duration of the delay event, and that if not, the delay event should be connected to one of its reasonable predecessor activities in the network.

When delay events are added without constraints, it can also be examined as if there were delays even if there were none in a project. If “delay event 3” is related to its predecessor (activity F) and successor (activity G) as FS0 without taking into account its actual start and finish date as shown in Figure 8, the analysis’ conclusion overestimates its influence and differs from its true progress. If the “delay event 3” is connected to its predecessor (activity F) as a finish-to-start relation with lag time 3 reflecting its real progress and to its successor (activity G) with FS0, its result would be the same as its real progress. Here, FS0 means finish-to-start relation with lag time 0. This outcome would be the same as the constraints. This means that connecting the delay event to its logical predecessors rather than using constraints that represent the actual date of the delay event provides no real benefit. In addition, the approach employing constraints is simple and easy to implement and can reduce disputes about the logical, soft connection between the delay event and its predecessor activities.

3.5. Adding Only Owner-Caused (or Contractor-Caused) Delays

Another approach is for the scheduler to simply take the as-planned schedule and add additional activities that represent delays (usually induced by the opposing party) to show why the project was completed later than expected [22]. This technique is used in practice to simply prove the other party’s responsibility for the delay of the project. However, this approach can distort the delay each party is responsible for and may lead to the wrong decision.

Figure 12 shows the IAP schedule, which solely includes imposed by the owner. It shows that the owner is responsible for 10 days of project delays.

The IAP schedule including only contractor-caused delays is shown in Figure 13. It shows that contractor delays 5 days of project duration.

The project’s planned duration is 40 days, and the project’s actual duration is 47. As a result, the total delay is 7 days. The owner-caused delay is 10 days, while the contractor-caused delay is 5 days, according to the analysis.

Owner-responsible delay (EC) is computed by multiplying the actual delay by owner-caused delays divided by the summation of all delays caused by the owner and contractors. Contractor-responsible delay (NN) is also calculated in the same way.

Owner-responsible delay (EC) = 7 × 10/15 = 4.67 days

(3)

Contractor-responsible delay (NN) = 7 × 5/15 = 2.33 days

(4)

This calculation assumes that the project’s estimated total delay is equal to the project’s actual delay. This approach does not allow for the analysis of concurrent delays caused by both the owner and the contractor. Therefore, in practice, this technique should only be utilized for simple pre-study.

4. Discussion

Table 1. Summary of the results of delay analysis.

Alternative	Delay (Days)
	EC	EN	NN
Actual	2	5	-
Single insertion	3.5	-	3.5
Stepwise insertion without constraints	5	5	-
Stepwise insertion with logic and constraints	2	5	-
Inserting only owner- (or contractor-) caused delays	4.67	-	2.33

summarizes the results of delay analysis by the four various techniques.

In a single insertion approach, a single delay event is inserted into an as-planned schedule without any additional delay events. This approach is currently being utilized by many delay analysts [23]. As shown in Table 1, however, it turns out that the types of delays are analyzed as different from actual progress. This approach considers the impact of each delay event at a time. As a result, it cannot analyze true concurrent delay. In addition, in the case of applying this approach, it is not recommended to utilize constraints based on actual dates of each delay event because an as-planned schedule does not reflect previous delays or changes that happened before each delay event in the network. Constraints with actual dates can result in a significant overestimate error when evaluating the impact of each delay event. This approach assumes that the sum of all delay impacts is equal to the project’s actual delay for simplification [20]. Therefore, it does not consider acceleration in the project and has limitations in terms of acceleration analysis.

In a stepwise insertion without constraints, Kim and Kwon [21] proclaims that delay events should be inserted into an as-planned schedule without using constraints, and delay events should be connected logically to activities in the as-planned network. However, there is a good likelihood that the delay events in the connection do not have a logical predecessor (activity) in the network. When an owner orders a design change in the middle of a project, for example, there may be no predecessor activities to the design change. Furthermore, when soft decisions are required, connecting delay events to logical predecessors may be difficult, and can cause controversy in delay analysis. Here, the soft decision means connection requiring the manager’s decisions that are related to optimizing site situations or minimizing a given impact [24]. They could be challenged in court since any change in the connection could have a significant influence on the outcomes of delay analysis [25]. Furthermore, as shown in Table 1, it turns out that the use of only logical relations excluding constraints can also lead to an overestimate in delay impact analysis.

In addition, two activities, predecessor activities being logically connected to the delay events and successor activities being impacted by them, could have long-time intervals. For example, the selection of a subcontractor for interior work can be scheduled right after the start of the project but interior works may not be started right after the selection of the subcontractor. The interior works are usually set to begin when the detailed work plan, shop drawing development, and all other previous works have been completed. Therefore, the activities “Selection of interior subcontractor” and “Interior works” could take a long-time interval. It can sometimes be longer than 1 year. As the activity “Selection of interior subcontractor” is near to the time of schedule development, an un-updated, as-planned schedule may reflect genuine progress of the activity. However, it may not reflect the real progress of activity “Interior works”, which is far from the time of schedule development. In this case, there is little chance that only using a logical relationship among delay events, predecessor, and successor activities without using constraints provide more accurate results than that of stepwise insertion with constraints where constraints are added into the network based on their actual dates and as-planned schedule includes all previous delay events and changes.

The third approach based on stepwise insertion with constraints is simple and efficient to implement. The result of delay analysis by this approach in this example is the same as that of its real progress. As Kim and Kwon [21] argues, this approach can lead to overestimation. To avoid overestimation, however, it is just necessary to make sure that the impact on the project’s duration is less than the duration of each delay event.

Approach inserting an only owner- (or contractor-) caused delay is simple and easy to implement. However, as illustrated in Table 1, it turns out that the types of delays are analyzed as different from actual progress. The outcome could be unfavorable to one party. In addition, constraints should not be used in inserting delay events into as-planned schedule. When only owner or, contractor-caused delays are added in the network, it does not reflect all changes in the schedule. However, constraints are added into the network based on their actual dates that the delay events actually happened. This can easily distort the output. This approach also implies that the sum of all estimated delay effects equals the project’s actual delay. Therefore, it cannot examine acceleration. In addition, concurrent delays cannot be estimated because it only analyzes delays caused by one party.

5. Conclusions

This research examines various techniques to estimate delay impacts using the IAP technique. A prototype network was introduced as an example to discuss several concerns. The results of delay analysis by each technique were compared with actual impacts. The advantages and limitations of each approach were identified. Recommendations were given for each approach.

Stepwise insertion with logic and constraints is most recommended. When inserting a fragnet (an activity or activities) in IAP to reflect delay events, both constraints and logical relationships between delay events, their logical predecessors, and successors can be used. Constraints based on the actual date of delay events are the simplest and easiest to use. However, constraints should not be used in “single insertion” and “inserting only owner- or contractor-caused delay” approach. In addition, in the case of using constraints, it is essential to check if the impact of delay events is larger than the duration of those delay events. In that case, delay events should be logically connected to their logical predecessor and successors without constraints. This study also identified through an example that inserting delay events by logic also can cause wrong analysis results. The findings of this research will aid delay analysts in identifying what kinds of issues arise in IAP methods and how to avoid them.

The problems dealt in this paper were identified by investigating real big projects having almost 5000 activities. However, real network could not be introduced in this paper. A sample network was used for simplification. This paper has limitations in that it cannot show the complexity and dynamics of real projects. AACE [14] and SCL [16] provides recommended protocols for delay analysis. However, there are still a lot of controversy in delay analysis. The area of delay analysis still does not have a standard practice. More issues in analyzing delay should be investigated and standardized in the future.