Construction Delay Analysis Techniques—A Review of Application Issues and Improvement Needs

Abstract

The time for performance of a project is usually of the essence to the employer and the contractor. This has made it quite imperative for contracting parties to analyse project delays for purposes of making right decisions on potential time and/or cost compensation claims. Over the years, existing delay analysis techniques (DATs) for aiding this decision-making have been helpful but have not succeeded in curbing the high incidence of disputes associated with delay claims resolutions. A major source of the disputes lies with the limitations and capabilities of the techniques in their practical use. Developing a good knowledge of these aspects of the techniques is of paramount importance in understanding the real problematic issues involved and their improvement needs. This paper seeks to develop such knowledge and understanding (as part of a wider research work) via: an evaluation of the most common DATs based on a case study, a review of the key relevant issues often not addressed by the techniques, and the necessary improvements needs. The evaluation confirmed that the various techniques yield different analysis results for the same delay claims scenario, mainly due to their unique application procedures. The issues that are often ignored in the analysis but would also affect delay analysis results are: functionality of the programming software employed for the analysis, resource loading and levelling requirements, resolving concurrent delays, and delay-pacing strategy. Improvement needs by way of incorporating these issues in the analysis and focusing on them in future research work are the key recommendations of the study.

1. Introduction

The duration of contract performance has a direct effect on the profitability of construction projects from the perspective of all stakeholders [1,2]. For project owners, lost profits or benefits stem from being unable to make use of the project at the agreed date whilst to the contractor, extra cost will be incurred due to prolonged stay on site. Most standard forms of contract thus have provisions that anticipate delay brought about by the actions and/or inactions of the contractor, the owner or are outside the control of both parties. The contractor is often excused from the consequences and/or allowed compensation for any costs due to delays resulting from events or circumstances that are beyond its control. Contractual provisions also allow the owner to recover liquidated damages from the contractor for failure to deliver the project within the contract performance period. Liquidated damages clauses entitle the owner to recovery of a specified sum of money for each day or week of culpable delay. In both instances, a detailed schedule analysis is required to investigate the events that have actually caused the project to overrun. Over the years, owners and contractors have used various Delay Analysis Techniques (DATs) to achieve this. However, in the vast majority of cases, the parties are not able to settle delay claims amicably resulting in costly disputes after project completion [3,4,5].

Consequently, delay claims are now a major source of conflict in the construction industry and also one of the most difficult to resolve [6,7,8]. This has generated considerable initiatives from researchers and industry practitioners aimed at enhancing the application of existing DATs (see for example, [6,9,10,11,12,13,14,15]) and the development of “good practice” documents for providing guidance to practitioners on what the best application of the various techniques entails and the circumstances that dictate their proper use. Of such documents, the most notable are the “Delay and Disruption Protocol” [7] developed by the UK’s Society of Construction Law and “Recommended Practice on Forensic Schedule Analysis” by the Association for Advancement of Cost Engineering International [16] of the USA.

In spite of the many contributions, proper analysis of delay claims which take into consideration the effect of a number of scheduling and delay issues is often lacking in practice [8,14,17]. Therefore, the need for greater awareness and incorporation of these issues in delay analysis is crucial to ensuring fairness and amicable resolution of delay claims. As part of a wider study aimed at addressing these issues, the purpose of this paper is to: discuss the most common existing DATs, as well as review the issues that are often missed in the analysis, and the required improvement needs. The scope of this wider study involves investigating the techniques’ applications (in theory and in practice) thoroughly with the view to developing an appropriate framework for enhancing their proper usage, in order to help reduce the frequent delay claims resolution difficulties. This paper’s presentation on DATs, as detailed in the next section, was done based on a hypothetical case study so as to clearly demonstrate the application processes of the techniques and their weaknesses in presenting (or defending) delay claims.

2. Existing Delay Analysis Techniques

The objective of delay analysis is to calculate the project delay and work backwards to try to identify how much of it is attributable to each party (contractor, owner, or neither) so that time and/or cost compensation can be decided. Questions that need to be answered here often include [3,18]:

• what was supposed to happen?
• what did actually happen?
• what were the variances?
• how did they affect the project schedule?

The various DATs have varying capabilities in providing sound answers to these questions. The techniques can be grouped under non-Critical Path Method (CPM)-based techniques and CPM-based techniques. They have been reported by different authors in the literature using different names, with the most common techniques being: “as-planned vs. As-built”, “impacted as-planned”, “as-planned but for”, “collapsed as-built”, “window analysis”, and “time impact analysis” (see, for example, [5,6,7,8,19,20,21,22,23,24]).

3. A Case Study Project

To critically evaluate the existing techniques, a simple case study has been designed and simulated with various delay scenarios. The case study project involves the construction of a small garage with the necessary approach drive-in, as shown in the network diagram of Figure 1, adopted from Pilcher [25].

