Managing Tipping Point Dynamics in Complex
Construction Projects
Timothy R. B. Taylor, P.E., M.ASCE
1; and David N. Ford, P.E., M.ASCE
2Abstract:Complex construction projects are vulnerable to tipping points. Tipping points are conditions that, when crossed, cause system behaviors to radically change performance. Previous research identified tipping point dynamics as capable of explaining the failure of some nuclear power plant construction projects. These dynamics can also threaten the success of other large, complex construction projects. The current work uses a dynamic project model to test policies for managing tipping point dynamics. The Limerick Unit 2 nuclear power plant project is used to test model usefulness. Sensitivity analysis reveals the rework fraction, strength of subsystem interdependence, and sensitivity of the project to schedule pressure as potential high-leverage points for policy design. The model is used to test policies for managing tipping points that were used to complete the Limerick Unit 2 nuclear power plant after a tipping point threatened project completion. Implications for construction project design and management and research opportunities are discussed.
DOI:10.1061/共ASCE兲0733-9364共2008兲134:6共421兲
CE Database subject headings:Project management; Dynamic models; Simulation models; Change management; Errors; Nuclear powerplants.
Introduction
Although development projects are pursued to add value to their developers or users, many projects fail to do so as originally planned共Flyvbjerg et al. 2003; Matta and Ashkenas 2003; Evans 2005; Nassar et al. 2005兲. Examples of failed large, complex projects include the U.S. Navy’s development of the Littoral Combat Ship that is currently $100 million over the original bud-get estimates共Karp 2007兲, the Channel Tunnel connecting Great Britain and France that when completed was approximately $10 billion over its original budget and two years late共Kharbanda and Pinto 1996兲, the Boston Central Artery project that is approxi-mately $10 billion over its original budget and seven years late 共USS 2000; USHOR 2005兲, and the U.S. Department of Energy’s National Ignition Facility that exceeded the original budget by approximately $1 billion and was six years late共D. Ford and V. Parasnis, unpublished internal report, November 2001兲. The fail-ure of large complex projects can lead to severe economic conse-quences for project stakeholders.
Large, complex projects are very susceptible to failure. Project management research has identified many factors that can lead to project failure including overestimation of benefits共Evans 2005兲,
errors共Busby and Hughes 2004兲, lack of knowledge transfer be-tween projects 共Cooper et al. 2002兲, rework 共Cooper 1993; Gidado 1996; Love et al. 1999, 2000b, 2002兲, concealing rework 共Ford and Sterman 2003a兲, schedule pressure共Nepal et al. 2006兲, and project complexity 共Gidado 1996; Lyneis et al. 2001; Lee et al. 2006兲. In large, complex projects, the impact of these and other factors can be magnified due to feedback dynamics within the project. In addition, these projects are composed of multiple interrelated systems where changes in one system can also require unforeseen changes in connected systems. Causal feedback be-tween these systems cause projects to evolve over time in ways that greatly increase project complexity and make them difficult to manage共Lyneis et al. 2001兲.
Consider some American commercial nuclear power plant projects as a specific example of a type of large, complex con-struction project that failed. Many nuclear power projects failed to meet their original cost and schedule targets. The average con-struction duration for American commercial nuclear power plants tripled from 1959 to 1988共NRC 1982兲and unit costs grew at an exponential rate 共Fig. 1兲. Based on analysis of data from the Nuclear Regulatory Commission共NRC 1982兲and the Energy In-formation Administration共EIA 1988兲, the mean project duration during this time was 239% of the planned duration and the mean cost was 338% of the original estimate.
Although the construction of nuclear power plants in the United States ceased in the late 1980s, current public policy and industrial planning include nuclear power projects. The United States’ increasing energy demand has raised the need for addi-tional generating capacity and initiated a possible resurgence in the construction of nuclear power plants. In both his 2005 and 2006 State of the Union Addresses, President George W. Bush promoted nuclear power as part of the nation’s energy future. In a 2006 speech at the Limerick nuclear power plant, the President stated, “For the sake of economic security and national security, the United States of America must aggressively move forward with the construction of nuclear power plants.” 共Pulizzi 2006兲. The energy industry is also planning to build new nuclear power 1
Ph.D. Candidate, Construction Engineering and Management
Program, Zachry Dept. of Civil Engineering, Texas A&M Univ., College Station, TX 77843-3136. E-mail: [email protected]
2
Associate Professor, Construction Engineering and Management Program, Zachry Dept. of Civil Engineering, Texas A&M Univ., College Station, TX 77843-3136 共corresponding author兲. E-mail: davidford@ tamu.edu
Note. Discussion open until November 1, 2008. Separate discussions must be submitted for individual papers. To extend the closing date by one month, a written request must be filed with the ASCE Managing Editor. The manuscript for this paper was submitted for review and pos-sible publication on October 23, 2006; approved on October 18, 2007. This paper is part of theJournal of Construction Engineering and Man-agement, Vol. 134, No. 6, June 1, 2008. ©ASCE, ISSN 0733-9364/2008/ 6-421–431/$25.00.
plants. As of January of 2007, the NRC expects to receive con-struction permit applications for at least 30 new nuclear reactors 共Smith 2007兲. The possible resurgence of nuclear power plant construction in the United States could lead to more projects that fail to meet cost and schedule plans.
What caused the failures of previous projects and how can future nuclear power plant projects be better designed and man-aged? In complex projects, interdependent project components such as rework, schedule pressure, and project complexity inter-act over time in ways that can lead to project failure. In the case of the U.S. nuclear power industry, several researchers identified ever increasing共and ever changing兲governmental regulations im-posed on nuclear power plants as a root cause of cost and duration increases in nuclear plant construction 共Friedrich et al. 1987; Feldman et al. 1988; Lillington 2004兲. These changes can initiate unforeseen project system interactions. Understanding the struc-ture of these interactions and their impacts is critical to improving nuclear power plant projects and共more generally兲large, complex construction projects. Recent research 共Repenning 2001; Taylor and Ford 2006兲has identified structures of these interactions that create tipping points. This research demonstrates how tipping points can explain and quantify interdependent project compo-nents that influence project performance.
Tipping Points
A tipping point is a set of conditions that separate two very dif-ferent, internally driven, behavior modes. In The Tipping Point, Gladwell共2000兲defined one tipping point as “that one dramatic moment in an epidemic when everything can change all at once.” Sociologists have used tipping points to explain the increase of participants in a riot 共Granovetter 1978; Granovetter and Soong 1983兲, school desegregation 共Clotfelter 1976兲, societal segrega-tion共Schelling 1971兲, and social problems associated with ghettos 共Crane 1991兲. The term “tipping point” and the concept have grown into widespread use and have been used 共satirically兲 to explain the popularity of names for newborn children 共Fry and Lewis 2006兲. The causal structures of these and other systems, including construction project processes and management, can create tipping points. From a feedback perspective, systems tend to remain stable as long as the feedback loops that control progress dominate the system 共Sterman 2000兲. However, when dominance shifts away from project feedback loops that complete
work to feedback loops that add work, a tipping point is crossed and the addition of new work can overwhelm the project. When this occurs, projects can become共temporarily兲unstable and fail. In construction projects, crossing a tipping point can change im-proving net progress to declining or no net progress.
The effects of tipping points in multiple development project systems has been investigated. Repenning 共2001兲showed that a tipping point can help explain “fire fighting,” the phenomenon of projects being overwhelmed with work to the point of failure, and can threaten the success of a series of development projects. Black and Repenning共2001兲investigated the effectiveness of sev-eral managerial policies to counteract fire fighting, including add-ing resources to the project, releasadd-ing lower quality work, and resource allocation policies. However, these and other policies for managing tipping points have not been tested for use in single development projects, such as construction projects. Taylor and Ford共2006兲showed that tipping point dynamics can lead to run away project backlogs and explain some forms of single develop-ment project failure, but did not address operational solutions. The current work uses a project from the American nuclear power industry to demonstrate the impacts of tipping point dynamics on complex construction projects and investigates possible solutions. An example of a construction project that displayed tipping point behavior is Unit 2 of the Philadelphia Electric Company’s 共PECO兲Limerick nuclear power plant. Construction of the 1,065 megawatt unit began in June of 1974. The schedule when the construction permit was issued called for completion in September 1980. However, Unit 2 was only 36% complete at the original planned construction completion date. In September 1980, PECO increased the estimated completion date by two years because of an “increase of scope due to design changes and new regulatory requirements” 共NRC 1982兲. Increases in scope and design changes reflect ripple effects and rework, two factors that will be shown to be capable of generating tipping point dy-namics. Construction of Unit 2 was halted in July 1982 by order of the Pennsylvania Public Utility Commission due to escalating costs共NRC 1982兲.
Tipping points have been used to describe how projects can evolve to conditions in which processes are in control that lead to project failure. However, tipping points have not been used to investigate potentially effective designs for, and responses to, this threat to large, complex construction projects. Effective designs and policies are needed to mitigate tipping point threats and thereby improve future performance on complex projects. The current work extends the theory of tipping point dynamics in complex construction projects by mathematically describing a tip-ping point structure in a way that facilitates its use in understand-ing, designunderstand-ing, and managing projects. This description is used to investigate process designs and policies for managing tipping point conditions in complex construction projects. A project model of tipping point dynamics is described next, followed by model analysis to identify key inputs driving tipping point dy-namics. Policies used during the construction of the Limerick Unit 2 nuclear power plant are presented and investigated with the model. Descriptions of implications for practice and future research opportunities conclude the work.
A Simulation Model of Tipping Point Dynamics
Based upon the experience of the Limerick Unit 2 nuclear power plant and failures of large, complex projects, a system dynamics model capable of producing tipping point dynamics in project Fig. 1.Unit costs of American nuclear power plant construction关data
simulations was developed. System dynamics is a methodology for studying and managing complex systems共Sterman 2000兲. The approach focuses on how performance evolves in response to the interactions of management decision making and development processes through feedback. System dynamics has been success-fully applied to a variety of project management issues including the effect of rework on project performance共Cooper 1993; Ford 1995; Love et al. 1999, 2000b, 2002; Cooper et al. 2002; Lee et al. 2006兲, construction firm performance共Tang and Ogunlana 2003; Ogunlana et al. 2003兲, failures in fast track implementation 共Ford and Sterman 1998, 2003b兲, poor schedule performance 共Abdel-Hamid 1984兲, the management of project contingencies 共Ford 2002兲, the planning of fast-track construction projects 共Pena-Mora and Li 2001; Pena-Mora and Park 2001兲, construc-tion innovaconstruc-tion共Park et al. 2004兲, change management共Lee et al. 2005, 2006; Park and Pena-Mora 2003兲, and concealing rework requirements共Ford and Sterman 2003a兲.
A system dynamics simulation model is a series of difference equations based on feedback relationships that represent interac-tions between elements of a system共Sterman 2000兲. The system dynamics methodology assumes that system changes occur in small increments over continuous time. System conditions are calculated at each time step based on the conditions in the previ-ous time period and the difference equations. The tipping point model used here has time units of months with a time step of one-eighth of a month. Thus, project conditions for the Limerick Unit 2 simulation change twice weekly over the course of the 200 month simulation. The equations for the tipping point model are shown in Appendix I.
The model is purposefully simple relative to actual practice to expose the relationships between tipping point structures, project behavior modes, and management. Therefore, although many de-velopment processes and features of project participants interact to determine project performance, only those features that
de-scribe a particular tipping point structure, project management policies, and the fundamental processes they impact are included. For example, resource productivities are assumed fixed, work packages are assumed to be available for development, and work packages are completed in accordance with schedule require-ments共i.e., work packages on the critical path are given priority over work packages not on the critical path兲. The literature cited above investigates the impacts of these and other factors on per-formance. References in parentheses 关e.g.,共7兲兴 in the model de-scription refer to equations in Appendix I. The complete model with documentation is also available from the authors or at http:// ceprofs.tamu.edu/dford/.
The model consists of three sectors: A workflow sector 共Fig. 2兲, a resource allocation sector, and a schedule pressure sector. The workflow sector is based on the Ford and Sterman 共1998兲structure of a development project value chain with a re-work cycle. The same or similar structures have been used exten-sively to investigate project dynamics and management issues 共Cooper 1993, 1994; Ford and Sterman 2003a, b; Joglekar and Ford 2005; Lee et al. 2005; Lee et al. 2007兲. In Fig. 2, boxes represent backlogs of work that must be completed to finish the project. As each work package is completed, it moves from one backlog to another, represented by arrows with valve symbols. Work is initially completed 共9兲 and moves from the initial completion backlog共4兲to the backlog of work requiring quality assurance共5兲. Work that passes quality assurance共9兲is approved 共11兲and adds to the backlog of work that has been approved and released共7兲. Work discovered to require change共either through errors, omissions, or regulation changes兲 共10兲 moves into the backlog of work known to require rework共6兲. The IC backlog can also be increased by work created by ripple effects 共12兲. The ripple effect strength describes the interdependence of project work packages. Completing rework returns work packages to the QA backlog 共9兲 for checking again because rework can reveal Fig. 2.Work flows through a project with a tipping point structure
previously hidden, or create new, rework requirements. The initial completion, quality assurance, and rework flows are constrained by either development processes共13兲or available resources共14兲. In the resource allocation sector, resources are allocated to the three development activities 共22兲after an adjustment delay 共21兲 in amounts proportional to demand. Each proportion is the size of the activity’s backlog compared to the project backlog 共IC backlog + QA backlog + Rework backlog兲 共18兲–共20兲.
In addition to describing the accumulations and flows of work, Fig. 2 describes the feedback loops that drive work, rework, ripple effects, and schedule pressure. The direction of arrows in-dicates the direction of influence. Plus signs at arrowheads indi-cate that an increase in the component at the arrow’s tail results in an increase of the component at the arrow’s head and vice versa 共i.e., decreases result in decreases兲. For example, as the ripple effect strength increases, the ripple effect rate increases. Negative signs at arrowheads indicate that an increase of the component at the arrow’s tail results in a decrease of the component at the arrow’s head and vice versa 共i.e., decreases result in increases兲. For example, as the project deadline increases共making more time available to complete the project兲, schedule pressure decreases. Closed feedback loops are either reinforcing 共“R”兲 and tend to generate accelerating divergent behavior or balancing 共“B”兲and generate goal-seeking behavior. See Sterman 共2000兲 for a more detailed description and analysis of reinforcing and balancing loops.
Feedback loops can explain tipping point dynamics. Balancing feedback loop B1 共Project Progress兲 withdraws work from the rework cycle. The QA backlog increases due to initial completion and rework, causing the QA rate to increase as resources are shifted to quality assurance. This increases the work approval rate, reducing the QA backlog, and increasing the amount of work released. This balancing loop drives the project to completion as the backlogs that represent the remaining project work decline to zero. In the absence of ripple effects共e.g., if no rework is discov-ered兲, B1 completes a project as quickly as processes and re-sources allow. Reinforcing loop R1共Ripple Effect兲adds work to the project through the discovery of rework and ripple effects. Increasing the QA backlog increases the QA rate, increasing the rate at which work is discovered to require rework. This increases ripple effects, adding work to the IC backlog. As the IC backlog increases, resources are shifted to initial completion, the initial completion work rate increases, and the QA backlog increases further. In the absence of loop B1 共e.g., if all work required re-work兲, loop R1 increases the rework and project backlog infi-nitely, thereby degrading project performance to eventual failure. Feedback loops B1 and R1 create a tipping point structure based on the approval of work and the addition of work to the project backlog. As long as loop B1 dominates, the project progresses 共albeit perhaps very slowly兲, the project backlog de-creases, and the percent complete increases. However, if loop R1 dominates, the project backlog increases and the percent complete decreases. At the tipping point, the rate of work being added to and the rate of work being removed from the project backlog are equal. When work is being completed faster than new work is being added 共ripple effect rate⬍approve work rate兲, the percent complete increases. When work is being added faster than it is being completed共ripple effect rate⬎approve work rate兲, the per-cent complete decreases.
A third feedback loop is needed to endogenously shift feed-back loop dominance between loops B1 and R1. Schedule pres-sure can create this third feedback loop. Schedule prespres-sure is common in development projects and can lower development
quality 共Park et al. 2004; Nepal et al. 2006兲, increase rework 共Cooper 1994; Graham 2000; Ford and Sterman 2003b; Nepal et al. 2006兲, and thereby have important impacts on performance. Schedule pressure can also have beneficial impacts that can be modeled with additional feedback loops关see Ford共1995兲for ex-amples兴, but the current work models only the net effects of schedule pressure, which are assumed to be negative. This as-sumption is supported by the findings of Nepal et al. 共2006兲. Schedule pressure 共30兲 increases with the time required to complete the project backlog 共28兲 and decreases with the time available to complete the project backlog共26兲. As a project ap-proaches a deadline, schedule pressure increases共ceteris paribus兲 and developers work faster to meet the deadline. This increases the risk of work being completed incorrectly 共i.e., increases the fraction of work requiring rework兲. Therefore, reinforcing Loop R2 共Schedule Pressure兲 can increase the strength of the ripple effect loop共R1兲by increasing the rework fraction 共31兲. The re-sulting increase in ripple effects, the IC backlog, and thereby the project’s backlog, increases the time required to complete the project, increasing schedule pressure further. Through loop R2, schedule pressure can push a project initially dominated by the Project Progress loop共B1兲across its tipping point into dominance by the Ripple Effect loop共R1兲and toward failure.
Typical Model Behavior and Testing
To illustrate typical model behavior, the simulated percents com-plete for two projects are shown in Fig. 3. The project structures are identical except that in Project A, schedule pressure has no impact on rework 共i.e., loop R2 is not active兲, while Project B experiences an increase in rework due to schedule pressure through feedback loop R2. Both projects begin with slow progress. Progress accelerates as work flows from the IC backlog to the QA and Rework backlogs and ultimately into the stock of work released. When the QA and Rework backlogs stabilize, the slope of Project A’s percent complete becomes almost constant 共months 3–15兲, indicating steady progress. Near month 15, the slope of Project A begins to decrease significantly as the stocks of initial completion, quality assurance, and rework are emptied, until the project is completed. Though the rate of increase of project percent complete changes during the project共slow initial growth, relatively steady growth during the middle of the project, and slow growth at the end of the project兲, the percent complete
increases monotonically. This indicates that Project A is domi-nated by loop B1 throughout its duration.
Project B initially displays similar, albeit slower, initial progress. As in Project A, its behavior is also dominated by loop B1 during this time. However, as Project B progresses, the sched-ule pressure loop 共R2兲strengthens the ripple effect 共Loop R1兲, weakening project progress共Loop B1兲, and increasing schedule pressure. Between months 14 and 15, the schedule pressure on Project B is twice that experienced by Project A, Project B crosses the tipping point, and Loop R1 dominates the project. Loop R1 dominates throughout the remainder of the project, caus-ing the percent complete to decrease共months 15–40兲. During this time, schedule pressure increases until the rework fraction in Project B is four times greater than the rework fraction experi-enced by Project A at the same time. Rather than continue to decline for an indefinite period, Project B might be terminated or changes made to shift dominance back to loop B1.
The model was tested using standard test methods for system dynamics models 共Sterman 2000兲. Basing the model on previ-ously tested project models and the literature improves the mod-el’s structural similarity to development processes and practices, as do unit consistency tests. Extreme condition tests were per-formed by setting model inputs, such as initial scope or total project staff, to extreme values and simulating project behavior. Model behavior remained reasonable. The model’s behavior for typical conditions is consistent with previous project models and practice共e.g., the common “S” shaped increase in percent com-plete over time shown for Project A, Fig. 3兲. Model behavior was also compared to actual project behavior as described by Ford and Sterman共1998, 2003b兲, Lyneis et al.共2001兲, and others and found to closely match the behavior modes of actual projects.
To test the ability of the model to replicate tipping point be-havior modes, the model was calibrated to the Limerick Unit 2 nuclear power plant project and the simulated behavior compared to the actual behavior of the Limerick Unit 2 project共Fig. 4兲. The similarity between the actual project and simulated behavior modes in Fig. 4 supports the model’s ability to reflect the behav-ior of Limerick Unit 2, including tipping point dynamics. Later, the same model is calibrated to the entire Limerick Unit 2 project 共through completion兲, further supporting the use of the model. Based on these tests, the model was assessed to be useful for investigating tipping point dynamics in complex construction projects.
Model Analysis
The model equations in the work flow sector can mathematically describe the tipping point conditions and conditions for project improvement or degradation. The tipping point conditions occur when the withdrawal of work from the project backlog is equal to the addition of work to the project backlog and the net change in the project backlog is zero. The withdrawal is the rate at which work is approved and released, which is the compliment of the QA rate that is discovered to require rework共11兲. The addition of work is the ripple effect共12兲, which is the product of the discover rework rate and the ripple effect strength. The rate at which re-work is discovered 共10兲, is the product of the QA rate and the rework fraction. Therefore, at the tipping point:
aq−共aq兲共fr兲=共r兲共aq兲共fr兲 共1兲 whereaq⫽quality assurance rate兵work packages/week其;r⫽ripple effect strength 兵dimensionless其; and fr⫽fraction discovered to require rework兵%其. Simplification yields a description of the tip-ping point
fr共r+ 1兲= 1 共2兲 When the left hand side of Eq.共2兲exceeds 1, the project is de-grading; when less than 1, the project is improving; and when equal to 1, the project is stagnant. The tipping point conditions are shown graphically in Fig. 5.
Fig. 5 reveals intuitive insights about project conditions that generate tipping point dynamics. The negative slope of the tip-ping point line indicates that projects that have relatively indepen-dent project parts共low ripple effect strength兲can tolerate a higher rework fraction before degrading than highly interdependent projects共ceteris paribus兲and that simple projects, as reflected by low rework fractions, can tolerate higher ripple effect strengths than complex projects. However, the tipping point relationship between ripple effect strength and rework fraction is not linear. The convex shape of the tipping point line indicates that increases in ripple effect strength greatly reduce the tolerable rework frac-tion when ripple effects are small, but as ripple effect strength increases, the tolerable rework fraction decreases more slowly.
Sensitivity analysis was performed to improve understanding of the drivers of tipping point dynamics. The analysis was per-formed on model variables that managers can influence through project designs and management policies. A project’s buffer against tipping point failure共btp兲was used to quantify the impact of changes in model inputs. This tipping point buffer is the Fig. 4.Tipping point behavior mode test共data from reports to NRC
1974-1982兲
distance a project’s conditions are from the tipping point, as fol-lows. By inspection of Eq.共2兲, if a project starts far enough away from its tipping point 关fr共r+ 1兲1兴and increases in the rework fraction and ripple effect strength are small, the project will not cross the tipping point and will monotonically improve. In Fig. 5, this initial project condition is well below and left of the tipping point line. However, if the project starts near the tipping point or the magnitudes of the changes are large enough, the project can be pushed over the tipping point. Eq. 共2兲 can be rearranged to define the tipping point buffer
fr+共fr·r兲+btp= 1 共3兲 where btp⫽buffer to tipping point-induced failure 兵dimension-less其. The right side of Eq. 共3兲represents 100% of the project’s capacity to tolerate ripple effects and rework. This capacity has been disaggregated into the three parts on the left side of Eq.共3兲: 共1兲Capacity fraction absorbed by rework共fr兲,共2兲capacity frac-tion absorbed by ripple effects 共fr·r兲, and 共3兲 the unutilized capacity fraction that provides the tipping point buffer 共btp兲. When the tipping point buffer is positive, the project is below the tipping point 共improving兲; when it is zero, the project is at the tipping point; and when it is negative, the project is above the tipping point 共degrading兲. For example, suppose a project has a fixed 20% rework fraction 共fr= 0.2兲 and a fixed ripple effect strength共r兲of 1 work package added per work package discov-ered to require rework. Applying Eq.共3兲, this project begins 0.6 from the tipping point 共initial buffer= 60%兲. This project could tolerate schedule pressure-driven increases in the rework fraction of up to 30% 共making fr= 50%兲 without crossing the tipping point.
Eq.共3兲provides a means of analyzing the sensitivity of tipping point structures to different variables. However, tipping point buffers can vary significantly from their initial values during a project. For example, schedule pressure can increase the fraction of work requiring change共fr兲and thereby reduce the buffer. The minimum distance that project conditions come to the tipping point during the project represents a project’s most vulnerable conditions. Therefore, a project’s minimum tipping point buffer is a better measure of project sensitivity than the initial buffer. Fig. 6 shows the results of sensitivity analysis of a project’s mini-mum tipping point buffer to four variables that impact tipping point dynamics in the model.
The horizontal axis of Fig. 6 represents the percent change from base case values of the reference rework fraction, ripple effect strength, rework sensitivity to schedule pressure, and
project deadline. The vertical axis represents the minimum project tipping point buffer. As an example of the need to use the project’s minimum tipping point buffer, for the base case the buffer at the beginning of the project共60%兲is reduced by sched-ule pressure during the project to a minimum of 51%关center point 共0%, 51%兲of Fig. 6兴. Values that “fall off” the bottom of the chart reflect negative buffers, when the project has crossed the tipping point and failed.
Inspection of the slopes of the lines in Fig. 6 reveal the project’s relative robustness to tipping point failure for each model input. Taguchi et al.共2000兲defines robustness as “the state where the product/process is minimally sensitive to factors caus-ing variability.” A steeper slope in Fig. 6 indicates the project is more sensitive共less robust兲to changes in the model input value 共the factor causing variability兲. In general, the project’s robust-ness to tipping point-induced failure is lowest for the reference rework fraction共reflecting project complexity兲, then ripple effect strength 共reflecting project interdependence兲, then rework sensi-tivity to schedule pressure, and is most robust to the project dead-line. The results of this analysis are next used to explain and design projects to avoid tipping point failure.
Project Management near Tipping Points
Model analysis revealed high leverage model inputs for managing the minimum project tipping point buffer. Project design and management policies that impact these high leverage model in-puts can reduce the potential of project failure due to tipping point dynamics. The literature suggests many construction management policies to improve the likelihood of project success that can be modeled using the four model parameters tested. For example, the rework fraction can be reduced through improved project learning 共Carrillo 2005; Cooper et al. 2002; Love et al. 2000a兲, the ripple effect strength can be reduced through project planning efforts focused on decoupling ripple effects 共Nepal et al. 2006; Love et al. 2002兲, and schedule pressure can be reduced by setting realistic project deadlines共Nepal et al. 2006兲. As described next, these policies, and others, used by Bechtel Western Power Corp. to complete construction of Limerick Unit 2 provide examples of policies that can be used to manage tipping point dynamics in large, complex construction projects.
Completing the Limerick Unit 2 Nuclear Power Plant
To test the effectiveness of policies for managing tipping point dynamics in large, complex construction projects, some of the policies used to complete Limerick Unit 2 were modeled to simu-late the completion of construction of Limerick Unit 2. Bechtel Western Power Corp resumed work on Limerick Unit 2 in Feb-ruary 1986 共Clarey 1987; Gotzis 1991兲and the unit was finally completed in August of 1989. When construction resumed, the contractor began implementing steps to minimize rework on the project 共Clarey 1987; Gotzis 1991兲. Nearly 300 engineers and managers were retained from the construction of Limerick Unit 1, completed in late 1985. This allowed the construction of Unit 2 to proceed with “lessons learned” from the construction of Unit 1, which, according to Carrillo 共2005兲, Cooper et al. 共2002兲, and Love et al. 共2000a兲, should have reduced the amount of project rework. Before the manual workforce was increased, the contrac-tor also added approximately 600 project managers and engineers to the project to further reduce rework by increasing the level of Fig. 6.Sensitivity analysis results
planning detail prior to construction. According to Nepal et al. 共2006兲 and Love et al. 共2002兲, this planning would also reduce ripple effect strength through the identification and decoupling of work dependencies. An example of this planning was the field review of complex installations by design engineers to identify potential problems prior to initiating work orders. This review identified potential problems before construction commenced and reduced the number of errors made during installation. In addi-tion, design engineers were placed on the second shift to resolve issues that arose during second shift construction. The availability of these engineers not only reduced the rework fraction, it re-duced ripple effect strength by making available their ability to decouple required changes and other construction work through their knowledge of the system design. A portion of the profes-sional manpower buildup included increasing the number of qual-ity control personnel available to check work. These additional personnel allowed more work to be checked in a given amount of time, which identified many errors more quickly and prevented their propagation.
To manage schedule pressure on Limerick Unit 2, an aggres-sive, but realistic, schedule based upon the work remaining to be completed was set共Clarey 1987兲. This is indicative of setting a realistic deadline as described by Nepal et al. 共2006兲. This re-duced the potential impact of schedule pressure on the project 共Graham 2000兲. To prevent the buildup of the work backlog from increasing schedule pressure, the experienced manual labor force was rapidly placed on site共Gotzis 1991兲. This fast buildup of an experienced labor force also allowed the project to make quick progress in reducing project backlog. This allowed the project to remain on schedule and reduced the pressure from managers to increase the work pace. Schedule pressure was further reduced through significant reductions in the number of work packages required to complete the project. Work packages such as pipes and pipe hangers, cable trays, wiring, and conduits were elimi-nated through system redesign, thereby reducing the project back-log. These and other project management policies implemented by Philadelphia Electric and Bechtel Western Power Corp to com-plete Limerick Unit 2 allowed the second phase of construction to be completed in accordance with the revised共after the first phase兲 budget and schedule requirements and helped the project earn recognition as the Project Management Institute’s 1990 “Project of the Year”共Gotzis 1991兲.
Many of the policies used to complete the Limerick Unit 2 project affect project features that the model analysis indicates affect tipping point dynamics. The policies used to complete Limerick Unit 2 were implemented in the model. When available, actual project data were used共e.g., project staffing levels, project deadline evolution, and work package reductions兲. In the absence of data, the authors assumed reasonable values and tested the robustness of results to the assumptions. Appendix II specifies the model calibration used to simulate Limerick Unit 2 construction completion and value ranges over which the behavior mode is robust. The entire Limerick Unit 2 project was modeled and simu-lated共July, 1974 through August, 1989, 181 months兲based upon this project description. Fig. 7 compares the simulated and actual project percent complete.
The similarity between the simulated and actual project behav-iors supports the ability of the suggested policies to manage tip-ping point dynamics in nuclear power plant construction. In addition, Fig. 7 helps explain the impact of tipping point dynam-ics on the construction of Limerick Unit 2. The project begins with a gradual buildup of completed work共months 0–5兲, followed by steady progress 共months 5–20兲, when its behavior is
domi-nated by Project Progress共Loop B1兲. During this time, the total project work backlog is being reduced at a faster rate than new work is being added to the project. Near month 26, the project crosses the tipping point and Ripple Effects共Loop R1兲dominate the system. The sudden change in project conditions suggests an abrupt shift in loop dominance, such as might be initiated by a new set of regulations. Progress declines as work is added to the project through ripple effects at a faster rate than work is ap-proved and released 共months 26–32兲. In the 32nd month, the project crosses the tipping point again, loop B1 dominates the system, and the project makes positive net progress共months 32– 50兲. Above month 50, Schedule Pressure 共Loop R2兲 begins to build on the project, as reflected in the gradual slowing of project progress between months 50 and 66 that is similar to the behavior pattern shown in Project B in Fig. 3. During this time, the sched-ule pressure loop共R2兲strengthens the ripple effect loop共R1兲as schedule pressure increases project rework, which increases the ripple effect rate. Simultaneously the increase in the project re-work rate decreases the rate of re-work being approved and released, thus weakening loop B1. In the 66th month, the project crosses the tipping point a third time, loop R1 dominates the system, and the project degrades. The project is halted in month 96 and project progress is stagnant until the project is restarted in month 139. Once the project is restarted, the policies implemented allow loop B1 to dominate the system and the project is completed in month 181. The model and the Limerick Unit 2 project data support tipping point dynamics as an explanation of this complex con-struction project performance.
Conclusions and Implications for Practice
The current work builds on existing tipping point dynamics re-search by testing and analyzing a project model with a tipping point structure to identify factors with high leverage impacts on project performance. Analysis reveals that, among the parameters tested, projects are least robust to rework, followed by ripple effects, sensitivity to schedule pressure, and are most robust to the project deadline. Existing project management research offers managers policies that can influence these variables. A nuclear power plant project was used to illustrate the successful applica-tion of policies for managing tipping point dynamics. The generic nature of tipping points and common characteristics of large con-Fig. 7.Comparison of Limerick Unit 2 simulation to available data
struction projects suggest that policies for managing tipping point dynamics in the construction of Limerick Unit 2 may be appli-cable to other types of projects. Therefore, results from the cur-rent work can potentially be applied to other types of development projects.
Project managers can benefit from developing an understand-ing of how tippunderstand-ing point dynamics can affect project performance. For example, knowing the relative sensitivity of project specific features due to tipping point structures can help managers design policies. This improvement is possible even though no known tools are currently available for managers to directly measure the rework fraction or the ripple effect strength. Project teams can ask questions such as, “What systems in this project are likely to require the most iteration 共rework兲?” “How can this iteration be eliminated or minimized?” “Could this iteration lead to work that has not been anticipated共ripple effects兲?” and “How can we de-couple these parts of the project共reduce ripple effects兲?” Project managers can use policies such as those modeled here to manage tipping point dynamics in planned U.S. commercial nuclear power plant construction projects and other large, complex projects.
Future research can improve the applicability of tipping points to project management in a number of ways. To successfully manage tipping point dynamics, project managers must identify tipping point structures and factors that can move projects to a tipping point prior to project initiation, or relatively early in the project. In the Limerick Unit 2 case, the tipping point structures were identified well after the project was completed. This a pos-teriori identification would not have aided Limerick Unit 2 project managers in the management of the project. The current work reveals that projects that are complex共potential for high levels of rework兲 and have highly interdependent components 共potential for high ripple effect strength兲can experience tipping point dy-namics. Existing work has identified other feedback structures that can drive projects to failure共e.g., Cooper 1980; Cooper et al. 2002; Ford and Sterman 2003a; Tang and Ogunlana 2003兲. These, and other structures, should be integrated into tipping point theory. Additional research is also needed to identify other project structures 共process designs and policies兲 that can cause tipping point dynamics and how project managers can identify them. The model structure used in this work has limitations that can be addressed in future research to improve the understanding of tipping point dynamics. Expanded models can improve model structure consistency with actual projects, calibrate the model to additional projects, and continue the development of robustness as a practical measure of a project’s protection against failure. In addition, the ability of policies to manage tipping point structures not tested in the current work 共e.g., with real options兲, could be modeled and tested.
Finally, the current work and its implications have larger soci-etal impacts. The failure of large projects, as exemplified by many projects in the American commercial nuclear power construction industry of the 1970s and 1980s, can have dramatic impacts be-yond the project’s direct stakeholders. For example, the Shoreham nuclear power plant in Long Island, NY, was completed but never operated. Its closure not only impacted the Long Island Lighting Company and its rate base, but also the taxpayers of New York, and to a lesser extent the United States, who ultimately paid for the lengthy legal process that accompanied the construction and decommissioning of the plant 共Aron 1997兲. Unfortunately, this important problem is not new or unique to nuclear power plant construction. InThe Wealth of Nations, Adam Smith共1776/2004兲 describes society’s losses due to project failure, noting that
“Every injudicious and unsuccessful project in agriculture, mines, fisheries, trade, or manufactures tends…to diminish the funds destined for the maintenance of productive labor. In every such project . . . there must always be some diminution in what would otherwise have been the productive funds of the society.” Failing to learn from past failures could lead the American nuclear power industry to repeat the troubles encountered during the construc-tion of Limerick Unit 2 in planned future nuclear power projects. More generally, understanding and addressing tipping point dy-namics can improve the management of large, complex construc-tion projects and, thereby, society.
Acknowledgments
The writers thank Marsha Ward, NRC Research Librarian, for assisting in the acquisition of NRC nuclear power plant construc-tion data, and the reviewers of this work.
Appendix I. Model Equations
j苸兵initial completion 共i兲, quality assurance 共q兲, rework 共r兲其 unless indicated otherwise.
Workflow Sector 共d/dt兲Ai= −ai−as+ae 共4兲 共d/dt兲Aq= +ai−ad+ar−aw 共5兲 共d/dt兲Ar= +aq−ar 共6兲 共d/dt兲Aw= +aw 共7兲 as= IF共t= 139兲THEN共Ai·c兲ELSE共0兲 共8兲 aj=共MIN共pj,rj兲 共9兲 ad=fr·aq 共10兲 aw=共1 −fr兲aq 共11兲 ae=ad·r 共12兲 pj=Aj/mj 共13兲 rj=sj·dj 共14兲 T=Ai+Aq+Ar 共15兲 Tw=T+Aw 共16兲 C=Aw/Tw 共17兲 where Aj⫽work backlog 共work packages兲; Aw⫽approved work 共work packages兲; aj⫽work flow 共work packages/month兲; ad⫽discover rework rate 共work packages/month兲; aw⫽approve work rate 共work packages/month兲; ae⫽ripple effects due to re-work共work packages/month兲;as⫽scope eliminated through rede-sign 共work packages/month兲; c⫽scope cancellation rate 共%兲; t⫽time共month兲;r⫽ripple effect strength共work packages added/ work packages requiring rework兲; rj⫽resource dependent work
flow rate 共work packages/month兲; pj⫽process dependent work flow rate 共work packages/month兲; fr⫽fraction discovered to re-quire rework 共%兲; mj⫽minimum work process time 共month兲; sj⫽staff assigned to work backlog 共people兲; dj⫽productivity of staff assigned to work backlog 共work packages/person-month兲; T⫽total project backlog 共work packages兲; Tw⫽total project work 共work packages兲; and C⫽percent of work that has been completed共%兲.
Resource Allocation Sector
Lj=Aj/dj 共18兲 Lt=Li+Lq+Lr 共19兲 Xj=Lj/Lt 共20兲
共d/dt兲Fj=共Xj−Fj兲/u 共21兲 sj=Fj·S 共22兲 where Lj⫽labor required to complete work backlog 共people·month兲; Lt⫽total labor required to complete project 共people·month兲; Xj⫽indicated fraction of resource demand to each backlog共%兲;Fj⫽applied fraction of resource demand 共frac-tion兲; u⫽time required to adjust staff 共month兲; and S⫽total project staff共people兲.
Schedule Pressure Sector
Za=Aw/t 共23兲 Zp=I/D 共24兲 Zt=D·Df 共25兲 Da= MAX共1,D−t兲 共26兲 Zf=兵关MAX共0,Zt−t兲/Zt兴·Zp其+关MIN共1,t/Zt兲兴·Za 共27兲 Dr=T/Zf 共28兲 Df= 0.5 共29兲 R= MAX关1,MIN共Rm,Dr/Da兲兴 共30兲 fr= MIN关1,fm+Rs·共R− 1兲兴 共31兲 where Za⫽actual release productivity 共work packages /month兲; Zp⫽planned release productivity 共work packages /month兲; Zt⫽time to transition from planned to actual release productivity 共month兲;Zf⫽release productivity for forecasting共work packages /month兲; I⫽initial project scope 共work packages兲; D⫽project deadline 共month兲; Df⫽planned project duration to transition to actual release productivity 共%兲; Da⫽time available to complete work 共month兲; Dr⫽time required to complete work 共month兲; R⫽schedule pressure ratio 共fraction兲; Rm⫽maximum effective schedule pressure共dimensionless兲;fm⫽minimum fraction discov-ered to require rework共%兲; andRs⫽sensitivity of rework fraction to schedule pressure共dimensionless兲.
Appendix II. Model Calibration for Limerick Unit 2 Construction Completion
Table 1 specifies model calibration values used to simulate the Limerick Unit 2 construction completion.
Table 1.Limerick Unit 2 Construction Completion Model Policy Implementation Policy共Clarey 1987; Gotzis 1991兲
Model variable affected
共base case value兲 Change in model variable to reflect policy changes
Increase CEM personnel
Review of complex field installations Lessons learned from completing Unit 1 Increase quality control personnel Design engineers placed on second shift
Rework fraction共30%兲 Assume each policy reduces the base rework fraction 3%
without overlapping reactions. This results in a cumulative rework fraction reduction of共5 policies兲·共3%/policy兲⫽15%. Rework fraction becomes 30% −15% = 15%.
Design engineers on second shift to correct design errors. Increase CEM personnel.
Ripple effect strength 共1WPA/WPRR兲a
Assume each policy reduces the ripple effect strength by 0.35 WPA/WPRR. Results in a cumulative ripple effect strength reduction of共2 policies兲·共0.35 WPA/WPRR/Policy兲 =0.7 WPA/WPRR. Ripple effect strength becomes 1 − 0.7= 0.3 WPA/WPRR.
Rapidly hire and deploy qualified workforce Sensitivity to schedule pressure 共0.4, dimensionless兲
Assume sensitivity to schedule pressure is reduced by 0.38. Sensitivity to schedule pressure becomes 0.4− 0.38= 0.02.
Cancel scope through redesign Initial completion backlog
共17,525 tasks兲
Reduce IC backlog at restart by 8% based on work quantity reductions presented in Clarey共1987兲, Tables 1 and 2.
Set realistic deadline Project deadline
共varies, month兲
Project deadline evolution based on data from NRC共1982兲 and Clarey共1987兲
Increased staffing levels Total project staff
共2,100 people兲
Increase staff关see Clarey共1987兲, Fig. 3 for details兴 Note: The project completion date shown in Fig. 7 is robust to within⫾10% of the actual completion date共month 181兲for minimum rework fraction values of共26%–0%兲, ripple effect strength values of共0.9 WPA/WPRR–0.0 WPA/WPRR兲, and sensitivity to schedule pressure values of共0.06–0兲. a
References
Abdel-Hamid, T. K. 共1984兲. “The dynamics of software development project management: An integrative systems dynamics perspective.” Ph.D. thesis, Massachusetts Institute of Technology, Cambridge, Mass.
Aron, J.共1997兲.Licensed to kill? The nuclear regulatory commission and the Shoreham Power Plant, Univ. of Pittsburgh Press, Pittsburgh, Pa. Black, L., and Repenning, N.共2001兲. “Why firefighting is never enough: Preserving high-quality product development.”Syst. Dyn. Rev., 17共1兲, 33–62.
Busby, S., and Hughes, E.共2004兲. “Projects, pathogens, and incubation periods.”Int. J. Proj. Manage., 22共2兲, 425–434.
Carrillo, P. 共2005兲. “Lesson learned practices in the engineer, procure-ment, and construction sector.”Eng., Constr., Archit. Manage., 12共3兲, 236–250.
Clarey, J.共1987兲. “New concept cuts nuclear project construction cost.” Power Eng. J., 91共11兲, 28–31.
Clotfelter, C.共1976兲. “School desegregation, ‘tipping,’ and private school enrollment.”J. Hum. Resour, 11共1兲, 28–50.
Cooper, K.共1980兲. “Naval ship production: A claim settled and a frame-work built.”Interfaces, 10共6兲, 20–36.
Cooper, K.共1993兲. “The rework cycle: Why projects are mismanaged.” PM Network, 7共2兲, 5–7.
Cooper, K.共1994兲. “The $2,000 hour: How managers influence project performance through the rework cycle.”Proj. Manage. J., 15共1兲, 11– 24.
Cooper, K., Lyneis, J., and Bryant, B.共2002兲. “Learning to learn, from past to future.”Int. J. Proj. Manage., 20共3兲, 213–219.
Crane, J.共1991兲. “The epidemic theory of ghettos and neighborhood ef-fects on dropping out and teenage childbearing.” Am. J. Sociol.,
96共5兲, 1226–1259.
Energy Information Administration共EIA兲.共1988兲. “Nuclear power plant construction activity 1988.”DOE/EIA-0473(88), Washington, D.C. Evans, M. 共2005兲. “Overdue and over budget, over and over again;
project management.”The Economist, 375共8430兲, 66.
Feldman, S., Bernstein, M., and Noland, R.共1988兲. “The costs of com-pleting unfinished US nuclear power plants.”Energy Policy, 16共3兲, 270–279.
Flyvbjerg, B., Skamris Holm, M., and Buhl, S.共2003兲. “How common and how large are cost overruns in transport infrastructure project?” Transport Rev., 23共1兲, 71–88.
Ford, D.共1995兲. “The dynamics of project management: An investigation of the impacts of project process and coordination on performance.” Ph.D. thesis, Massachusetts Institute of Technology, Cambridge, Mass.
Ford, D.共2002兲. “Achieving multiple project objectives through contin-gency management.”J. Constr. Eng. Manage., 128共1兲, 30–39. Ford, D., and Sterman, J.共1998兲. “Modeling dynamic development
pro-cesses.”Syst. Dyn. Rev., 14共1兲, 31–68.
Ford, D., and Sterman, J.共2003a兲. “The liar’s club: Impacts of conceal-ment in concurrent developconceal-ment projects.”Concurr. Eng. Res. Appl.,
111共3兲, 211–219.
Ford, D., and Sterman, J. 共2003b兲. “Overcoming the 90% syndrome: Iteration management in concurrent development projects.”Concurr. Eng. Res. Appl., 111共3兲, 177–186.
Friedrich, D., Daly, J., and Dick, W. 共1987兲. “Revisions, repairs, and rework on large projects.”J. Constr. Eng. Manage., 113共3兲, 488–500. Fry, M., and Lewis, T.共2006兲. “Over the hedge.”Bryan-College Station
Eagle, July 16, E3.
Gidado, K.共1996兲. “Project complexity: The focal point of construction production planning.”Constr. Manage. Econom., 14共3兲, 213–225. Gladwell, M. 共2000兲. The tipping point: How little things make a big
difference, Little, Brown, and Company, Boston.
Gotzis, T. 共1991兲. “Project management in action: Showcase project: Limerick generating station unit 2.”PM Network, 5共1兲, 9–22. Graham, A.共2000兲. “Beyond PM 101: Lessons for managing large
de-velopment programs.”Proj. Manage. J., 31共4兲, 7–18.
Granovetter, M.共1978兲. “Threshold models of collective behavior.”Am. J. Sociol., 83共6兲, 1420–1443.
Granovetter, M., and Soong, R.共1983兲. “Threshold models of diffusion and collective behavior.”J. Math. Sociol., 9, 165–179.
Joglekar, N., and Ford, D.共2005兲. “Product development resource allo-cation with foresight.”Eur. J. Oper. Res., 160共1兲, 72–87.
Karp, J.共2007兲. “Navy cancels Lockheed ship pact.”Wall Street Journal Online,具www.wsj.com典 共May 22, 2007兲.
Kharbanda, O., and Pinto, J.共1996兲.What made Gertie gallop: Learning from project failures, Van Nostrand Reinhold, New York.
Lee, S., Pena-Mora, F., and Park, M.共2005兲. “Quality and change man-agement model for large scale concurrent design and construction projects.”J. Constr. Eng. Manage., 131共8兲, 890–902.
Lee, S., Pena-Mora, F., and Park, M.共2006兲. “Reliability and stability buffering approach: Focusing on the issues of errors and changes in concurrent design and construction projects.” J. Constr. Eng. Man-age., 131共5兲, 452–464.
Lee, Z., Ford, D., and Joglekar, N.共2007兲. “Resource allocation policy design for reduced project duration: A systems modeling approach.” Syst. Res. Behav. Sci., 24共6兲, 551–556.
Lillington, J.共2004兲.The future of nuclear power, Elsevier, U.K. Love, P., Holt, G., Shen, L., Li, H., and Irani, Z.共2002兲. “Using system
dynamics to better understand change and rework in construction project management systems.”Int. J. Proj. Manage., 20, 425–436. Love, P., Li, H., Irani, Z., and Faniran, O.共2000a兲. ‘ ‘Total quality
man-agement and the learning organization: A dialogue for change in con-struction.”Constr. Manage. Econom., 18共3兲, 321–331.
Love, P., Mandal, P., and Li, H.共1999兲. “Determining the causal structure of rework influences in construction.” Constr. Manage. Econom.,
17共4兲, 505–517.
Love, P., Mandal, P., Smith, J., and Li, H.共2000b兲. “Modeling the dy-namics of design error induced rework in construction.”Constr. Man-age. Econom., 18共5兲, 567–574.
Lyneis, F., Cooper, K., and Els, S. 共2001兲. “Strategic management of complex projects: A case study using system dynamics.”Syst. Dyn. Rev., 17共3兲, 237–260.
Matta, F., and Ashkenas, R. 共2003兲. “Why good projects fail anyway.” Harvard Bus. Rev., 81共9兲, 109–114.
Nassar, K., Nassar, W., and Hegab, Y.共2005兲. “Evaluating cost overruns of asphalt paving project using statistical process control methods.” J. Constr. Eng. Manage., 131共11兲, 1173–1178.
Nepal, M., Park, M., and Son, B.共2006兲. “Effects of schedule pressure on construction performance.” J. Constr. Eng. Manage., 132共2兲, 182–188.
Nuclear Regulatory Commission 共NRC兲. 共1982兲. “Nuclear power plant construction status report 06/30/82.”NUREG-0030 6(2), Washington, D.C.
Ogunlana, S., Li, H., and Sukhera, F.共2003兲. “System dynamics approach to exploring performance enhancement in a construction organiza-tion.”J. Constr. Eng. Manage., 129共5兲, 528–536.
Park, M., Nepal, M., and Dulaimi, M. 共2004兲. “Dynamic modeling for construction innovation.”J. Manage. Eng., 20共4兲, 170–177. Park, M., and Pena-Mora, F.共2003兲. “Dynamic change management for
construction: Introducing the change cycle into model-based project management.”Syst. Dyn. Rev., 19共3兲, 213–242.
Pena-Mora, F., and Li, M.共2001兲. “Dynamic planning and control meth-odology for design/build fast-track construction projects.”J. Constr. Eng. Manage., 127共1兲, 1–17.
Pena-Mora, F., and Park, M.共2001兲. “Dynamic planning for fast-tracking building construction projects.” J. Constr. Eng. Manage., 127共6兲, 445–456.
Pulizzi, H.共2006兲. “Bush outlines U.S. initiative to build nuclear power plants.”Wall Street Journal,具www.wsj.com典 共July 17, 2006兲. Repenning, N.共2001兲. “Understanding fire fighting in new product
devel-opment.”J. Product Innovation Management, 18共5兲, 265–300. Schelling, T.共1971兲. “Dynamic models of segregation.”J. Math. Sociol.,
Smith, A.共1776/2004兲.The wealth of nations, Barnes and Noble, New York.
Smith, R.共2007兲. “Power producers rush to secure nuclear sites.”Wall Street Journal, January 29, A1.
Sterman, J.共2000兲.Business dynamics: Systems thinking and modeling for a complex world, Irwin McGraw-Hill, New York.
Taguchi, G., Chowdhury, S., and Taguchi, S.共2000兲.Robust engineering, McGraw-Hill, New York.
Tang, Y., and Ogunlana, S.共2003兲. “Modeling the dynamic performance of a construction organization.” Constr. Manage. Econom., 21共2兲, 127–136.
Taylor, T., and Ford, D.共2006兲. “Tipping point failure and robustness in single development projects.”Syst. Dyn. Rev., 22共1兲, 51–71. United States House of Representatives共USHOR兲.共2005兲. “Digging up
the facts: Inspecting the big dig and the performance of federal and state government in providing oversight of federal funds.” Hearing before the Committee on Government Reform, House of Representa-tives, 109th Congress, April 22, Serial No. 109-29.
United States Senate共USS兲.共2000兲. “Oversight hearing on the Boston central artery/tunnel project.”Hearing before the Committee on Com-merce, Science, and Transportation, 106th Congress May 3, Senate Hearing, 106-1110.
