مدیریت ریسک پروژه و انعطاف پذیری طراحی: تحلیل موردی و شرایط مکمل

We explore how risk management and design flexibility interplay in major (infrastructure) projects, using the £4.2bn Terminal 5 project to expand London's Heathrow airport. By juxtaposing these two conceptual frames, we unearth the conditions under which they can be complements for managing the tension between efficiency and effectiveness central to these projects. Building design flexibility – through modular or safeguarded integral architectures – increases adaptability to accommodate evolving requirements which is necessary to attain effectiveness. Efficiency, in turn, demands risk management to deliver the project ‘on time, within budget’. We explain variation in the interplay between the two approaches, highlighting the moderating role of the developer's relationship with the customer. Strong co-operation, particularly in a stable environment, encourages investments in design flexibility. Risk management practices prevail when co-operation breaks down. Another insight is that co-location and continuity of key project staff are themselves inadequate conditions to sustain co-operation.

Large-scale infrastructure assets such as an airport terminal, power station, or high-speed rail line are delivered through one-off, multi-year, capital- and engineering-intensive projects. The symbiotic relationship between the developer, who incurs the capital costs, and the customer(s) who will operate the asset, is central to these projects. Because customers’ needs evolve over time, they understandably want process flexibility to postpone design decisions and request late changes. But keeping the design fluid during physical execution is challenging, as gains in the effectiveness of the final asset may come at the cost of lost efficiency in project delivery, increasing the time and/or cost required for project completion. Hence, this tension between efficiency and effectiveness is a key characteristic of large infrastructure projects, and of large engineering (major) projects more generally (Morris, forthcoming). The risk management literature applied to major projects has recognised this tension. Scholars recognise that adapting the project to changes in customer needs can be business critical (Dvir and Lechler, 2004, Gil et al., 2006 and Miller and Lessard, 2000). To decide whether to accede to a customer's re-design request, project teams are urged to appraise and manage the risks of adapting the elements that are under detailed design or construction, as well as those elements that have been completed (Cleland and King, 1983, Cooper and Chapman, 1987 and Morris and Hough, 1987). Changes are typically accepted when their prospective benefits to future operations are thought to outweigh the adaptation costs and risk of delays, which can both be significant, especially in projects with integral design architectures (Shenhar, 2001 and Floricel and Miller, 2001). Extraordinarily, however, the development of project risk management has barely intersected with studies on commercial new product development, which consider the comparable problem of achieving efficiency whilst attaining consumer satisfaction. In this world, scholars advocate the use of modular architectures to achieve flexibility and substitute risk management under uncertainty (Thomke, 1997). Modularity enables set-based design and mass customisation practices, both of which permit a range of final products to be offered to consumers within the scope of the flexibility deliberately built into the architecture (Pine II, 1993, Sanchez, 1995, Sobek II et al., 1999, Clark and Fujimoto, 1991, Ward et al., 1995, Feitzinger and Lee, 1997 and Iansiti, 1995). Design modularity also enables developers to exploit product platforms over their life-cycle (Sanderson and Uzumeri, 1995 and Martin and Ishii, 2002) and to postpone design freeze to incorporate cutting-edge technologies for which premium prices can be charged (Iansiti, 1995). To explore how risk management and product design flexibility interplay in major projects, we undertook an inductive, multiple-case study of the £4.2bn (in 2005 prices) Terminal 5 (T5) project to expand London's Heathrow airport. Designed to handle 35 million passengers per year, BAA, the private owner–operator of Heathrow airport, began planning T5 around 1989. Planning consent was granted in 2001, and schematic design and construction began concurrently in September 2002. T5 opened ‘on time and within budget’ in March 2008. Our research design focuses on a key unit of analysis: co-design processes. We examined co-design processes for selected functional elements across different subprojects that involved the BAA's T5 team (the ‘developer’) and three separate future operators, the project customers. Our key contribution is a theoretical, longitudinal understanding of the conditions under which risk management and design flexibility can complement each other for managing the tension between efficiency and effectiveness in major projects. Critically, we find that the developer's willingness to invest in design flexibility – through modular or safeguarded integral architectures – is moderated by the extent the developer and customer co-operate effectively during the project. Effective co-operation encourages investments in design flexibility, whereas poor inter-relations encourage the realisation of a more rigid architecture. The lack of product flexibility increases the costs and risks of adapting the design to accommodate evolution in customer needs, shifting the emphasis toward project risk management. Interestingly, we show co-location and continuity of key project personnel are insufficient conditions to achieve and sustain effective cooperation.

By studying the interplay of design flexibility and risk management in a major project, we have bridged a gap between two frames of reference that have developed in parallel. We propose that design flexibility and risk management are complementary in managing these projects. Moreover, we argue that the quality of the developer's relationship with the customer conditions the balance of the two approaches. This conceptualization has managerial and policy implications. It highlights that unless customer and developer sustain co-operation and shared goals, project uncertainty increases and product designs are likely to become more rigid. As managerial complexity compounds, short-term concerns for efficiency can overshadow long-term effectiveness. At the limit, this can lead to early obsolescence and compromise detrimentally the operational longevity of the asset. Our insights are drawn from cases across a single setting, and we cannot claim generalizability from our findings to the whole universe of major projects. IT projects in particular have made notable progress towards modular architectures (Baldwin and Clark, 2000). The T5 project was also schedule-driven, and BAA was a profit-seeking, monopolistic infrastructure owner operating under public scrutiny. The T5 Agreement between BAA and its suppliers also facilitated greater flexibility in their relationship than is likely to have been the case had a commercially aggressive contract been adopted. These conditions are significant and constitute a limitation. Further studies to test the plausibility of our insights in other contexts are welcomed. Interestingly, whilst not the focus of this study, the ‘debacle’ (Brady and Davies, 2010) that characterised T5's opening – when 15% of scheduled flights were cancelled and over 23,000 bags ‘misconnected’ in the first two weeks of operations – becomes less surprising. The accounts of BAA and BA to the House of Commons Transport Committee (2008) suggest that the bungled opening was caused by the simultaneous realisation of two main groups of risks: 1. inadequate familiarization and insufficient training of airline staff, especially baggage handlers (which BA framed as ‘calculated risks’, attributing them to compromises it had agreed with BAA to accommodate delays in the building schedule and incompleteness of some essential facilities); and 2. software problems and unserviceable facilities, including lifts, escalators, and toilets (which BAA framed as ‘no more than teething troubles’). Critically, the accounts indicate that co-operation between the two companies deteriorated towards the end of the project. Assuming the insights from managing co-design apply to project handover, this deterioration may have stymied exchanges of information essential to manage the hand-over stage, creating instead new and additional risks. With the developer's attention fully focused on delivering T5 on time and within schedule, these risks may well have been overlooked. Testing this logic, of course, requires a further study. A final point of interest, relevant to policy-makers, is how to incentivise monopolistic private developers of public infrastructure assets to build-in greater design flexibility. Importantly, private development of public infrastructure is a growing socio-economic phenomenon worldwide (Gil and Beckman, 2009b). But, as indicated earlier, public and commercial pressure on private developers to deliver capital projects on time and within budget can incentivise managers to make short-term savings, reducing or removing design flexibility, leaving their successors to make amendments (where possible), at greater long-term cost to shareholders and society at large. Given that authorities regulate the price structures and service levels under which monopolists operate, one thought is to factor into the regulatory process mechanisms that encourage design decisions that enhance operational longevity. In the planning stage, the developer could be required, within reason, to build-in design flexibility to pre-specified levels, and later in operations, be permitted to reap the monetary rewards for doing so.