Figure 1. Arrow diagram of the case-study project.

Figure 1. Arrow diagram of the case-study project.

The as-planned programme of this project (in bar chart format for clarity) is as shown in Figure 2, indicating a total project duration of 40 days. The as-planned critical path, indicated in red bars, flows through activities of the garage structure, with a 5-day float on the path of drive-in activities.

The project started as scheduled but progress was affected by three main types of delay events: (1) Events for which the contractor assumes the risks of costs and the time consequences involved, which are often categorised as “Nonexcusable–Noncompensable” delays (NN); (2) events for which the contractor is entitled to both time extensions and recovery of extra cost consequential upon the delay [“Excusable Compensable” delays (EC)]; and finally, (3) those events for which no party has control over or bears the risks involved, (e.g., acts of God and strikes), which are often termed as “Excusable Non-compensable” (EN) delays.

Figure 2. As-planned schedule.

Figure 2. As-planned schedule.

Table 1 below defines the delay scenarios encountered in the hypothetical project. The as-built schedule, which includes all delays that occurred during construction of the project, had total project duration of 51 days and a critical path along the drive-in activities (see Figure 3). To distinguish between the various delays, EC delays are indicated in dark horizontal strips and NN delays in dark diagonal strips. Apart from the delays, there were also changes in the planned sequence between some of the activities. The as-built programme thus shows start–start logic with lag of 2 days between the first two activities of the garage instead of the originally planned finish–start relationship. Similar logic with a lag of 3 days exists between the first two activities of the drive-in.

Figure 3. As-built schedule.

Figure 3. As-built schedule.

Table 1. Delays events that affected the sample project.

Activity	As planned duration	Chronology of delays	Delay information
			Description	Type	Start date (day)	End date (day)	Duration (days)
Concrete foundations (G2)	3	1	Contractor had a labour problem so it took 3 days extra to complete activity G2.	NN	6	9	3
Clear and excavate for drive-in (D1)	15	2	Contractor encountered unforeseen adverse ground condition during excavation of the drive-in.	EC	10	17	7
Brickwork to roof level (G4)	14	3	Activity G4 did not start immediately after completion of its predecessor as-planned due to 1-day delay by the contractor’s brick supplier.	NN	15	16	1
Concrete to floor slab (G5)	4	4	Contractor advised the owner on the need to increase the thickness of the floor slab. This change required 1 extra day to accomplish.	EC	19	20	1
Hardcore base to drive-in (D2)	10	5	After 5 days of working on activity D2, the owner suspended works for 3 days as a decision on the suitability of the hardcore material was being made.	EC	24	28	4
Brickwork to roof level (G4)	14	6	The owner ordered the contractor to add an extra window after the completion of G4. This design change caused 2-day delay.	EC	30	32	2
Hardcore base to drive-in (D2)	10	7	A quality control test revealed that certain sections of the drive-in base were poorly constructed. This defective work resulted in 5 days of rework by the contractor.	NN	31	36	5
Tarmacadam to drive-in (D3)	5	8	There was a 4-day delay by the owner in making available to the contractor an owner-furnished equipment for activity D3	EC	38	42	4
Waterproof roof (G7)	2	9	It took the contractor 3 more days to complete activity G6.	NN	40	43	3
Fix doors (G8)	2	10	The owner changed his mind on the type of door used for the garage so ordered the contractor to make changes. This caused 3 extra days of work.	EC	40	43	3

Table 1. Delays events that affected the sample project.

Activity	As planned duration	Chronology of delays	Delay information
			Description	Type	Start date (day)	End date (day)	Duration (days)
Concrete foundations (G2)	3	1	Contractor had a labour problem so it took 3 days extra to complete activity G2.	NN	6	9	3
Clear and excavate for drive-in (D1)	15	2	Contractor encountered unforeseen adverse ground condition during excavation of the drive-in.	EC	10	17	7
Brickwork to roof level (G4)	14	3	Activity G4 did not start immediately after completion of its predecessor as-planned due to 1-day delay by the contractor’s brick supplier.	NN	15	16	1
Concrete to floor slab (G5)	4	4	Contractor advised the owner on the need to increase the thickness of the floor slab. This change required 1 extra day to accomplish.	EC	19	20	1
Hardcore base to drive-in (D2)	10	5	After 5 days of working on activity D2, the owner suspended works for 3 days as a decision on the suitability of the hardcore material was being made.	EC	24	28	4
Brickwork to roof level (G4)	14	6	The owner ordered the contractor to add an extra window after the completion of G4. This design change caused 2-day delay.	EC	30	32	2
Hardcore base to drive-in (D2)	10	7	A quality control test revealed that certain sections of the drive-in base were poorly constructed. This defective work resulted in 5 days of rework by the contractor.	NN	31	36	5
Tarmacadam to drive-in (D3)	5	8	There was a 4-day delay by the owner in making available to the contractor an owner-furnished equipment for activity D3	EC	38	42	4
Waterproof roof (G7)	2	9	It took the contractor 3 more days to complete activity G6.	NN	40	43	3
Fix doors (G8)	2	10	The owner changed his mind on the type of door used for the garage so ordered the contractor to make changes. This caused 3 extra days of work.	EC	40	43	3

