*3.4. Stepwise Insertion with Constraints*

This approach is to insert an activity or activities reflecting delay events into an asplanned schedule in chronological order by using constraints assigning the date that the delay events happened. As shown in Figures 9 and 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.

**Figure 9.** Adding delay event 1 by constraints.

**Figure 10.** Adding delay events 1 and 2 by constraints.

"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 asplanned 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.

**Figure 12.** Owner-caused delay.

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

**Figure 13.** Contractor-caused delay.

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 contractorcaused delay is 5 days, according to the analysis.

Owner-responsible delay (EC) is computed by multiplying the actual delay by ownercaused 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.

$$\text{Overner-resportible delay (EC)} = \mathcal{T} \times 10/15 = 4.67 \text{ days} \tag{3}$$

$$\text{Contractor-responseible delay (NN)} = 7 \times 5 / 15 = 2.33 \text{ days} \tag{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 summarizes the results of delay analysis by the four various techniques.

**Table 1.** Summary of the results of delay analysis.


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.
