- Email: [email protected]
Incorporating rework into construction schedule analysis
Automation in Construction 20 (2011) 1051–1059
Contents lists available at ScienceDirect
Automation in Construction j o u r n a l h o m e p a g e : w w w. e l s ev i e r. c o m / l o c a t e / a u t c o n
Incorporating rework into construction schedule analysis Tarek Hegazy a,⁎, Mohamed Said a,1, Moustafa Kassab b,1 a b
Civil and Environmental Engineering Department, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1 Systems Design Engineering Department, University of Waterloo, Waterloo, Ontario, Canada, N2L 3G1
a r t i c l e
i n f o
Article history: Accepted 5 April 2011 Available online 13 May 2011 Keywords: Construction management Rework Delay analysis Cost Acceleration Scheduling Optimization Computer application
a b s t r a c t Rework has been a primary cause of cost and schedule overruns in large construction projects. While several research efforts have analyzed the causes and effects of rework and provided guidelines to reduce rework, almost no research exists to analyze the impact of rework timing and quantity on schedule delays and to support decisions on cost effective recovery. This research presents a quantitative mechanism for schedule analysis considering rework. The mechanism has three aspects: (1) a new schedule representation of rework magnitude as negative percentage complete for affected activities, documented on the specific date on which the rework is detected; (2) a modified daily-windows delay analysis to apportion project delays among the responsible parties; and (3) an optimization technique for determining the least costly corrective action strategy that recovers project delays. The proposed approach is applied to a case study to demonstrate its ability to consider rework impact, in combination with other progress events by other project parties. This research offers an innovative quantitative approach to consider rework timing and amount in delay analysis and corrective action optimization. © 2011 Elsevier B.V. All rights reserved.
1. Introduction Rework is a serious problem facing large and complex construction projects, particularly industrial projects that involve multiple parties such as contractors, suppliers, and trades. In such a complex environment where many activities by many parties take place simultaneously, often errors, omissions, and misunderstandings cause undesirable outcomes that have to be reworked. Rework, thus, has been defined as the effort of re-doing a process or activity that was incorrectly implemented the first time [22]. In literature, the term “rework” has been related to other terms such as “quality deviations” [5], “non-conformance” [1,3], “defects” [17], and “quality failures” [4]. Since rework can occur at different stages in the project life cycle, the term “field rework” has been clarified not to incorporate change orders or off-site fabrication errors [8]. Various researchers have studied rework from different perspectives such as rework cycle, root causes, and impact on project performance [19]. [7] introduced the concept of the rework cycle in projects, where the rework itself is not done properly, thus requiring further rework in a recursive cycle that can extend project duration far beyond what is originally conceived. This concept becomes important to the understanding of the interactions
⁎ Corresponding author. Tel.: + 1 519 8884567x32174; fax: + 1 519 888 6197. E-mail addresses: [email protected] (T. Hegazy), [email protected] (M. Said), [email protected] (M. Kassab). 1 Tel.: + 1 519 888 4567x33869. 0926-5805/$ – see front matter © 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.autcon.2011.04.006
among various project factors including rework, which can be studied using system dynamics tools [24]. With respect to root causes, several studies and surveys were conducted to identify and classify the root causes of rework such as [21]; [25]; [6]; [28]; [5]; [23]; [8]; [20]; [26] and [16]. Almost all studies reported that rework plays a major role in cost and schedule overruns. They identified the main root causes of rework as: errors, omissions, failures, damages, poor leadership, poor communication, and ineffective decisionmaking. The survey of [21], for example, reported the direct and indirect costs of rework observed in various contract types and identified rework causes related to the design team, client, site management, and subcontractors. Among the various project types, industrial projects have been reported by [16] to exercise the most cost increase due to rework. With respect to the impact of rework on project performance, various researchers reported observations from case studies, surveys, and interviews among professionals. A summary of the rework cost reported in various studies is shown in Fig. 1. With most studies analyzing rework-related cost performance, [16] recommended conducting further studies on rework impact on schedule performance. The direct costs of rework, however, have been reported to be in excess of 15% of the contract value [4,19]. Using a survey of 115 civil infrastructure projects, it was revealed that the following five significant predictors accounted for 25% of the variance in total rework cost: (1) ineffective use of information technologies; (2) excessive client involvement in the project; (3) lack of clearly defined working procedures; (4) changes made at the request of the client; and (5) insufficient changes initiated by the
1052
14 %
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
Cost of rework (% of total project cost)
12 % 10 %
12.4%
8% 6%
5%
2-6%
10%
5% 3.15%
(1) CII (1989) (2 Josephson and Hammarlund (1999) (3) Love and Li (2000)
(6) Rail way
(5) Heavy Eng. / Industrial
(4) Highway
(3) Residential
(2) Commercial, Industrial
(1) All types
4%
(4) Abdul-Rahman (1995) (5) Burati et al. (1992) (6) Nylén (1996)
Fig. 1. Cost impacts of rework reported in various studies.
contractor to improve quality [19]. Since many rework causes emanate from the design phase, effective design management has been reported as a key to reducing rework [21]. Research undertaken by [29] who examined 161 projects revealed that ‘design changes’ accounted for 50% of rework costs incurred in projects. Based on the above discussion, rework clearly has a huge impact on the ability of construction projects to meet their time and cost constraints. While the various studies in the literature help in recognizing the impact of rework and its root causes, no approach has been proposed to incorporate rework within current scheduling and project control tools. The primary objective of this research is to propose a quantitative mechanism for incorporating rework into existing scheduling tools to clearly represent the evolution of progress events directly on the schedule, calculate a revised project duration, consider rework in project delay analysis, and help in devising costeffective corrective actions. The research first discusses various ways that rework can affect activities and several strategies to accelerate the project to recover schedule delays. Afterwards, the paper introduces a proposed approach for rework representation, schedule analysis, and corrective action optimization. A case study is then used to demonstrate the proposed approach and, its advantages, and future improvements.
2. Rework Impact on the Schedule Depending on the construction schedule, there are several situations by which a rework event can impact the project activities, completion, and resource use. Four specific cases, from a simple to a more involved case, are defined as follows: a) Rework on a single activity, without resource constraints: In this case, if the affected activity is non-critical, the activity float can absorb the additional time needed to do the rework (if such additional time is within the activity total float). On the other hand, if the affected activity is critical, the amount of time it takes to do the rework constitutes a project delay (if no acceleration is done for the remaining part of the activity). b) Rework on a single activity, with resource constraints: a more practical case for rework impact on a schedule is when the project has limited resources. In this case, even if the activity is noncritical, the amount of time to do the rework will extend the activity duration, thus may cause a resource over allocation that, when resolved, may also lead to project delay.
c) General rework case: in this general case, a rework situation affects multiple activities. For example, when a concrete column needs to be redone because of misalignment, rework becomes necessary in other related activities such as formwork, steel, and concrete. In this general case also, the schedule may have some activities experiencing various events such as contractor slow progress, acceleration, or weather problems. Therefore, rework becomes a documented progress event that combines with all others to impact the project time, cost, and resource use. Based on this discussion, for a contractor to quantitatively analyse the impact of rework on the project schedule, the following three steps are necessary: 1. Record all progress events, including rework, and calculate the expected project delay; 2. Accurately analyze the project delay to identify the number of days attributed to each party's actions (contractor, owner, or neither); then 3. Analyze various acceleration options to determine the least costly action to recover the contractor's own delay. In terms of progress recording, this research extends the earlier research of [14] that represents the progress evolution of the project on a daily basis (calculated from the start and finish dates) for each activity (Fig. 2). The activities are thus represented not as long bars (as in commercial software) but as a group of adjacent cells, each is one day, making up the duration of the activity. This bar chart representation, thus, records not only the daily progress, but also the party responsible for any daily event such as work stops and their reasons / documents, etc. As shown in Fig. 2, if an activity is stopped for owner-related reasons (e.g., late approval of drawings), an “O” is shown on that day. In the same manner, if the delay is contractorrelated (e.g., using slow resources), a “C” is shown. In the case of events that are not attributable to the owner or contractor (e.g., weather), an “N” is shown. If an event occurs due to concurrent actions of several parties, then a combination of these three letters is shown (e.g., “O + N” or “O + C”), with the reasons recorded as comments in the related cells. This representation can therefore be extended to record rework events and facilitate its related calculations. It is important to note that this research assumes that all data related to resources, costs, delays, rework, and responsible parties can be collected and recorded. While data collection is not part of the paper's scope, the data can be obtained (to a good level of detail) from site reports, which can be daily, weekly, or monthly. With the absence of a detailed procedure for analyzing the impact of this data on the schedule and on corrective actions, the paper's focus is on developing an analysis procedure that can produce as accurate results as the level of information available. As mentioned earlier, delay analysis is an important step in determining the amount of time that needs to be shortened from Day No. 1 2
Plan Excavation Foundation Joining Walls
3
4
5
6
7
9
10
33% 33% 34% 50% 50%
Actual Excavation Foundation Joining Walls
8
50% 50%
50%
O
C+O
Project Delay 3 days
50% 25%
15%
60% 25%
Slow Progress
Work Stop Data Responsibility: Owner (O) Reason : Unexpected Rock
Acceleration
Fig. 2. Progress recording.
50%
25%
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
Mitigation Strategies
Change Activities’ Logical Relations
Improve Productivity for Critical Activities
Expedite Delivery of Materials
Fig. 3. Project acceleration strategies.
project duration to remain within the project deadline. Delay analysis is an analytical process to apportion the project delays among the responsible parties [15]. One of the most credible methods described in the literature is the windows delay analysis method [2,9,12,13,18,27]. In order to capture and consider all variations in critical path(s), multiple baselines, and the impact of delays on resource over allocation, the Daily Windows Analysis method proposed by [12] is utilized and improved in this study to consider rework. Once the amount of delay time attributable to a specific party is determined, that party can overcome its own delays through various acceleration strategies. As shown in Fig. 3, the three common types of acceleration strategies include: (1) changing the logical relations among the activities (i.e., having more parallel, rather than sequential, relations to save time); (2) expediting the delivery of materials with long lead time; and (3) selecting more productive construction methods (using overtime or more resources) in the project's critical activities to reduce project duration (sometimes referred to as schedule compression or schedule crashing). Logically, critical activities are the ones to target for crashing. However, the selection of which critical activity(ies) to accelerate and which of their construction method to use (slow and cheap versus fast and expensive) is basically a cost minimization problem.
1053
For better progress documentation and project control, this research proposes a new representation of rework events on the schedule. It considers rework amount as a negative percentage complete that is assigned on a specific date to the affected activity. As an example, Fig. 5 shows a concreting activity for 10 columns, with the rate of 2 columns per day (planned duration is 5 days). During construction, by the end of the third day where 6 columns were completed (1 column in day 1, an accelerated progress of 4 columns in day 2, and a 1 column in day 3), the site supervisor discovered a misalignment in 2 of the previously constructed columns, which need to be redone. With the amount of rework being 20% (2 columns), a “C20%” is added to the progress of day 3 (bottom bar in Fig. 5) to signify both the progress that is done (10%) plus the observed rework (C20%). As such, the activity total percent complete at the end of day 3, considering the rework amount becomes 40% (10% + 40% + 10% − 20% = 40%). With this simple and logical representation, the schedule can show all the information about rework timing, amount, and responsibility. This approach, therefore, can be a simple extension to the daily progress representation shown earlier in Fig. 2. It is important to note that in practice, minor rework can happen and can possibly be accommodated within the regular work of that day, thus requires no specific rework documentation on the schedule. The representation in Fig. 5, therefore, is for the rework items that meaningfully impact the remaining activity progress. In terms of rework amount, the rework percentage is calculated as a percentage of the total activity quantity. Having the rework represented as a negative progress, it is then possible to calculate a modified activity percentage complete (MPC%), as follows: MPC% = Actual Progress To Date ð%Þ–Rework Amount ð%Þ
ð1Þ
Accordingly, Modified Activity Duration can be calculated as follows:
3. Schedule Analysis Considering Rework The proposed schedule analysis mechanism incorporates three main aspects: (1) new schedule representation of rework; (2) a delay analysis procedure considering rework; and (3) an optimization mechanism to accelerate the project by the number of identified delay days, in a cost effective manner. These are discussed in detail in the following subsections. 3.1. Representing Rework on a Single Activity Available project management tools have standardized schedule representation for the activities and their progress percentage complete, as shown in Fig. 4. This representation, as such, shows only the activity's latest status, without any details about the evolution of events that led to this status. Since each activity is a continuous bar of with a given duration, it cannot show on the schedule a rework event on a specific date and with a specific amount. While it is possible to manipulate the software by splitting the activity, adding a new activity for the rework event, and adjusting the logical relationships, this process, however, is cumbersome and confusing for projects with a large number of activities.
Modified Activity Duration = Actual Duration To Date + Remaining Duration Where; Remaining Duration = Planned Duration ð1−MPCÞ
ð2Þ ð3Þ
For example, in Fig. 5, the remaining duration of the activity after the end of day 3, according to Eq. (3), becomes [5 × (1 − 0.4)] = 3 days, as shown in the figure. 3.2. Representing Rework on Multiple Activities Since rework can affect more than one activity, it is important to adjust the representation to clearly show the activity that initiates the rework. As such, a generic rework representation is shown in the example in Fig. 6. Fig. 6a shows a 10-day plan with all resources within the specified limit (2/day). In the first 8 days, several progress events are shown, including work stops by the owner and the contractor. On the current progress date (day 9), a rework was identified and documented as shown in Fig. 6b. In this case, where the rework affects multiple activities, a (C-25%) is recorded for activity E,
Fig. 4. Typical progress representation in scheduling software.
1054
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
Day No. Plan for 10 columns
Actual without Rework
Actual with Contractor Rework of 20% on day 3
1
2
3
4
5
6
20%
20%
20%
20%
20%
10%
40%
10%
20%
20%
10%
40%
10% + C-20%
20%
20%
20%
Remaining Fig. 5. Representing rework as negative percentage complete.
(a) Planned schedule Day Number 1
2
3
4
5
6
7
8
9
10
A B C D
Resource Limit = 2 /day
E
Planned Finish
F Resource
2
2
2
2
2
2
2
2
1
1
(b) Rework on multiple activities on day 9 – Before resolving resource over-allocation Day Number 1
2
50%
50%
Current Date 3
4
5
6
7
8
9
10
11
12
13
8%
Before resolving resource over allocation
A O
B
25%
C
50%
-33% 25%
25%
25%
25%
50% C
D
50%
50%
E F
50%
50% + C-25
2
2
Completed progress from day 1 to day 8
Resource
2
2
2
1
2
1
2
25%
Remaining 3
1
10
11
50% 1
50% 1
12
13
(c) After resolving the resource over-allocation in part (b) A
1
2
50%
50%
3
4
5
6
7
8
O
B
25%
C
50%
25%
25%
25%
8%
50% C 50%
50%
E
50%
50% + C-25
2
2
F
25%
Remaining 2
2
2
1
2
14
After resolving resource over allocation
-33% 25%
D
Resource
9
1
2
1
Fig. 6. Simple case study with rework on multiple activities.
1
2
50% 1
50% 1
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
1055
Fig. 8 (some days are skipped because they exhibit no change). In each window (day), actual progress is entered on the left side and the remaining schedule is calculated (with resource over allocations resolved) on the right side. Any consequent project delay is thus attributed to the party that caused the delay on current date. Following this process, the analysis of the window of day 6 (top part in Fig. 8) shows a project duration of 11 days, thus exhibiting no project delays from the events of days 4 and 5 (in Fig. 7). As such, the contractor's work stop (C) on activity D in window 6 did not cause project delay (only affected a non-critical path). Continuing this daily process to days 7, then day 8 (middle part in Fig. 8), the project duration is still 11, without further delays attributable to any party. Proceeding to day 9 (bottom part of Fig. 8), the rework on the activities B and E was entered, then the resource over-allocation was resolved (as discussed on Fig. 6) to produce a project duration of 14 days (3 days delay from the previous window duration). Since the events of day 9, including the rework, are all attributable to the contractor, the analysis of window 9 then assigns a 3 day delay responsibility to the contractor. Accordingly, the conclusion of the daily windows analysis for the progress events until day 9 is an expected project delay of 4 days (from the 10-day deadline), apportioned as one delay due to Owner's events, and three days due to Contractor's events. This small example, as such, demonstrates the importance of accurately recording and analyzing all progress events before a corrective action plan can be determined. Based on this analysis, a flowchart of a systematic delay analysis process is presented in Fig. 9. To continue with this case study, the contractor's rework on multiple activities is considered for further analysis.
indicating that E is the driving activity, which then triggered rework in activity B (33% rework). Once rework is specified, the remaining schedule is then calculated using Eqs. (1) to (3), following the activities’ logical relationships. Accordingly, the case in Fig. 6b will extend the project to day 13 before resolving the resource over allocation (Fig. 6b); and to day 14 after resolving the resource over allocation (Fig. 6c). It is noted that due to the rework, activity B needs to be extended two days since planned progress is 25% daily, while the rework amount is 33%. A basic assumption in the calculation of remaining duration is that the remaining work follows the planned progress percentage in each day. At this point, it is necessary for the contractor to consider all the daily events, rework, and resource limits to calculate its share of project delay, and then determine a schedule corrective action to recover that delay. These are discussed in the following subsections. 4. Delay Analysis Considering Rework Based on the daily representation of events shown in Fig. 6, the basic daily windows analysis of [12] has been modified to accommodate the representation and analysis of Rework events as well the consideration of resource over-allocation in delay analysis. The modified daily windows analysis has been demonstrated on the case study in Fig. 6. Since the first three days of progress followed the plan, the daily windows analysis starts from day 4. As shown in Fig. 7, the owner's work stop (O) on activity B caused an extension to the activity duration, thus, causing a resource over allocation on day 7. When the contractor resolves the resource allocation (by delaying activity E one day, as shown), a project delay of one day is anticipated. As such, according to the events of day 4, the project will be delayed one day due to the owner's action. Following this process, the events of each day are analyzed and the responsibility is accumulated, as shown in
5. Optimizing Corrective Action Decision Once the delay analysis results are computed (Owner (1) and Contractor (3)), the contractor now can present the analysis results to
Before Resource allocation A
1
2
50%
50%
3
4
5
6
7
8
9
10
2
Resource Over allocation 2 2
3
2
1
1
4
5
7
8
9
10
O
B
25%
C
50%
50%
D E F Resource
2
2
2
After Resource allocation A
1
2
50%
50%
3
25%
C
50%
50%
D
Responsibility: Owner: Contractor:
1
E F 2
2
2
2
11
Cumulative Result: Day 4 1 Project Delay:
O
B
Resource
6
Start delay = 1 day for activity E to avoid resource problem 2 2 1
2
Fig. 7. Daily windows analysis — day 4.
2
1
1
1 0
1056
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
Day 6 A
1
2
50%
50%
3
4
5
6
7
8
9
10
Result of days 1-6: Owner: 1 Contractor: 0
O
B
25%
C
50%
25%
25%
11
25%
25% C
D
50%
50%
E
50%
50%
F Resource
2
2
2
2
2
2
2
2
2
50% 1
50% 1
Day 8
1
2
3
4
5
6
7
8
9
10
11
50%
50% 25%
25%
25%
A
Result of days 1-8: Owner: 1 Contractor: 0
O
B
25%
C
50%
25% C
D
50%
50%
E
50%
50%
2
F Resource
2
2
2
2
2
2
2
2
Day 9
1
2
3
4
5
6
7
8
50%
50%
A
25%
C
11
12
13
14
50%
-33% 25%
25%
25%
25%
Total Owner: 1 Total Contractor: 3
8%
50% C
D
50%
50%
E
50%
50% + C-25
2
2
F Resource
10
50% 1
Day 9 O
B
9
50% 1
2
2
2
1
2
1
2
25%
1
1
2
50% 1
50% 1
Fig. 8. Daily windows analysis — days 6, 8, and 9.
the owner to decide between two options: (1) request one day extension due to the owner delay and try to overcome its own three delay days through acceleration; (2) accelerate the project for all the delay days, considering a one day owner-directed acceleration. In general, however, the ability of the contractor to overcome delays depends on when the rework is discovered and scheduled. The earlier the rework occurs in the project, the less the impact and the more options are available to overcome this impact. For the present case study, the rework was introduced close to the end of the project. However, for demonstration purposes it is assumed that the owner has approved a one-day project extension. The contractor therefore is seeking to accelerate the project three days and meet an 11-day deadline duration, without violating resource limits. To facilitate corrective action planning, this research uses optimization to help the contractor select the best acceleration strategy. The mechanism is basically a total cost minimization under time and resource constraints, considering any penalty, incentive, and indirect costs. To enable the optimization, optional execution methods (e.g., larger crew formations, better equipment, and/or overtime hours) need to be identified for the remaining activities in the schedule. In essence, two basic decisions are needed for each of the remaining activities: (1) the execution method (e.g., normal
versus a speedier and costly option) to meet deadline at minimum cost; and (2) any start time delay of each activity (as applied in Fig. 8 on day 5) to avoid resource over allocation. The combination of these activity decisions, as such, represents a corrective action plan. Because of the various possibilities to speed up one activity versus another and to delay one activity versus another, any real-life project requires some automation to try different combinations until a satisfactory (near optimum) solution is determined. In consistency with the daily progress representation in this paper, a computer prototype, EasyPlan [10] has been modified to consider rework. The prototype has various integrated functions to: manage a simple depository of resources, allow optional execution methods to be specified, apply optimization to try different combinations of decisions, record actual progress and work interruptions, and produce various reports. The three main changes made to EasyPlan to consider rework are: rework representation, modified resource allocation, modified delay analysis, and modified optimization process. The modified schedule optimization feature then optimizes corrective action by selecting the optimum combination of decisions (execution methods and start delays) for the remaining activities in the schedule. Applying the prototype to the case study, optional construction methods were specified as shown in Fig. 10 in terms of cost, duration,
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
Record all progress events Remove all progress events to get the as-planned schedule Stop yes Day > Progress date
Day = 1 (window 1) CPD = Current project duration No Add events of this day Calculate remaining schedule
Day = Day+1 CPD = NPD
Resolve over allocation - NPD = New project duration - Project delay d =NPD - CPD No (d = 0)
1057
Once the baseline was saved, actual progress data for the first 9 days were entered (top schedule in Fig. 12) with rework specified as a negative percentage complete. The figure shows two bars for each activity: baseline (top), and actual progress (bottom). Once actual progress was entered, project duration became 13 days (before resolving the resource over allocation), as discussed before. To meet an 11-day deadline and the resource limits, the modified optimization feature of the EasyPlan was activated. The optimization has two options: (1) simple heuristic approach based on well known resource levelling and time-cost trade-off heuristics [11], which is fast but may not reach the best solution; and (2) a genetic algorithm-based optimization which requires time to search for a near-optimum solution. In this simple case study, because of the activities’ limited options, the heuristic solution was sufficient to provide an 11-day solution, without resource over allocation (the bottom schedule in Fig. 12). The corrective action plan involves using speedy construction methods for activities B and F, which makes the project more costly but avoids more expensive penalty for any daily delay in project completion.
d>0 7. Concluding Remarks
yes Allocate responsibility for the d days
Fig. 9. Flowchart of the delay analysis process.
and resource amount for each activity. As opposed to existing scheduling tools where each activity typically has a single duration and cost, Fig. 10 shows the ability to specify estimates that vary from cheap and slow to fast and expensive activity. The options then become an important part of deciding the cheapest activities to speed (crash) in order to recover project delays and keep meeting the deadline. After specifying the activities options in Fig. 10, the activities’ logical relationships were specified as shown in Fig. 11 (by specifying the index to the predecessor activities, as shown). As shown in Fig. 11 also, each activity was set to use its cheapest construction methods (index 1 for all activities). Once this was done, a baseline schedule was then obtained (as shown in Fig. 11), with baseline duration of 10 days. Since the baseline schedule has not resource over-allocation (i.e., the daily resources of the schedule are within the resource limit), the start-delay values of the activities (see Fig. 11 are set to zeros).
This research contributes to the provision of quantitative scheduling tools that consider rework and support decisions for recovering delays. This study showed that the day-by-day segmentation of activity duration can be beneficial in representing all progress events including rework. Scheduling in this case becomes more responsive to the specific timings of various progress events (i.e., detailed progress evolution), not just presenting the cumulative percentage complete (progress end result). This paper thus served as a proof-of-concept and extensive experimentation on real-life projects is currently ongoing. More research is also needed to improve the schedule in terms of visualization, allow external resources to be used for doing the rework, manage the schedule of resources between new progress and rework, and incorporate a change-order management feature. Other future research to improve the present model as a project control tool is to incorporate cash flow analysis, earned value analysis, performance indices, and productivity analysis. In addition, a survey is currently being prepared to interview experienced scheduling professionals and contract experts to evaluate the impact of the proposed approach on current practice and the need to incorporate the analysis of rework in the scheduling specification of the project. One last note is that existing software tools have been improving much in terms of collaboration, graphics, etc., but not much in terms of the necessary project management features such as rework, delay analysis, time-cost trade-off, and optimization. Because of the importance of these aspects to the day-to-day project management
Menu options
Cost, Duration, & Resources Cost, Duration, & Resources of a Fast and Expensive of a Slow and Cheap estimate estimate Fig. 10. Specifying activities' optional methods.
1058
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
Start delays for resolving resource over-allocation (all zeros since resources are not over-allocated)
Logical relations Cheaper estimates (index 1) are used. Activities durations Index of and costs of the predecessor cheapest estimates activities
Index of the cheapest estimates
Fig. 11. Logical relations and baseline schedule.
Progress events including rework
Optimization changed the methods to meet target deadline
Fig. 12. Actual progress before and after optimization.
process, having them as standard features in widely used commercial software is long overdue.
References [1] H. Abdul-Rahman, The cost of non-conformance during a highway project: a case study, Constr. Mgmt. Econ. 13 (1) (1995) 23–32.
[2] D. Arditi, T. Pattanakitchamroon, Selecting a delay analysis method in resolving construction claims, Int. J. Proj. Mgmt. 24 (2) (2006) 145–155. [3] J.L. Ashford, The Management of Quality in Construction, E & F Spon, London, U.K, 1992. [4] P. Barber, A. Graves, M. Hall, D. Sheath, C. Tomkins, Quality failure costs in civil engineering projects, Int. J. Qual. Reliab. Mgmt. 17 (4/5) (2000) 479–492. [5] J.L. Burati, J.J. Farrington, W.B. Ledbetter, Causes of quality deviations in design and construction, J. Constr. Engrg. and Mgmt. ASCE 118 (1) (1992) 34–49. [6] Construction Industry Institute (CII), Costs of quality deviations in design and construction, The Univ. of Texas at Austin, Austin, Texas, 1989, RS 10–1 (Jan.).
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059 [7] K.G. Cooper, The rework cycle: benchmarks for the project manager, Proj. Mgmt. J. 24 (1) (1993) 17–21. [8] A.R. Fayek, M. Dissanayake, O. Campero, Measuring and Classifying Construction Field Rework: A Pilot Study, Research Rep. (May), Construction Owners Association of Alberta (COAA), The University of Alberta, Edmonton, Al., Canada, 2003. [9] M. Finke, Window analysis of compensable delays, J. Constr. Engrg. and Mgmt. ASCE 125 (2) (1999) 96–100. [10] T. Hegazy, “Simplified project management for construction practitioners”, Cost Eng. J. AACE Int. 48 (11) (2006) 20–28. [11] T. Hegazy, Computer-Based Construction Project Management, Prentice Hall, Upper Saddle River, NJ, USA, 2002. [12] T. Hegazy, W. Menesi, Delay analysis under multiple baseline updates, J. Constr. Engrg. and Mgmt. 134 (8) (2008) 575–582. [13] T. Hegazy, K. Zhang, Daily windows delay analysis, J. Constr. Engrg. and Mgmt. ASCE 131 (5) (2005) 505–512. [14] T. Hegazy, E. Elbeltagi, K. Zhang, Keeping better site records using intelligent bar charts, J. Constr. Engrg. and Mgmt. ASCE 131 (5) (2005) 513–521. [15] S. Holloway, Introductory concepts in delay claims, Constr. Law and Business. 2 (6) (2002) 3–6. [16] B.G. Hwang, S.R. Thomas, C.T. Haas, C.H. Caldas, Measuring the impacts of rework on construction cost performance, J. Constr. Engrg. and Mgmt. ASCE 135 (3) (2009) 187–198. [17] P.E. Josephson, Y. Hammarlund, The causes and costs of defects in construction: a study of seven building projects, Automation in Construction 8 (6) (1999) 681–687. [18] S. Kartam, Generic methodology for analyzing delay claims, J. Constr. Engrg. and Mgmt. ASCE 125 (6) (1999) 409–419.
1059
[19] P.E.D. Love, D.J. Edwards, H. Watson, P. Davis, “Rework in civil infrastructure projects: determination of cost predictors”, J. Constr. Engrg. and Mgmt. ASCE 136 (3) (2010) 275–282. [20] P.E.D. Love, D. Edwards, Forensic project management: the underlying causes of rework in construction projects, Civ. Eng. Environ. Syst. 12 (3) (2004) 207–228. [21] P.E.D. Love, J. Smith, Bench-marking, bench-action and bench-learning: rework mitigation in projects, J. Mgmt. Eng. ASCE 19 (4) (2003) 147–159. [22] P.E.D. Love, H. Li, Quantifying the causes and costs of rework in construction, Constr. Mgmt. Econ. 18 (4) (2000) 479–490. [23] P.E.D. Love, P. Mandal, H. Li, Determining the casual structure of rework influences in construction, Constr. Mgmt. Econ. 17 (4) (1999) 505–517. [24] J.M. Lyneis, D.N. Ford, System dynamics applied to project management: a survey, assessment, and directions for future research, Syst. Dyn. Rev. 23 (2–3) (2007) 157–189. [25] J.T. O'Conner, R.L. Tucker, Industrial project constructability improvement, J. Constr. Engrg. and Mgmt. ASCE 112 (1) (1986) 69–82. [26] J.Y. Ruwanpura, D. Meek, T. Nutting, D. Greaves, J. Hamlin, M. Timler, Most significant causes for rework due to engineering deliverables, in: M. Massièra, N. El-Jabi (Eds.), Proceedings of the 5th Construction Specialty Conference, CSCE, Moncton, N.B, 2003, June 2003. [27] G.R. Stumpf, Schedule delay analysis, Cost. Eng. Jr. AACE Int 42 (7) (2000) 32–43. [28] K. Davis, W.B. Ledbetter, J.L. Burati, Measuring design and construction quality costs, J. Constr. Engrg. and Mgmt. ASCE 115 (3) (1989) 385–400. [29] P.E.D. Love, Influence of Project Type and Procurement Method on Rework Costs in Building Construction Projects, J. Constr. Engrg. and Mgmt. ASCE 128 (1) (2002) 18–29.
Contents lists available at ScienceDirect
Automation in Construction j o u r n a l h o m e p a g e : w w w. e l s ev i e r. c o m / l o c a t e / a u t c o n
Incorporating rework into construction schedule analysis Tarek Hegazy a,⁎, Mohamed Said a,1, Moustafa Kassab b,1 a b
Civil and Environmental Engineering Department, University of Waterloo, Waterloo, Ontario, Canada N2L 3G1 Systems Design Engineering Department, University of Waterloo, Waterloo, Ontario, Canada, N2L 3G1
a r t i c l e
i n f o
Article history: Accepted 5 April 2011 Available online 13 May 2011 Keywords: Construction management Rework Delay analysis Cost Acceleration Scheduling Optimization Computer application
a b s t r a c t Rework has been a primary cause of cost and schedule overruns in large construction projects. While several research efforts have analyzed the causes and effects of rework and provided guidelines to reduce rework, almost no research exists to analyze the impact of rework timing and quantity on schedule delays and to support decisions on cost effective recovery. This research presents a quantitative mechanism for schedule analysis considering rework. The mechanism has three aspects: (1) a new schedule representation of rework magnitude as negative percentage complete for affected activities, documented on the specific date on which the rework is detected; (2) a modified daily-windows delay analysis to apportion project delays among the responsible parties; and (3) an optimization technique for determining the least costly corrective action strategy that recovers project delays. The proposed approach is applied to a case study to demonstrate its ability to consider rework impact, in combination with other progress events by other project parties. This research offers an innovative quantitative approach to consider rework timing and amount in delay analysis and corrective action optimization. © 2011 Elsevier B.V. All rights reserved.
1. Introduction Rework is a serious problem facing large and complex construction projects, particularly industrial projects that involve multiple parties such as contractors, suppliers, and trades. In such a complex environment where many activities by many parties take place simultaneously, often errors, omissions, and misunderstandings cause undesirable outcomes that have to be reworked. Rework, thus, has been defined as the effort of re-doing a process or activity that was incorrectly implemented the first time [22]. In literature, the term “rework” has been related to other terms such as “quality deviations” [5], “non-conformance” [1,3], “defects” [17], and “quality failures” [4]. Since rework can occur at different stages in the project life cycle, the term “field rework” has been clarified not to incorporate change orders or off-site fabrication errors [8]. Various researchers have studied rework from different perspectives such as rework cycle, root causes, and impact on project performance [19]. [7] introduced the concept of the rework cycle in projects, where the rework itself is not done properly, thus requiring further rework in a recursive cycle that can extend project duration far beyond what is originally conceived. This concept becomes important to the understanding of the interactions
⁎ Corresponding author. Tel.: + 1 519 8884567x32174; fax: + 1 519 888 6197. E-mail addresses: [email protected] (T. Hegazy), [email protected] (M. Said), [email protected] (M. Kassab). 1 Tel.: + 1 519 888 4567x33869. 0926-5805/$ – see front matter © 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.autcon.2011.04.006
among various project factors including rework, which can be studied using system dynamics tools [24]. With respect to root causes, several studies and surveys were conducted to identify and classify the root causes of rework such as [21]; [25]; [6]; [28]; [5]; [23]; [8]; [20]; [26] and [16]. Almost all studies reported that rework plays a major role in cost and schedule overruns. They identified the main root causes of rework as: errors, omissions, failures, damages, poor leadership, poor communication, and ineffective decisionmaking. The survey of [21], for example, reported the direct and indirect costs of rework observed in various contract types and identified rework causes related to the design team, client, site management, and subcontractors. Among the various project types, industrial projects have been reported by [16] to exercise the most cost increase due to rework. With respect to the impact of rework on project performance, various researchers reported observations from case studies, surveys, and interviews among professionals. A summary of the rework cost reported in various studies is shown in Fig. 1. With most studies analyzing rework-related cost performance, [16] recommended conducting further studies on rework impact on schedule performance. The direct costs of rework, however, have been reported to be in excess of 15% of the contract value [4,19]. Using a survey of 115 civil infrastructure projects, it was revealed that the following five significant predictors accounted for 25% of the variance in total rework cost: (1) ineffective use of information technologies; (2) excessive client involvement in the project; (3) lack of clearly defined working procedures; (4) changes made at the request of the client; and (5) insufficient changes initiated by the
1052
14 %
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
Cost of rework (% of total project cost)
12 % 10 %
12.4%
8% 6%
5%
2-6%
10%
5% 3.15%
(1) CII (1989) (2 Josephson and Hammarlund (1999) (3) Love and Li (2000)
(6) Rail way
(5) Heavy Eng. / Industrial
(4) Highway
(3) Residential
(2) Commercial, Industrial
(1) All types
4%
(4) Abdul-Rahman (1995) (5) Burati et al. (1992) (6) Nylén (1996)
Fig. 1. Cost impacts of rework reported in various studies.
contractor to improve quality [19]. Since many rework causes emanate from the design phase, effective design management has been reported as a key to reducing rework [21]. Research undertaken by [29] who examined 161 projects revealed that ‘design changes’ accounted for 50% of rework costs incurred in projects. Based on the above discussion, rework clearly has a huge impact on the ability of construction projects to meet their time and cost constraints. While the various studies in the literature help in recognizing the impact of rework and its root causes, no approach has been proposed to incorporate rework within current scheduling and project control tools. The primary objective of this research is to propose a quantitative mechanism for incorporating rework into existing scheduling tools to clearly represent the evolution of progress events directly on the schedule, calculate a revised project duration, consider rework in project delay analysis, and help in devising costeffective corrective actions. The research first discusses various ways that rework can affect activities and several strategies to accelerate the project to recover schedule delays. Afterwards, the paper introduces a proposed approach for rework representation, schedule analysis, and corrective action optimization. A case study is then used to demonstrate the proposed approach and, its advantages, and future improvements.
2. Rework Impact on the Schedule Depending on the construction schedule, there are several situations by which a rework event can impact the project activities, completion, and resource use. Four specific cases, from a simple to a more involved case, are defined as follows: a) Rework on a single activity, without resource constraints: In this case, if the affected activity is non-critical, the activity float can absorb the additional time needed to do the rework (if such additional time is within the activity total float). On the other hand, if the affected activity is critical, the amount of time it takes to do the rework constitutes a project delay (if no acceleration is done for the remaining part of the activity). b) Rework on a single activity, with resource constraints: a more practical case for rework impact on a schedule is when the project has limited resources. In this case, even if the activity is noncritical, the amount of time to do the rework will extend the activity duration, thus may cause a resource over allocation that, when resolved, may also lead to project delay.
c) General rework case: in this general case, a rework situation affects multiple activities. For example, when a concrete column needs to be redone because of misalignment, rework becomes necessary in other related activities such as formwork, steel, and concrete. In this general case also, the schedule may have some activities experiencing various events such as contractor slow progress, acceleration, or weather problems. Therefore, rework becomes a documented progress event that combines with all others to impact the project time, cost, and resource use. Based on this discussion, for a contractor to quantitatively analyse the impact of rework on the project schedule, the following three steps are necessary: 1. Record all progress events, including rework, and calculate the expected project delay; 2. Accurately analyze the project delay to identify the number of days attributed to each party's actions (contractor, owner, or neither); then 3. Analyze various acceleration options to determine the least costly action to recover the contractor's own delay. In terms of progress recording, this research extends the earlier research of [14] that represents the progress evolution of the project on a daily basis (calculated from the start and finish dates) for each activity (Fig. 2). The activities are thus represented not as long bars (as in commercial software) but as a group of adjacent cells, each is one day, making up the duration of the activity. This bar chart representation, thus, records not only the daily progress, but also the party responsible for any daily event such as work stops and their reasons / documents, etc. As shown in Fig. 2, if an activity is stopped for owner-related reasons (e.g., late approval of drawings), an “O” is shown on that day. In the same manner, if the delay is contractorrelated (e.g., using slow resources), a “C” is shown. In the case of events that are not attributable to the owner or contractor (e.g., weather), an “N” is shown. If an event occurs due to concurrent actions of several parties, then a combination of these three letters is shown (e.g., “O + N” or “O + C”), with the reasons recorded as comments in the related cells. This representation can therefore be extended to record rework events and facilitate its related calculations. It is important to note that this research assumes that all data related to resources, costs, delays, rework, and responsible parties can be collected and recorded. While data collection is not part of the paper's scope, the data can be obtained (to a good level of detail) from site reports, which can be daily, weekly, or monthly. With the absence of a detailed procedure for analyzing the impact of this data on the schedule and on corrective actions, the paper's focus is on developing an analysis procedure that can produce as accurate results as the level of information available. As mentioned earlier, delay analysis is an important step in determining the amount of time that needs to be shortened from Day No. 1 2
Plan Excavation Foundation Joining Walls
3
4
5
6
7
9
10
33% 33% 34% 50% 50%
Actual Excavation Foundation Joining Walls
8
50% 50%
50%
O
C+O
Project Delay 3 days
50% 25%
15%
60% 25%
Slow Progress
Work Stop Data Responsibility: Owner (O) Reason : Unexpected Rock
Acceleration
Fig. 2. Progress recording.
50%
25%
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
Mitigation Strategies
Change Activities’ Logical Relations
Improve Productivity for Critical Activities
Expedite Delivery of Materials
Fig. 3. Project acceleration strategies.
project duration to remain within the project deadline. Delay analysis is an analytical process to apportion the project delays among the responsible parties [15]. One of the most credible methods described in the literature is the windows delay analysis method [2,9,12,13,18,27]. In order to capture and consider all variations in critical path(s), multiple baselines, and the impact of delays on resource over allocation, the Daily Windows Analysis method proposed by [12] is utilized and improved in this study to consider rework. Once the amount of delay time attributable to a specific party is determined, that party can overcome its own delays through various acceleration strategies. As shown in Fig. 3, the three common types of acceleration strategies include: (1) changing the logical relations among the activities (i.e., having more parallel, rather than sequential, relations to save time); (2) expediting the delivery of materials with long lead time; and (3) selecting more productive construction methods (using overtime or more resources) in the project's critical activities to reduce project duration (sometimes referred to as schedule compression or schedule crashing). Logically, critical activities are the ones to target for crashing. However, the selection of which critical activity(ies) to accelerate and which of their construction method to use (slow and cheap versus fast and expensive) is basically a cost minimization problem.
1053
For better progress documentation and project control, this research proposes a new representation of rework events on the schedule. It considers rework amount as a negative percentage complete that is assigned on a specific date to the affected activity. As an example, Fig. 5 shows a concreting activity for 10 columns, with the rate of 2 columns per day (planned duration is 5 days). During construction, by the end of the third day where 6 columns were completed (1 column in day 1, an accelerated progress of 4 columns in day 2, and a 1 column in day 3), the site supervisor discovered a misalignment in 2 of the previously constructed columns, which need to be redone. With the amount of rework being 20% (2 columns), a “C20%” is added to the progress of day 3 (bottom bar in Fig. 5) to signify both the progress that is done (10%) plus the observed rework (C20%). As such, the activity total percent complete at the end of day 3, considering the rework amount becomes 40% (10% + 40% + 10% − 20% = 40%). With this simple and logical representation, the schedule can show all the information about rework timing, amount, and responsibility. This approach, therefore, can be a simple extension to the daily progress representation shown earlier in Fig. 2. It is important to note that in practice, minor rework can happen and can possibly be accommodated within the regular work of that day, thus requires no specific rework documentation on the schedule. The representation in Fig. 5, therefore, is for the rework items that meaningfully impact the remaining activity progress. In terms of rework amount, the rework percentage is calculated as a percentage of the total activity quantity. Having the rework represented as a negative progress, it is then possible to calculate a modified activity percentage complete (MPC%), as follows: MPC% = Actual Progress To Date ð%Þ–Rework Amount ð%Þ
ð1Þ
Accordingly, Modified Activity Duration can be calculated as follows:
3. Schedule Analysis Considering Rework The proposed schedule analysis mechanism incorporates three main aspects: (1) new schedule representation of rework; (2) a delay analysis procedure considering rework; and (3) an optimization mechanism to accelerate the project by the number of identified delay days, in a cost effective manner. These are discussed in detail in the following subsections. 3.1. Representing Rework on a Single Activity Available project management tools have standardized schedule representation for the activities and their progress percentage complete, as shown in Fig. 4. This representation, as such, shows only the activity's latest status, without any details about the evolution of events that led to this status. Since each activity is a continuous bar of with a given duration, it cannot show on the schedule a rework event on a specific date and with a specific amount. While it is possible to manipulate the software by splitting the activity, adding a new activity for the rework event, and adjusting the logical relationships, this process, however, is cumbersome and confusing for projects with a large number of activities.
Modified Activity Duration = Actual Duration To Date + Remaining Duration Where; Remaining Duration = Planned Duration ð1−MPCÞ
ð2Þ ð3Þ
For example, in Fig. 5, the remaining duration of the activity after the end of day 3, according to Eq. (3), becomes [5 × (1 − 0.4)] = 3 days, as shown in the figure. 3.2. Representing Rework on Multiple Activities Since rework can affect more than one activity, it is important to adjust the representation to clearly show the activity that initiates the rework. As such, a generic rework representation is shown in the example in Fig. 6. Fig. 6a shows a 10-day plan with all resources within the specified limit (2/day). In the first 8 days, several progress events are shown, including work stops by the owner and the contractor. On the current progress date (day 9), a rework was identified and documented as shown in Fig. 6b. In this case, where the rework affects multiple activities, a (C-25%) is recorded for activity E,
Fig. 4. Typical progress representation in scheduling software.
1054
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
Day No. Plan for 10 columns
Actual without Rework
Actual with Contractor Rework of 20% on day 3
1
2
3
4
5
6
20%
20%
20%
20%
20%
10%
40%
10%
20%
20%
10%
40%
10% + C-20%
20%
20%
20%
Remaining Fig. 5. Representing rework as negative percentage complete.
(a) Planned schedule Day Number 1
2
3
4
5
6
7
8
9
10
A B C D
Resource Limit = 2 /day
E
Planned Finish
F Resource
2
2
2
2
2
2
2
2
1
1
(b) Rework on multiple activities on day 9 – Before resolving resource over-allocation Day Number 1
2
50%
50%
Current Date 3
4
5
6
7
8
9
10
11
12
13
8%
Before resolving resource over allocation
A O
B
25%
C
50%
-33% 25%
25%
25%
25%
50% C
D
50%
50%
E F
50%
50% + C-25
2
2
Completed progress from day 1 to day 8
Resource
2
2
2
1
2
1
2
25%
Remaining 3
1
10
11
50% 1
50% 1
12
13
(c) After resolving the resource over-allocation in part (b) A
1
2
50%
50%
3
4
5
6
7
8
O
B
25%
C
50%
25%
25%
25%
8%
50% C 50%
50%
E
50%
50% + C-25
2
2
F
25%
Remaining 2
2
2
1
2
14
After resolving resource over allocation
-33% 25%
D
Resource
9
1
2
1
Fig. 6. Simple case study with rework on multiple activities.
1
2
50% 1
50% 1
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
1055
Fig. 8 (some days are skipped because they exhibit no change). In each window (day), actual progress is entered on the left side and the remaining schedule is calculated (with resource over allocations resolved) on the right side. Any consequent project delay is thus attributed to the party that caused the delay on current date. Following this process, the analysis of the window of day 6 (top part in Fig. 8) shows a project duration of 11 days, thus exhibiting no project delays from the events of days 4 and 5 (in Fig. 7). As such, the contractor's work stop (C) on activity D in window 6 did not cause project delay (only affected a non-critical path). Continuing this daily process to days 7, then day 8 (middle part in Fig. 8), the project duration is still 11, without further delays attributable to any party. Proceeding to day 9 (bottom part of Fig. 8), the rework on the activities B and E was entered, then the resource over-allocation was resolved (as discussed on Fig. 6) to produce a project duration of 14 days (3 days delay from the previous window duration). Since the events of day 9, including the rework, are all attributable to the contractor, the analysis of window 9 then assigns a 3 day delay responsibility to the contractor. Accordingly, the conclusion of the daily windows analysis for the progress events until day 9 is an expected project delay of 4 days (from the 10-day deadline), apportioned as one delay due to Owner's events, and three days due to Contractor's events. This small example, as such, demonstrates the importance of accurately recording and analyzing all progress events before a corrective action plan can be determined. Based on this analysis, a flowchart of a systematic delay analysis process is presented in Fig. 9. To continue with this case study, the contractor's rework on multiple activities is considered for further analysis.
indicating that E is the driving activity, which then triggered rework in activity B (33% rework). Once rework is specified, the remaining schedule is then calculated using Eqs. (1) to (3), following the activities’ logical relationships. Accordingly, the case in Fig. 6b will extend the project to day 13 before resolving the resource over allocation (Fig. 6b); and to day 14 after resolving the resource over allocation (Fig. 6c). It is noted that due to the rework, activity B needs to be extended two days since planned progress is 25% daily, while the rework amount is 33%. A basic assumption in the calculation of remaining duration is that the remaining work follows the planned progress percentage in each day. At this point, it is necessary for the contractor to consider all the daily events, rework, and resource limits to calculate its share of project delay, and then determine a schedule corrective action to recover that delay. These are discussed in the following subsections. 4. Delay Analysis Considering Rework Based on the daily representation of events shown in Fig. 6, the basic daily windows analysis of [12] has been modified to accommodate the representation and analysis of Rework events as well the consideration of resource over-allocation in delay analysis. The modified daily windows analysis has been demonstrated on the case study in Fig. 6. Since the first three days of progress followed the plan, the daily windows analysis starts from day 4. As shown in Fig. 7, the owner's work stop (O) on activity B caused an extension to the activity duration, thus, causing a resource over allocation on day 7. When the contractor resolves the resource allocation (by delaying activity E one day, as shown), a project delay of one day is anticipated. As such, according to the events of day 4, the project will be delayed one day due to the owner's action. Following this process, the events of each day are analyzed and the responsibility is accumulated, as shown in
5. Optimizing Corrective Action Decision Once the delay analysis results are computed (Owner (1) and Contractor (3)), the contractor now can present the analysis results to
Before Resource allocation A
1
2
50%
50%
3
4
5
6
7
8
9
10
2
Resource Over allocation 2 2
3
2
1
1
4
5
7
8
9
10
O
B
25%
C
50%
50%
D E F Resource
2
2
2
After Resource allocation A
1
2
50%
50%
3
25%
C
50%
50%
D
Responsibility: Owner: Contractor:
1
E F 2
2
2
2
11
Cumulative Result: Day 4 1 Project Delay:
O
B
Resource
6
Start delay = 1 day for activity E to avoid resource problem 2 2 1
2
Fig. 7. Daily windows analysis — day 4.
2
1
1
1 0
1056
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
Day 6 A
1
2
50%
50%
3
4
5
6
7
8
9
10
Result of days 1-6: Owner: 1 Contractor: 0
O
B
25%
C
50%
25%
25%
11
25%
25% C
D
50%
50%
E
50%
50%
F Resource
2
2
2
2
2
2
2
2
2
50% 1
50% 1
Day 8
1
2
3
4
5
6
7
8
9
10
11
50%
50% 25%
25%
25%
A
Result of days 1-8: Owner: 1 Contractor: 0
O
B
25%
C
50%
25% C
D
50%
50%
E
50%
50%
2
F Resource
2
2
2
2
2
2
2
2
Day 9
1
2
3
4
5
6
7
8
50%
50%
A
25%
C
11
12
13
14
50%
-33% 25%
25%
25%
25%
Total Owner: 1 Total Contractor: 3
8%
50% C
D
50%
50%
E
50%
50% + C-25
2
2
F Resource
10
50% 1
Day 9 O
B
9
50% 1
2
2
2
1
2
1
2
25%
1
1
2
50% 1
50% 1
Fig. 8. Daily windows analysis — days 6, 8, and 9.
the owner to decide between two options: (1) request one day extension due to the owner delay and try to overcome its own three delay days through acceleration; (2) accelerate the project for all the delay days, considering a one day owner-directed acceleration. In general, however, the ability of the contractor to overcome delays depends on when the rework is discovered and scheduled. The earlier the rework occurs in the project, the less the impact and the more options are available to overcome this impact. For the present case study, the rework was introduced close to the end of the project. However, for demonstration purposes it is assumed that the owner has approved a one-day project extension. The contractor therefore is seeking to accelerate the project three days and meet an 11-day deadline duration, without violating resource limits. To facilitate corrective action planning, this research uses optimization to help the contractor select the best acceleration strategy. The mechanism is basically a total cost minimization under time and resource constraints, considering any penalty, incentive, and indirect costs. To enable the optimization, optional execution methods (e.g., larger crew formations, better equipment, and/or overtime hours) need to be identified for the remaining activities in the schedule. In essence, two basic decisions are needed for each of the remaining activities: (1) the execution method (e.g., normal
versus a speedier and costly option) to meet deadline at minimum cost; and (2) any start time delay of each activity (as applied in Fig. 8 on day 5) to avoid resource over allocation. The combination of these activity decisions, as such, represents a corrective action plan. Because of the various possibilities to speed up one activity versus another and to delay one activity versus another, any real-life project requires some automation to try different combinations until a satisfactory (near optimum) solution is determined. In consistency with the daily progress representation in this paper, a computer prototype, EasyPlan [10] has been modified to consider rework. The prototype has various integrated functions to: manage a simple depository of resources, allow optional execution methods to be specified, apply optimization to try different combinations of decisions, record actual progress and work interruptions, and produce various reports. The three main changes made to EasyPlan to consider rework are: rework representation, modified resource allocation, modified delay analysis, and modified optimization process. The modified schedule optimization feature then optimizes corrective action by selecting the optimum combination of decisions (execution methods and start delays) for the remaining activities in the schedule. Applying the prototype to the case study, optional construction methods were specified as shown in Fig. 10 in terms of cost, duration,
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
Record all progress events Remove all progress events to get the as-planned schedule Stop yes Day > Progress date
Day = 1 (window 1) CPD = Current project duration No Add events of this day Calculate remaining schedule
Day = Day+1 CPD = NPD
Resolve over allocation - NPD = New project duration - Project delay d =NPD - CPD No (d = 0)
1057
Once the baseline was saved, actual progress data for the first 9 days were entered (top schedule in Fig. 12) with rework specified as a negative percentage complete. The figure shows two bars for each activity: baseline (top), and actual progress (bottom). Once actual progress was entered, project duration became 13 days (before resolving the resource over allocation), as discussed before. To meet an 11-day deadline and the resource limits, the modified optimization feature of the EasyPlan was activated. The optimization has two options: (1) simple heuristic approach based on well known resource levelling and time-cost trade-off heuristics [11], which is fast but may not reach the best solution; and (2) a genetic algorithm-based optimization which requires time to search for a near-optimum solution. In this simple case study, because of the activities’ limited options, the heuristic solution was sufficient to provide an 11-day solution, without resource over allocation (the bottom schedule in Fig. 12). The corrective action plan involves using speedy construction methods for activities B and F, which makes the project more costly but avoids more expensive penalty for any daily delay in project completion.
d>0 7. Concluding Remarks
yes Allocate responsibility for the d days
Fig. 9. Flowchart of the delay analysis process.
and resource amount for each activity. As opposed to existing scheduling tools where each activity typically has a single duration and cost, Fig. 10 shows the ability to specify estimates that vary from cheap and slow to fast and expensive activity. The options then become an important part of deciding the cheapest activities to speed (crash) in order to recover project delays and keep meeting the deadline. After specifying the activities options in Fig. 10, the activities’ logical relationships were specified as shown in Fig. 11 (by specifying the index to the predecessor activities, as shown). As shown in Fig. 11 also, each activity was set to use its cheapest construction methods (index 1 for all activities). Once this was done, a baseline schedule was then obtained (as shown in Fig. 11), with baseline duration of 10 days. Since the baseline schedule has not resource over-allocation (i.e., the daily resources of the schedule are within the resource limit), the start-delay values of the activities (see Fig. 11 are set to zeros).
This research contributes to the provision of quantitative scheduling tools that consider rework and support decisions for recovering delays. This study showed that the day-by-day segmentation of activity duration can be beneficial in representing all progress events including rework. Scheduling in this case becomes more responsive to the specific timings of various progress events (i.e., detailed progress evolution), not just presenting the cumulative percentage complete (progress end result). This paper thus served as a proof-of-concept and extensive experimentation on real-life projects is currently ongoing. More research is also needed to improve the schedule in terms of visualization, allow external resources to be used for doing the rework, manage the schedule of resources between new progress and rework, and incorporate a change-order management feature. Other future research to improve the present model as a project control tool is to incorporate cash flow analysis, earned value analysis, performance indices, and productivity analysis. In addition, a survey is currently being prepared to interview experienced scheduling professionals and contract experts to evaluate the impact of the proposed approach on current practice and the need to incorporate the analysis of rework in the scheduling specification of the project. One last note is that existing software tools have been improving much in terms of collaboration, graphics, etc., but not much in terms of the necessary project management features such as rework, delay analysis, time-cost trade-off, and optimization. Because of the importance of these aspects to the day-to-day project management
Menu options
Cost, Duration, & Resources Cost, Duration, & Resources of a Fast and Expensive of a Slow and Cheap estimate estimate Fig. 10. Specifying activities' optional methods.
1058
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059
Start delays for resolving resource over-allocation (all zeros since resources are not over-allocated)
Logical relations Cheaper estimates (index 1) are used. Activities durations Index of and costs of the predecessor cheapest estimates activities
Index of the cheapest estimates
Fig. 11. Logical relations and baseline schedule.
Progress events including rework
Optimization changed the methods to meet target deadline
Fig. 12. Actual progress before and after optimization.
process, having them as standard features in widely used commercial software is long overdue.
References [1] H. Abdul-Rahman, The cost of non-conformance during a highway project: a case study, Constr. Mgmt. Econ. 13 (1) (1995) 23–32.
[2] D. Arditi, T. Pattanakitchamroon, Selecting a delay analysis method in resolving construction claims, Int. J. Proj. Mgmt. 24 (2) (2006) 145–155. [3] J.L. Ashford, The Management of Quality in Construction, E & F Spon, London, U.K, 1992. [4] P. Barber, A. Graves, M. Hall, D. Sheath, C. Tomkins, Quality failure costs in civil engineering projects, Int. J. Qual. Reliab. Mgmt. 17 (4/5) (2000) 479–492. [5] J.L. Burati, J.J. Farrington, W.B. Ledbetter, Causes of quality deviations in design and construction, J. Constr. Engrg. and Mgmt. ASCE 118 (1) (1992) 34–49. [6] Construction Industry Institute (CII), Costs of quality deviations in design and construction, The Univ. of Texas at Austin, Austin, Texas, 1989, RS 10–1 (Jan.).
T. Hegazy et al. / Automation in Construction 20 (2011) 1051–1059 [7] K.G. Cooper, The rework cycle: benchmarks for the project manager, Proj. Mgmt. J. 24 (1) (1993) 17–21. [8] A.R. Fayek, M. Dissanayake, O. Campero, Measuring and Classifying Construction Field Rework: A Pilot Study, Research Rep. (May), Construction Owners Association of Alberta (COAA), The University of Alberta, Edmonton, Al., Canada, 2003. [9] M. Finke, Window analysis of compensable delays, J. Constr. Engrg. and Mgmt. ASCE 125 (2) (1999) 96–100. [10] T. Hegazy, “Simplified project management for construction practitioners”, Cost Eng. J. AACE Int. 48 (11) (2006) 20–28. [11] T. Hegazy, Computer-Based Construction Project Management, Prentice Hall, Upper Saddle River, NJ, USA, 2002. [12] T. Hegazy, W. Menesi, Delay analysis under multiple baseline updates, J. Constr. Engrg. and Mgmt. 134 (8) (2008) 575–582. [13] T. Hegazy, K. Zhang, Daily windows delay analysis, J. Constr. Engrg. and Mgmt. ASCE 131 (5) (2005) 505–512. [14] T. Hegazy, E. Elbeltagi, K. Zhang, Keeping better site records using intelligent bar charts, J. Constr. Engrg. and Mgmt. ASCE 131 (5) (2005) 513–521. [15] S. Holloway, Introductory concepts in delay claims, Constr. Law and Business. 2 (6) (2002) 3–6. [16] B.G. Hwang, S.R. Thomas, C.T. Haas, C.H. Caldas, Measuring the impacts of rework on construction cost performance, J. Constr. Engrg. and Mgmt. ASCE 135 (3) (2009) 187–198. [17] P.E. Josephson, Y. Hammarlund, The causes and costs of defects in construction: a study of seven building projects, Automation in Construction 8 (6) (1999) 681–687. [18] S. Kartam, Generic methodology for analyzing delay claims, J. Constr. Engrg. and Mgmt. ASCE 125 (6) (1999) 409–419.
1059
[19] P.E.D. Love, D.J. Edwards, H. Watson, P. Davis, “Rework in civil infrastructure projects: determination of cost predictors”, J. Constr. Engrg. and Mgmt. ASCE 136 (3) (2010) 275–282. [20] P.E.D. Love, D. Edwards, Forensic project management: the underlying causes of rework in construction projects, Civ. Eng. Environ. Syst. 12 (3) (2004) 207–228. [21] P.E.D. Love, J. Smith, Bench-marking, bench-action and bench-learning: rework mitigation in projects, J. Mgmt. Eng. ASCE 19 (4) (2003) 147–159. [22] P.E.D. Love, H. Li, Quantifying the causes and costs of rework in construction, Constr. Mgmt. Econ. 18 (4) (2000) 479–490. [23] P.E.D. Love, P. Mandal, H. Li, Determining the casual structure of rework influences in construction, Constr. Mgmt. Econ. 17 (4) (1999) 505–517. [24] J.M. Lyneis, D.N. Ford, System dynamics applied to project management: a survey, assessment, and directions for future research, Syst. Dyn. Rev. 23 (2–3) (2007) 157–189. [25] J.T. O'Conner, R.L. Tucker, Industrial project constructability improvement, J. Constr. Engrg. and Mgmt. ASCE 112 (1) (1986) 69–82. [26] J.Y. Ruwanpura, D. Meek, T. Nutting, D. Greaves, J. Hamlin, M. Timler, Most significant causes for rework due to engineering deliverables, in: M. Massièra, N. El-Jabi (Eds.), Proceedings of the 5th Construction Specialty Conference, CSCE, Moncton, N.B, 2003, June 2003. [27] G.R. Stumpf, Schedule delay analysis, Cost. Eng. Jr. AACE Int 42 (7) (2000) 32–43. [28] K. Davis, W.B. Ledbetter, J.L. Burati, Measuring design and construction quality costs, J. Constr. Engrg. and Mgmt. ASCE 115 (3) (1989) 385–400. [29] P.E.D. Love, Influence of Project Type and Procurement Method on Rework Costs in Building Construction Projects, J. Constr. Engrg. and Mgmt. ASCE 128 (1) (2002) 18–29.