4. Project Delay Analysis Using the Various Techniques

4.1. As-Planned vs. As-Built

Under this method, all delaying events (EC, EN and NN delays) encountered on the project are depicted on the as-built schedule. The difference between the as-planned and as-built completion dates is the amount of time for which the claimant will request for compensation. The critical path is determined once in the as-planned and again in the as-built schedule [8,22]. This technique and the net impact technique utilising bar chart are similar in that they all show the net effect of all claimed delays. By the approach of Stumpf [24], the following illustrates the allocation of delay responsibility between the owner and the contractor for the sample project.

Sum of contractor-caused delays (NN) = ΣNN_i = 3 + 1 + 5 + 3 = 12 days (see Table 1);

Sum of owner-caused delays (EC) = ΣEC_i = 7 + 1 + 4 + 2 + 4 + 3 = 21 days (see Table 1).

From the above, the assumption is that concurrent delay due to both parties is 12 days (“i.e.”, the lower of the above two types of delays). Therefore, net project delays for which the owner is responsible = 21 − 12 = 9 days;

From Figure 2, Figure 4, the net total project delay = 51 − 40 = 11 days, the balance is the contractor responsibility, which is 11 − 9 = 2 days. The limitations of this methodology are:

• it does not scrutinize delay types and this makes it easy for it to be manipulated and distorted to reflect either the position of the claimant or the defendant;
• it ignores the dynamic nature of the critical path and any changes in schedule logic [20,24,26];
• no attempt is made to determine the individual impact of each delay on the project completion. All delays, including delays on non-critical path, were summed up and their net effect calculated.

Figure 4. As-built schedule with delays.

Figure 4. As-built schedule with delays.

4.2. Impacted As-Planned

This method measures the impact of the delays on the contractor’s as-planned CPM schedule. The various delays are formulated as activities and added to the as-planned network in a chronological order showing the effect of each delay at a time and demonstrating how the project is being delayed [27]. The amount of delay equals the difference in completion dates between the schedules before and after the impacts. The technique can be used for analysis of delay during and after project completion.

Delay analysis of the sample project using this technique was carried out by sequential addition of the delays to the as-planned schedule. The impact of each delay is as shown in Figure 5, Figure 6, Figure 7, Figure 8, Figure 9, Figure 10, Figure 11, Figure 12, Figure 13 below.

Figure 5. Impact of first delay.

Figure 5. Impact of first delay.

Figure 6. Impact of second delay.

Figure 6. Impact of second delay.

Figure 7. Impact of third delay.

Figure 7. Impact of third delay.

Figure 8. Impact of fourth delay.

Figure 8. Impact of fourth delay.

Figure 9. Impact of fifth delay.

Figure 9. Impact of fifth delay.

Figure 10. Impact of sixth delay.

Figure 10. Impact of sixth delay.

Figure 11. Impact of seventh delay.

Figure 11. Impact of seventh delay.

Figure 12. Impact of eighth delay.

Figure 12. Impact of eighth delay.

Figure 13. Impact of ninth and tenth delays.

Figure 13. Impact of ninth and tenth delays.

The first delay (NN = 3) was on the critical path, G1-G2-G3-G4-G6-G7-G8-G9 so it caused 3 days of slippage to the as-planned programme. The second, fourth, ninth and tenth delays were on non-critical paths so their impacts did not cause any slippage. The impacts of fifth, seventh and eighth delays caused project slippage on the critical path, D1-D2-D3-G9. A summary of the results obtained are as shown in Table 2.

Table 2. Impacted as-planned results.

Chronology of delays	Activity	Delay
		Type	Duration (days)	Impact (days)
1	G2	NN	3	3
2	D1	EC	7	0
3	G4	NN	1	1
4	G5	EC	1	0
5	D2	EC	4	1
6	G4	EC	2	1
7	D2	NN	5	4
8	D3	EC	4	4
9 and 10	G7 and G8	NN and EC	3 and 3	0

Table 2. Impacted as-planned results.

Chronology of delays	Activity	Delay
		Type	Duration (days)	Impact (days)
1	G2	NN	3	3
2	D1	EC	7	0
3	G4	NN	1	1
4	G5	EC	1	0
5	D2	EC	4	1
6	G4	EC	2	1
7	D2	NN	5	4
8	D3	EC	4	4
9 and 10	G7 and G8	NN and EC	3 and 3	0

From Table 2, the owner is responsible for six days of delay to the project whilst the contractor is responsible for 8 days. The sum of these delays is greater than the actual project delay of 11 delays because of the failure of this technique to consider any changes in the as-planned programme, which is by maintaining the original finished–start relationship of all activities in the analyses.

The limitations of this method include the following:

• it uses fixed as-planned schedule to analyse delays out of context and time [24,26];
• the original baseline programme may not be a realistic model on which to base the whole analysis;
• it has the potential of failing to consider the delays of all parties especially that of the claimant (“i.e.”, being one-sided);
• potential disputes over the adequacy of the as-planned schedule because it is not economically possible, nor does it makes sense, to schedule the entire project in detail at its inception [3].

4.3. As-Planned But for

This method entails injecting the as-planned schedules with all the delays of a particular party to form an adjusted schedule. The completion date of this adjusted as-planned schedule compared with the actual completion date gives the amount of delay for which the other party is responsible [8,19,22]. A contractor using this method would identify and add all non-excusable delays to the as-planned schedule, whereas the owner would add all excusable delays. The advantage of this method is that it can be performed quickly because there is no need to consider actual progress of the work. This technique is applied to the sample project first for contractor’s point of view and then for owner’s point of view.

Contractor’s point of view: Under this, all the contractor-caused delays were impacted on the as-planned schedule. This resulted in an adjusted as-planned schedule with completion date as day 47 and G1-G2-G3-G4-G6-G7-G8-G9 as the critical path (see Figure 14 below). With the actual completion date as day 51, the owner is responsible for 4 days’ project delay, which could be charged as compensable delay. The amount of delay for which the contractor is responsible is 47 − 40 = 7 days, where 40 is the original as-planned completion date.

Figure 14. As-planned schedule impacted with contractor’s delays.

Figure 14. As-planned schedule impacted with contractor’s delays.

Owner’s point of view: Under this, all the owner-caused delays were impacted on the as-planned schedule. This resulted in an adjusted as-planned schedule with completion date as day 49 and D1-D2-D3-G9 as the critical path (see Figure 15 below). With actual completion date as day 51, the contractor is responsible for 2 days’ project delay, which could be charged for liquidated damages by the owner. The owner is then responsible for the difference between the adjusted schedule and the original completion date, i.e., 49 − 40 = 9 days.

Figure 15. As-planned schedule impacted with owner’s delays.

Figure 15. As-planned schedule impacted with owner’s delays.

The limitations of this method include the following:

• it does not take into account any changes in the critical path schedule during the course of the project [19];
• it assumes that the planned construction sequence remains valid during the project duration [5];
• owner’s point of view and contractor’s point of view may yield different results resulting in disputes (as this case shows).

4.4. Collapsed As-Built

In principle, this method is a form of “but for” which does not use the as-planned as a baseline schedule, but rather uses the as-built schedule (and thus also referred to as “as-built but for” technique). It involves removing the delays of each party from the as-built network so that the resulting schedule will give the completion date of the project but for the delays of the other party [18,24]. Like the previous technique, this technique is applied to the sample project first for contractor’s point of view and then for owner’s point of view as follows:

Contractor’s point of view: Under this, all owner-caused delays were subtracted from the as-built schedule resulting in a collapsed as-built schedule of completion date as day 45 and critical path G1-G2-G3-G4-G6-G7-G8-G9 (see Figure 16).

Figure 16. As-built schedule with owner’s delays subtracted.

Figure 16. As-built schedule with owner’s delays subtracted.

With actual completion date as day 51, the owner is responsible for 6 days of the (51–45) project delay, which could be charged as compensable delay. Comparing the collapsed as-built schedule with the original schedule gives 45 − 40 = 5 days project delay, as caused by the contractor.

Owner’s point of view: Under this, all contractor-caused delays were subtracted from the as-built schedule resulting in a collapsed as-built schedule of completion date as day 46 and critical path D1-D2-D3-G9 (see Figure 17). With actual completion date as day 51, the contractor is responsible for 5 days of project delay, which could be charged for liquidated damages. Comparing the collapsed as-built schedule with the original schedule gives 46 − 40 = 6 days project delay as that caused by the owner.

Figure 17. As-built schedule with contractor’s delays subtracted.

Figure 17. As-built schedule with contractor’s delays subtracted.

This technique and the “as-planned but for” could give similar results if the planned logic remains unchanged in the course of the project. The perceived advantage of this technique is that it is based on actual events on the project, making it one of the techniques of high credibility [5]. However, its shortcomings include the following:

• in collapsing the schedule, the analyst is typically forced to insert after-the-fact logic ties which may not reflect the thinking of the executor of the schedule during actual performance [5];
• the removal of the delays from the schedule could result in an unrealistic as-built but-for schedule, particularly when the schedule sequence has been so much impacted by those delays;
• adjusting the collapsed schedule to suit what the contractor is likely to follow requires experience and sound judgement beyond the capability of most analysts [18];
• it ignores the circumstances at the time of the delay and the dynamic nature of the critical path;
• the identification of the as-built critical path requires great deal of effort on judgement and schedule manipulation [20];
• the use of as-built information to prepare the as-built schedule is subjective and highly amenable to manipulation [27].

4.5. “Window” Analysis

This technique involves interim assessment of delay on updated schedules at specific periods of the project. This is similar to the “snapshot technique” described by Alkass [19] and “contemporaneous period analysis” described by Schumacher [2]. First, the total project duration is divided into a number time periods (windows or snapshots) usually based on major changes in planning or major project milestones [6,8]. The schedule within each window is updated to reflect the actual durations and sequence at the time of the delay while the remaining as-planned schedule beyond the window period is maintained. Analyses are performed to determine the critical path and new completion date. This new completion date is compared with the as-planned completion date prior to this analysis to give the amount of delay during that window period.

Applying this technique to the sample project, the total contract period was first broken into discrete time periods at days 10, 21, 32, 40 and 51, resulting in 5 “window” periods. Analysis was carried out for each “window” successively at the various updates as shown in Figure 18, Figure 19, Figure 20, Figure 21, Figure 22 below.

Figure 18. Updated schedule on day 10.

Figure 18. Updated schedule on day 10.

Figure 19. Updated schedule on day 21.

Figure 19. Updated schedule on day 21.

Figure 20. Updated schedule on day 32.

Figure 20. Updated schedule on day 32.

Figure 21. Updated schedule on day 40.

Figure 21. Updated schedule on day 40.

Figure 22. Updated schedule on day 51.

Figure 22. Updated schedule on day 51.

There was 1-day slippage at the end of the 1st window due to 3 days’ delay by the contractor on the critical path G1-G2-G3-G4-G6-G7-G8-G9. The updated schedule at the end of the 2nd window showed 1 day slippage due to 1-day delay by the contractor on the critical path. There was 2 days of project delay at the end of the 3rd window as a result of 2 days delay by the owner on the critical path. The critical path changed to D1-D2-D3-G9 at the end of the 4th window, resulting in 5 days slippage. By “but for” analysis, the contractor’s delay responsibility within this window is 2 days while that of the owner is 3 days. At the end of the last window, further 2 days’ slippage was caused by the owner along the critical path, D1-D2-D3-G9. Table 3 below gives a summary of the results of this analysis.

Table 3. “Window” analysis results.

Window number	Schedule update (day No.)	Completion date (day No.)	Delays in window
			EC	NN
0 (start)	0	40	0	0
1	10	41	0	1
2	21	42	0	1
3	31	44	2	0
4	39	49	3	2
5 (completion)	51	51	2	0
Total			7	4

Table 3. “Window” analysis results.

Window number	Schedule update (day No.)	Completion date (day No.)	Delays in window
			EC	NN
0 (start)	0	40	0	0
1	10	41	0	1
2	21	42	0	1
3	31	44	2	0
4	39	49	3	2
5 (completion)	51	51	2	0
Total			7	4

Thus the contractor is responsible for 4 delays to the project whilst the owner is responsible for 7 days’ delay. A major advantage of this method is that it divides a complicated network into a manageable one and also takes into account the dynamic nature of the critical path. This method offers a very effective approach to analysing delays and the more snapshots or windows used the better the accuracy of the results. However, the limitations of this technique include:

• it is time consuming and costly to operate and also demands complete project records, which are often not available;
• differences in the time periods (or “windows”) can produce different results [14];
• periodic updates may not be existing which may then require the analyst to perform a highly laborious analysis of project records to create updates.

4.6. Time Impact Analysis

This technique is a variant of the window technique described above, with the difference being that the time impact technique concentrates on a specific delay or delaying event but not on time periods containing delays or delaying events [19].

A stop-action picture of the project is developed each time it experiences a major delay situation. The schedule is then updated at this delay period and the effect of the delay is analysed to establish a new completion date. The difference between the new completion date and the date prior to the exercise gives the delay caused by that particular impact. A “fragnet” or subnetworks are sometimes prepared to depict the impact of the delay event, e.g., change orders on the schedule. It is an effective technique because the delays are analysed using real time CPM. It is also applicable to use during project duration and after completion. However its limitations include:

• it may not be practical or realistic to use if there are an overwhelming number of delay causing events [8];
• periodic updates may not be existing which may then require the analyst to perform highly laborious analysis of project records to creates updates;
• the analysis requires intensive effort and is time consuming.

Because of the close similarity of the time impact analysis and the window analysis, the former was not applied to the sample project.

Table 4 below summarises the results of delay responsibilities of the parties as given by the various the techniques.

Table 4. Summary of delay analysis results for the case study.

Delay analysis methodology	Delay
	EC	NN
As-planned vs. As-built	9	2
Impacted As-planned	6	8
As-planned But for
(a) contractor’s point of view	4	7
(b) owner’s point of view	9	2
Collapsed As-built	6	5
“Window”Analysis	7	4

Table 4. Summary of delay analysis results for the case study.

Delay analysis methodology	Delay
	EC	NN
As-planned vs. As-built	9	2
Impacted As-planned	6	8
As-planned But for
(a) contractor’s point of view	4	7
(b) owner’s point of view	9	2
Collapsed As-built	6	5
“Window”Analysis	7	4

4.7. Reflection on the Different Results DATs Generate

Clearly, the main reason responsible for the different results is the different modes of application the various techniques employ. Not only are there wide differences in their applications, the delaying events experienced by real-life projects are often extensive and more complex to deal with [7,19] than the example of this case study portrays. Thus, the analysis results from DATs for real-life cases tend to be staggeringly different and bear a significant amount of time and cost compensations, as well [17,23]. The different modes of application also require varying levels of analysis details in the delay assessment process. DATs that analyse a programme(s) directly as it is, without any major modifications of the programme(s) (e.g., as-planned vs. as-built), are often considered “simplistic methods” [20]. On the other hand, those that involve extensive programme modifications, including running of “additive” and “subtractive” simulations (e.g., collapsed as-built and time impact analysis), are termed “sophisticated methods” [20]. Although the latter group require more expense, time, skills, resources and project records to operate, they tend to give more accurate results than the former partly due to the detailed/rigorous analysis they entail [5,20]. In terms of which techniques are favoured by claim parties, the impacted as-planned, as-planned but-for, and collapsed as-built are often preferred by contractors or owners, since these techniques are capable of easily establishing the amount of project delays that could be attributable to the actions or inactions (delays) of a particular party, through just by inserting or removing such delays from relevant programmes [24,25].

In view of the aforementioned differences, the general view amongst practitioners regarding use of DATs is that no single technique is suitable for all delay claims situations and that the most appropriate one for any case is dictated by a number of factors or criteria [7,17]. The need to determine and make use of this appropriate technique is increasingly becoming a crucial issue. For example, in the UK case of Balfour Beatty Construction Ltd vrs The Mayor and Burgesses of the London Borough of Lambeth [28], the defendant challenged the adjudicator’s decision for, in alia, not given any opportunity to the parties to comment on the appropriateness of the technique adopted by the adjudicator for determining time extensions and to seek their observations as to its use. The defendant’s position was upheld by the judge, who regarded the adjudicator’s inaction as a serious omission. The following sections discuss the factors often mentioned in the literature as being the key criteria that parties need to consider in deciding on the most appropriate technique.

Availability and accuracy of project records have a major influence on the suitability of a technique since the various techniques employ different programming information sources. If a good as-planned network programme exists but has not been updated with progress due to lack of as-built records, etc., then impacted as-planned analysis may be appropriate [8]. Conversely, where there are good as-built records but no as-planned programme or the as-planned programme is not adequately prepared, then the collapsed as-built method may be appropriate [24].

The time of performing delay analysis is an important factor, since some techniques (e.g., time impact analysis, impacted as-planned) are suitable for performing forward or contemporaneous assessment (termed “prospective analysis”), whilst others (e.g., collapsed as-built) can only be used for hindsight assessment (retrospective analysis) [3,7]. The prospective analysis seeks to establish the effect of delays during the currency of the project, particularly when the contract provides that the contractor is entitled to relief from liquidated damages if completion is likely to be delayed. Retrospective analysis, on the other hand, is carried out after the fact (i.e., at the end of the project), where analysts usually have full benefit of hindsight [8,17].

The type of delay claims in dispute influences the type of DAT to be employed. The more theoretical techniques like “impacted as-planned” are helpful for instances where a party is concerned with proving delay time only [8]. Nevertheless, when the claim involves money as well, an approach based on the analysis of what actually transpired on the project (e.g., using “Collapse As-built”) is warranted [8]. The cases McAlpine Humberoak Ltd vrs McDermott International Inc. [29] and Ascon Contracting Ltd vrs Alfred McAlpine Construction Isle of Man Ltd. [30] have both confirmed that wholly theoretical calculations are unlikely to succeed.

The availability of resources for the analysis is also a relevant issue of consideration [7]. As noted earlier, the sophisticated techniques require more time and resources to use than the simplistic ones and hence the latter group may be suitable for small/medium size projects where management resources are limited and the records are usually inadequate. On the other hand, larger-scale projects with sufficient management resources warrant a more sophisticated method such as the time impact analysis and window analysis [7,17].

5. Relevant Issues not Addressed by Existing DATs

In addition to the different results that existing DATs produce when applied to the same set of delay claims data, there are other relevant issues that have the potential of affecting the results but are often not taken into consideration in the techniques applications. These issues include: functionality of the programming software employed, resource loading and levelling requirements, resolving concurrent delays, and delay pacing strategies.

5.1. Functionality of the Analysis Software Packages

Not only do current construction programming software packages have different functionalities and capabilities [31,32], they also lack transparency on certain scheduling operations [33,34]. For instance, when it comes to dealing with programming issues of relevance to delay analysis, such as project calendars, rescheduling activities with lags, handling of statuses/updates (progress override or retain logic settings) and resource allocation, the packages have different settings and ways of handling them [35,36,37]. As a result of these features, different software are likely to produce different results when used to analyse a particular delay claim [38] and therefore further exacerbating the difficulties often surrounding the amicable resolution of the delay claims. A possible solution to this issue is to convert the programme being used for the analysis from one software package into another, but this does not offer a viable solution either, as the conversion process is characterised by difficulties and information distortion problems [38]. A notable recommendation for dealing with the software problem is for the disputing parties to agree on a common software for undertaking the delay claims assessment [7], unless the project contract specifies otherwise.

5.2. Resource Loading and Levelling Requirements

The basic assumption underpinning traditional CPM programme that resources are unlimited does not hold in reality as resources tend to be limited in most practical situations [8,39]. It is thus quite important for baseline programmes to be resource-loaded so as to ensure both reliable task duration and network logic, especially when many tasks require the same resources at the same time [40]. Without such loading, the programme to be used for delay analysis would not show realistic float values in its non-critical activities, and would thus affect the outcome of the analysis, especially for cases involving time extensions claims resolutions [41,42]. Therefore, resource loading or levelling considerations in delay analyses is quite crucial to ensuring accurate and trustworthy results [8,15], except for the collapse as-built technique as it does not rely on baseline programmes.

It is noteworthy that the need for analysts to take resource allocations into account in their delay analyses is becoming an increasingly vital requirement. For instance, in the UK case of McAlpine Humberoak vrs McDermott International [29], the judge disapproved of the plaintiff’s delay claim submissions on the basis of not giving consideration on how resource usage was planned for and how they were actually utilized during construction. Wickwire [43] also reviewed legal decisions in the US and noted that “in any analysis of project delays, the contractor is required to take into account realistic resource levelling”. Although the incorporation of resource loading effects in the analysis represents a more accurate and rigorous assessment of delay claims, there is very little research on how this consideration can be incorporated in the existing techniques. There is thus the need for further research into this aspect of programming to help enhance the resolution of delay claims in practice.

5.3. Resolving Concurrent Delays

The identification and apportionment of concurrent delays remains a contentious technical subject [7]. More debilitating is the fact that there is no uniformly accepted definition among practitioners as to what it concurrent delay itself means [7]. A reliable approach for analysing concurrent delays would involve using dynamic multiple time periods or windows, as this is capable of tracing changes in the critical path [7,14,24]. However, in such mode of analysis, identifying the concurrency and the type of concurrent delays within a given period will be dependent on the length of time chosen for the analysis period. Therefore analysts using different time intervals are bound to interpret a given concurrent delay situation differently. To enhance amicable settlement of claims, analysts would have to agree on the analysis time interval to be used, which can either be based on dates at which programme updating occurred or the occurrence of key project events such as project milestone or major changes in the programme. The legal aspects of concurrent delays concerning the kind of remedies to be offered to parties have also continued to remain a highly contentious issue. Scott et al. [44], for example, found that UK practitioners hold dissenting views to the SCL’s recommended remedies [7], which stipulate that, for employer and contractor delays occurring concurrently, the parties should share the responsibility between them and extension of time without costs also awarded. In addition, existing case laws that could offer some guidance on the remedies do not speak in harmony [45]. This lack of consensus or clearly defined rules/methods for dealing with remedies of concurrent delay types poses great difficultly to practitioners in delay claims resolution. There is therefore the need for research into the underlying principles that govern the legal resolution of concurrent delays to establish clear guidelines for dealing with all possible concurrency situations. Employers may subsequently incorporate these in their contracts for it to guide claim parties during delay claims resolutions.

5.4. Pacing Delays

Zack [46] defined this as “deceleration of the project work, by one of the parties to the contract, due to a delay to the end date of the project caused by the other party, so as to maintain steady progress with the revised overall project schedule”. The thinking behind pacing delay is that it is sensible for a party to slow down the working pace if a delay by other party makes it unnecessary for hard or fast working, as often memorably argued, “why hurry up and wait”. It enables the contractor or the employer to mitigate or avoid cost that otherwise would have been incurred had the work been done faster. However, there are difficulties in exercising the right to pace delays, which can affect the delay analysis process. For instance, float ownership, will determine whether a particular contractor-caused delay could be a potential employer’s defence of concurrent delay or otherwise. Furthermore, as argued by Zack [46], pacing delays tends to minimise compensable delay and this makes it imperative to consider its effect in delay analysis process to ensure fairness in the apportionment of delay responsibility. Further studies are thus needed to offer assistance on how to resolve these issues.

6. Conclusions

Delay claims are now a major source of conflict in the construction industry and also one of the most difficult to resolve. Inspired by this, academic researchers and practitioners alike have made numerous attempts by way of developing DATs and good practice documents for guiding practitioners on the proper analyses and resolution of the claims. The knowledge of the application of these techniques is of paramount importance to understanding their limitations and capabilities in practice and areas of improvement needs. As part of a wider research work, this paper seeks to develop such knowledge and understanding via: an evaluation of the most common DATs based on a case study, a discussion of the key relevant issues often not addressed by the techniques and their improvement needs. The evaluation of the techniques confirmed that the various DATs give different allocations of delay responsibilities when applied to the same set of delay claims data, reinforcing the common notion that the most appropriate technique for any claims situation depends on the claims circumstances and the project. The different results stem mainly from the unique set of requirements and application procedures each technique employs. In addition, there are a number of issues such as: functionality of the programming software employed for the analysis, resource loading and levelling requirements, concurrent delay and delay pacing, which are all vital to ensuring accurate and reliable analysis results but are not addressed by the DATs.

Current programming software packages for analysis delay claims are characterised by different functionalities and capabilities. They also lack transparency on some crucial scheduling operations and employ different settings for dealing with key scheduling issues that affects delay analysis process such as project calendars, rescheduling activities with lags and status updates. These features increase the chance of claimants and defendants at arriving at different delay claim results and thus make it more difficult for amicable settlement of the delay claim disputes. This justifies the need for disputing parties to agree on a common acceptable software package for the analysis and how it should be applied appropriately.

To ensure a more reliable delay analysis results, it is important to use resource-loaded and levelled baseline programmes, as such programmes provide for reliable task duration, network logic, and realistic float values in non-critical activities. Without taking such programming requirements into account in the analysis, the baseline programme would not adequately reflect the plan of work as dictated by the true intent of resource usage in practice, thereby leading to results that are not accurate and trustworthy. Although taking account of resource loading ensures reliable analyses and results thereby contributing to successful claims resolution, there is very little research done on how this consideration can best be incorporated in DATs. This limitation thus calls for the need for further research studies in this area.

Resolving concurrent delays is still considered one of the most difficult issues to address, partly because existing DATs do not take them into account in the analyses. The best approach to handling this challenge is for the analyst to employ dynamic multiple time periods or windows, so as to be able to trace changes in the critical path. Using different time intervals would however produce different results as the extent and type of concurrency are bound to yield difference situations and effect. It is therefore important for disputing parties to agree on the most appropriate time interval to be used for the analysis, either based on status dates or the occurrence of key/milestone project events.

Delay pacing strategy is a relatively new defence strategy often argued by both owners and contractors to demonstrate that their delay was not the dominant or controlling delay. Although each party has the right to pace delays, the process is fraught with difficulties similar to those of concurrent delays and float ownership issue. For instance, the latter will determine whether a particular contractor-caused delay could be a potential employer’s defence of concurrent delay or otherwise.

In general, this paper offers valuable insights into the applications of existing DATs, which have important implications for the resolution of construction delay claims and its improvement needs. First, parties involved in such claims should not only be aware of the limitations and capabilities of the techniques, but need to examine the above-highlighted issues as well so as to, as far as possible, take them into account in the analysis. This consideration will hopefully increase the rigour and transparency in the claims analysis, and hence reduce the chances of disputes in the claims settlement. Secondly, the highlighted issues have, however, received very little awareness and research attention thus far, as evidenced by delay analysis literature. Future research thus needs to focus more on these relatively overlooked issues, in order to extend the limited knowledge and understanding that exist about them such as how best they can be addressed appropriately in delay analysis.

Whilst the case study used was based on a hypothetical project, the proposed claims scenarios largely reflect that of a typical construction delay claims settings, both in relevance and context. However, to strengthen this study, it is recommended that a similar study be undertaken in the future based on real-life project data to validate the case study findings.