Abstract
It is recognized that projects continue to deliver operational assets that are partially defective. This article proposes this because the causes of operational failures have not been extensively analyzed. This study explores how an infrastructure client made quality a strategic and project delivery necessity by undertaking research to analyze operational failure. A mixed-method approach consisting of three phases was used: (1) to understand the operational failure elements; (2) to explore the causes of operational failure; and (3) to develop a new strategic framework to address failure mitigation. The study showed the need for transferring, applying, and recognizing capabilities across strategic business, project delivery, and operational use transitions.
Introduction
Infrastructure owners suffer from quality issues at post-construction project handover, with some asset systems and subsystems failing to operate. While this is understandable, because projects are complex, high pressure (Love et al., 2002), and face uncertainty (Atkinson et al., 2006), failure has now become routine. Mature infrastructure owners are challenging these routines and collecting data to mitigate operational failure. They recognize that collecting data on quality is the only way to progress the sector. From a low-margin, low-innovation, high-error, high-claim, and high-health and safety incidence sector, to one that is strategic, integrated, innovative, and systematic in delivering quality. There will, no doubt, be a requirement for increased planning and a preventative quality management approach; without data, however, industry change will be very difficult. Institutional acceptance of failure appears to be blended into the construction process. Restoration of quality (CIOB, 2018) and a more challenging process of its delivery (Delgado-Hernandez & Aspinwall, 2008) must be priorities.
Studies have documented the causes of operational failure (Barber et al., 2000; Hillman Willis & Willis, 1996; Hwang & Aspinwall, 1996; Teo & Love, 2017), but there is a need to develop better solutions and new strategies to mitigate these failures (Krishnan, 2006; von Ahsen & Ahsen, 2008). Part of this will be demonstration of the significant cost of operational failure in order for organizations to better see the interorganizational quality impacts on firms and the need for a more strategic approach to mitigating operational failure across transitions. This article focuses specifically on quality issues at project transitions that impact project operations (Slack, 2005), an infrequently explored area of project management. The aim is to quantify and qualify quality issues across project transition in developing the failure-mitigation capability of a major infrastructure owner.
Quality Issues and Failures at Project-Operation Transition
The transactions among various strategy, project delivery, and operational use teams across different transitional phases can contribute to an increase in operational quality, but there are often issues that affect this. Issues within a phase—such as defects or rework (Cauchick Miguel & Pontel, 2004; Jingmond & Ågren, 2015)—are often investigated, but seldom are those at the transition (e.g., from project to operations). As a result, there are limited control and management of these transition issues and little assurance of integration of capabilities across phases, especially when projects are viewed as short-term and temporal transactions (Lundin & Söderholm, 1995).
Large projects failure is not unexpected (Flyvbjerg et al., 2002). Heathrow Terminal 5 (Caldwell et al., 2009), Berlin Brandenburg Airport (Nieto-Rodriguez, 2017), and the Millennium Dome (Bourn, 1999) are examples of projects with failure routed in transition issues and lack of integration across phases. Leading infrastructure owners are looking at operational failure in a new way. They are looking more directly at root causes and measuring the actual and significant costs associated with them across project transitions and the impact of these on operational performance. A strategic approach to mitigating operational failure is needed to integrate the diversity of capability, share the risks, and build shared ownership to mitigate these failures.
It is well known that projects sometimes fail to identify operational requirements across the different transitions (Davies, 2004; Symons et al., 2017), capabilities, and systems (Helms et al., 2006). What is evident is that operational assets are not fully integrated in terms of their systems’ technology and against the increasing expectations of stakeholders requirements, which lead to quality issues at operations. Among other things, operational failure causes damage to reputation (Love et al., 2018) and wastes money (Miguel, 2015) throughout the systems’ life (Josephson & Saukkoriipi, 2005; Zerjav et al., 2018). A vital challenge is the insular way in which quality issues at project transitions are understood and overcome through project management (Dale & Plunkett, 1995) and the distribution of capabilities during the strategic stage (Eisenhardt & Martin, 2000). Projects are seldom appraised to determine which part of the product and service lead to internal project and operational failures. Traditional behaviors prevent full explanation of the root cause. As such, failures frequently re-emerge with limited interorganizational learning.
Frequently, operational failures are seen as an individual responsibility rather than shared by the whole project team to deliver an integrated and dynamic response (Peña-Mora et al., 2008; Snieska et al., 2013). Quality issues between projects and operations can result (Rosenfeld, 2009) unless the causes of such failures are mitigated. Personnel issues (Thiry, 2002) or deficiencies in management (Sage et al., 2014) have according to project management scholars previously caused failure (Pinto & Mantel, 1990); however, quality issues across the transitions have not been well explored (Abd Razak et al., 2018). What is needed is theoretical clarity (Sage et al., 2014), and knowledge of the capabilities needed to mitigate these failures (Ahern et al., 2015). It is imperative, therefore, that owners advocate the comprehensive study of failure and establish a new integrated capability model that includes a more routinely collaborative environment to address quality issues and mitigate failures at project–operation transitions.
Integrated Capabilities to Mitigate Operational Failure
Capability development for long-term and stable operations must be continuously reconfigured (Dosi et al., 2008; Schreyögg & Kliesch-Eberl, 2007) to match operation to strategy (Tatikonda & Montoya-Weiss, 2001). There must be integration across short-term projects (Davies & Brady, 2016) and cross-party investment (Ethiraj et al., 2005). This requires collaborative effort (Eriksson & Westerberg, 2011) to distribute capabilities across a network of partners (Frohlich & Westbrook, 2001).
Organizational capabilities—ranging from routines, knowledge, skills, and experiences (Chandler, 1992; Davies & Brady, 2016)—must be employed to make cost savings. Despite this, however, operational failure costs have remained hidden (Abd Razak et al., 2016), absorbed into overheads or day-to-day costs. Studies have shown failure costs can range from 50% to 90% of the total cost (Snieska et al., 2013), but a true figure is elusive. Poor cost estimation is a partial reason for failure (Assaf et al., 2015) due to lack of knowledge (Josephson, 1998) about quality issues during project transitions. Authors have inaugurated the need to take additional steps to explore the specific nature of these costs (Adam et al., 2015; Love et al., 1999) to improve competitiveness. However, first, there are needs for greater collaborative integration (Demirkesen & Ozorhon, 2017), to increase quality and lower costs and, most importantly, to mitigate operational failure.
Although it is the owner and operator who play the most important roles in keeping and advancing the range of capabilities (Morris & Hough, 1987; Winch & Leiringer, 2016; Winch, 2014), project-based expertise spans a broad range of organizations (Hobday et al., 2005). Capabilities are often tacit, socially determined, emerge gradually over time (Leonard-Barton, 1992), and so are interrupted by the temporal nature of projects. There is a need, therefore, to explore, experience, and innovate through the dynamic interplay between the firms’ internal capabilities and the changing nature of the project (Davies & Brady, 2000) to influence a new set of services (Davies & Mackenzie, 2014) for future interorganizational network success (or to mitigate failure). These capabilities will create, extend, and modify the ways in which firms operate (Harreld et al., 2007; Söderlund et al., 2008). Given the temporary nature of projects (Lundin & Söderholm, 1995), a repeatable solution needs to be captured with a concentration on operational impacts (Slack, 2005).
In different project transitions, an organization needs to acquire sustained firm performance to carry out capabilities in an efficient way (Melkonian & Picq, 2011), foster evolution, respond to changing environments, and mitigate operational failure. This will help the organization to expand its knowledge and enrich their core competencies (March & Levinthal, 1993), thus improving decision making and preventing failure during operations.
Capabilities for Operational Failure Mitigation in Complex Networks
Projects are fundamentally network-based organizations (Styhre et al., 2004) that consist of different capabilities. These capabilities, transferred within projects, should be captured and managed (Pemsel & Wiewiora, 2013) to improve, renew, and reconfigure resources into new capabilities and competences (Hagström et al., 1999). Due to the unique and temporary nature of projects, complex projects face substantial challenges in harnessing the capabilities to exploit lessons learned from previous projects (Bellini & Canonico, 2008) to prevent repeat failures. However, projects may be referred to as similar when the same capabilities and routines are required for their repeated execution (Davies & Brady, 2000). This gives owners a great opportunity to recognize these valuable capabilities as a way to improve (Winch & Leiringer, 2016). However, reconciled objectives, a collaborative team culture, and learning networks must overcome temporal boundaries, foster innovation, build trust, and share capabilities (Hobday et al., 2005; Kwak et al., 2015; Styhre et al., 2004; Wu et al., 2010) that manage and prevent possible operational failure.
Little research has been undertaken to show how capability building across project transitions to connect operations to projects and vice versa, and how visibility of quality issues and costs might mitigate failure (Love et al., 2002). We prefer, instead, learning and innovating on projects when it is perhaps too late (Kerzner, 2009; Pemsel & Wiewiora, 2013). When capabilities are not captured, this inevitably leads to a loss in failure-mitigation capability.
Research Methodology
Sample Design
A UK infrastructure owner self-selected to participate in the study and nominated five projects according to their project timeline, project relevance, participant support, access consent, and explicit expertise available within the research area. A Delphi technique was used with an expert sample to increase reliability (Okoli & Pawlowski, 2004). This was undertaken with the quality team and project managers to build a consensus on the best case studies in order to understand operational failure. Table 1 provides project descriptions. A case study protocol was used in generating data to help ensure reliability (Yin, 2003).
The Multi-Case Study Project Descriptions
Table 2 defines the interview sample. Appendix A details the issues found on projects A to E. An initial sample of seven (n = 7) owner project managers for each project were selected in stage two, which allowed snowball sampling to identify the various project and operation participants (e.g., commercial, supplier, and facilities management). The interviewees were asked about who was involved with specific operational failures to generate further insight into the link among operational issues, quality cost, and construction supply network. Twenty-six (n = 26) interviews were then conducted within the identified projects and operational teams.
List of Participant Roles and Unique Anonymous Identifying Participant Codes
The Units of Analysis Across Three Stages
The research was conducted in three stages:
To understand and appraise the operational element through a questionnaire survey that was sent to a selective sample of industry-based experts (n = 42);
To explore the causes of operational failure through semi-structured interviews with the project supply chain (n = 26); and, lastly
To develop strategic project management approaches that addressed transition issues in failure mitigation through mapping data in an advanced owner workshop with experts (n = 4).
The outcome of stage 1 (Figure 1) was a definition of the external failure quality elements that were subsequently used in stage 2.

Failure categories from Stage 1 cost of quality framework definition (Abd Razak et al., 2016 and 2018).
Semi-structured interviews were employed to “learn the respondent’s viewpoint regarding situations relevant to the broader research problem” (Blumberg et al., 2008, p. 386); thus, a snowball method was used to elicit further stakeholder and situation-specific details when quality issues were explored to understand failure. This theoretical sampling (Charmaz, 2014) allowed for the emergence of concepts from the initial data to reach saturation.
Stage two interviews (Figure 2) worked with project managers and quality teams to select project-specific quality issues, which were then discussed to understand the causes (e.g., organizational structure and management, procurement, supply chain, design/production/control, stakeholder engagement, other) and assign cost of quality failure estimates. Appendix B contains the stage two semi-structured interview questionnaire, which partially used card sorting to facilitate a cause–effect dialogue around project-specific costs of quality failure issues.

Example of the cost of quality failures causes and effects.
The grounded (Charmaz, 2014) and human and inter-organizational complexities of the case studies (Quinlan et al., 2015) were used to develop a new framework to address failure mitigation.
Analysis Method and Theory Emergence
A case study protocol was used to build data reliability (Yin, 2003). A thematic method that began with coding transcribed interviews, investigated each project on a case-by-case basis. Emerging pattern codes and categories were visualized through concept mapping to provide clearer explanation on the event that constituted operation failure. Selective coding of the core categories, pattern matching, and visualization was used to enable cross-case comparison (Miles & Huberman, 1994; Yin, 2003).
Quantifying Operational Failure Across the Transition
Focusing on failure through quantifying its cost could demonstrate the root cause of its occurrence and create solutions to the intangibility of its high occurrences. This could help to provide a greater understanding of the linkage of cost incurred, responsible parties, and the chain that constitute the event. Figure 3 shows the elements selected by expert project participants during all case studies. All elements were selected at least once for four or more projects, with the exception of early obsolescence (which was selected for case study Projects C and E only). Safety cost for operator was the most selected element (n = 11), followed by maintenance (n = 9) and life cycle (n = 8) and latent defect cost with (n = 7). Project B shows the lowest selection among all quality cost elements, and Projects A and E have a wide range of selected elements (2 to 7 times on most quality cost elements).

Selected cost of quality failure elements across all project case studies.
During the interviews, participants were asked to select which failure elements occurred and what the estimated/real costs of the selected elements were (Table 3). The costs were divided by the total cost of the project and described as a percentage (%) shown below. The result shows that operational failures could range from 0.1% to many times more than the total project cost—for example, in Project C the contractor perceived the reputational cost as seven times that of the project (if for example they were to lose their place on a procurement framework). This indicates the significant impact of operational failure cost across project transition if it is not mitigated.
Estimated Cost of Operational Failure Quality Elements as a Percentage of Total Project Cost (Brackets Contain the Project [See Key] and the Number of Participants)
This range of operational failure percentages is significant. Most case studies indicated that costs were shared/exchanged among the owner and supply network, although it shows the significant cost associated with failure. The range of these percentages shows the uncertainty that project participants will have when pricing for and allocating project risk. Anecdotally, project supply chain participants all add 5% to mitigate their own failure. More needs to be done, therefore, to understand the various competing interests of failure mitigation and to align around a common need to increase both project and operational quality.
Qualifying Failure-Mitigating Capabilities Across Transitions
Distribution of capability in a project influences the occurrences of operational failure across project transitions. Figure 4 shows the causes of failure over the development–project transition and effects on project capability when the owner is not able to set the project on the right path from the very beginning. Project planning by way of setting the budget, time, and policy has a significant influence on project execution. Project planning establishes the quality culture, sets the standards, and determines the commercial and governance structures.

Owner’s capability in the development phase drives project execution (Transferring – Applying Capability).
Figure 5 shows the causes of failure at the transition from project execution to the operational phase. The influence of capability distributed toward operational failure is on the formation of operational capability through the transference of skills based on the project to those in operation. Thus, owner and other supply chain member involvement with the project is key. Increased integration between the owner’s technical expertise and contractor reduced operational failures. Capabilities of the “certified” contractor were often critical in operation, but were not fully transferred. This capability is critical in mitigating failure and making improvements in future projects.

Project capability impacting operational capability (Applying – Recognizing Capability).
Figure 5 shows the influence of project capabilities on operations. Operational failures were seldom a priority during delivery, but on completion the reputational impact was significant. As a result, the contract was used to apportion blame and appoint responsibility. This analytical information was then used to form the discussion of how owners could develop integrated capabilities across their strategic requirement, technical project delivery, and functional operations management to mitigate failure.
Discussion
It is known that the cost of operational failure often remains hidden and difficult to quantify (Barber et al., 2000; Rosenfeld, 2009). This study has helped to align organizational structures and commercial relationships to establish a shared responsibility for three capabilities in mitigating operational failure. Transferring, applying, and recognizing capabilities are the basis for learning across various strategy, project delivery, and operational use teams to address transitional issues. The case studies showed that operational failure was caused by a shortage of transferring capabilities. This was often due to project-based constraints, such as a contracted end date, the allocation of budget to fit project specifications, the owner’s relationship with the supply network, and investment in innovation with demanding regulations. Figure 6 shows a significant influence on how the owner, from the strategic requirement phase, transferred the capability needed to develop technical project delivery capability. Capabilities that were applied during project execution were then developed as functional operations management capabilities through asset integration.

Triggering factors of operational failure in the capabilities cycle.
Frequently, operational failure was caused by a deficiency of information flow among technical delivery partners and operations managers. Critically applying capabilities required an understanding of real-life operational technicalities. There were also design constraints, issues associated with trust in the contractor’s expertise and resources, and technical competency in on-site operations. Finally, the operational failures were caused by an absence of some critical recognizing of capabilities, for example, the need for technical expertise during operations and learning not captured during the project. These failure-mitigating capabilities are further described in the following sections.
Transferring Capability
The supply network in construction is frequently fragmented, with different construction participants having separate responsibilities and separated by phases of the construction life cycle. The general contractor usually supplies the entire construction project, integrating subcontractors and suppliers for the owner (Hu, 2008), but this has highlighted an issue with the transition to the operational stage. Thus, long-term relationships between the owner and contractor could initiate inconsistencies in operational assurance. Various organizations have different quality approaches, and so the owner needs to be a steward for suppliers to build an integrating capability (Winch & Merrow, 2012) However, as this quote illustrates, there may be gaps in the assurance process on some projects.
“… we had assurance …, [contractor] had assurance and … second tier of supply they had assurance [but still] we get into a situation where everybody took a picture of something that was wrong… we need[ed] to get it finished…but if they look back now for the sake of a week or to two weeks then they could have finished it right the first time rather than come back and do things again." [Project A—Owner’s Project Manager]
The owner now realizes the potential transitional issues that may cause failure and the importance of a shared capability to mitigate failure in future projects.
Applying Capability
Lack of operational capabilities in the project delivery team limited collaboration in the prevention of operational failure. Typically, the supply network may not fully understand operational requirements across transitions. Although handover to operations (Davies & Brady, 2000) and design for use (Soderlund & Tell, 2011) have received some attention in the project management field, the causes of operational quality failure have received little attention. As emphasized in the following quote, a project-wide strategy to mitigate failures is required to, for example, allow designers to apply learning from operations back into design.
“…then [they repeat] exactly, same design, same specification and then you get the same issues.” [Project A—Owner’s Project Engineer]
A clearer vision of the owner’s operational needs and requirements across transitions could mitigate failures.
Recognizing Capability
Operational failures are caused when the capabilities to deliver and manage innovation have not been dynamically assessed (Teece, 2007; Zollo et al., 2002). The ongoing exploration of causes of operational failures across transitions is critical, as is the sharing of interorganizational learning and capabilities development in mitigating failure. As the following quote states, fragmented knowledge of the causes of failure can be enduring.
" …In fact it’s been leaking so the previous guy tried to resolve it in a number of ways but we never really got to the cause of the issues.” [Project A—Owner’s Project Manager]
Recognizing these capabilities and integrating responsibility for quality across transitions in the project life cycle are essential to failure mitigation. As the following quote shows, there is a need for a shared mindset across functional roles and organizations:
"… so you’d have [numbers of] technical engineer[s] come out and look…but because of the nature of the schedule, would almost pale into insignificance because “yeah whatever we’ve got to get it done.” [Project A—Owner’s Project Manager]
Learning from failure must be shared across different boundaries and time (Styhre et al., 2004). Owners need to recognize and bridge the capabilities between project and operational teams.
Integration Across the Capability Cycle
Projects must be integrated from the front end, through project tendering and delivery toward the handover and post-operation life cycle (Davies & Brady, 2000); this, however, is not always reflected in operational practice. There are different vocabularies and technical capabilities that must be integrated (Sage et al., 2014).
Capabilities have not been mutually altered and revised to enhance broader strategy to mitigate failures. Different organizations are involved (Söderlund et al., 2008), and so the most advanced organizations are combining experience and knowledge to deliver higher quality. Capabilities can only be evolved when the problem is faced over time (Ulrich & Lake, 1991) to design across transitions and predict different components of the project life cycle. Failures are frequently expected on projects, justified by transitional conditions and the one-off nature of projects. Critical is building shared capability by aligning commercial relationships to reduce the risk and increase the benefits of higher quality through measures of cost of quality. Operational failure does occur (Wu et al., 2010), and has been shown to incur various costs. In the cases reviewed, the cost of quality was most frequently minor with minimal impact on the owner or operator. However, there are other international examples where failure has been catastrophic. The owner and their delivery team must learn from experience (Pillai et al., 2002) if they are to mitigate future failures. Mature owners must appraise the operational failures (across project transitions) to understand when capabilities are missing, but also use this knowledge in the development of new project routines (Brady & Davies, 2004) and functions, hierarchy, and line management (Turner & Keegan, 2000). Project-based organizations need to promote knowledge across transitions to develop common knowledge and specialized technologies to achieve operational success (Wang et al., 2013; Zerjav et al., 2018).
Capable owners, in collaboration with contractors and suppliers, must build operational failure-mitigating capabilities across project transitions (Helfat & Peteraf, 2003) and they must influence the project-by-project mentality (Lindahl & Ryd, 2007). This work has shown that quantifying and qualifying quality issues across project transition could help to effectively foresee, prevent, and address failure at an early stage. This has contributed to knowledge in project management by illustrating the transitional gaps between strategic requirements, technical project delivery capabilities and functional operations, and the causes of operational failure. The implications for management are for owners to engage with interorganizational partners to develop failure-mitigating capability to improve the predictability and quality assurance of their projects and programs.
Conclusions
Assets delivered by projects are failing during operation, partly because of the complex interrelationships of various strategy, project delivery, and operational use teams across the system life cycle. The research discussed in this article investigated the failure-mitigating capabilities at three transitions: (1) strategic planning to project delivery, (2) project delivery to operational use, and (3) operational use to strategic planning.
Five project cases within a single client organization showed that failure is a ubiquitous problem, with little or no quantitative benchmarking data. Furthermore, much of the qualitative learning from root cause analysis remains tacit. As a result, the industry as a whole is failing to learn from known failures due to the fear of reputational damage. Leading clients, however, are challenging this learning deficiency to investigate the causes of operational failure. Integration of capabilities at transitions are needed among the owner’s strategic requirement, technical project delivery, and functional operations management to balance the risks, share the responsibilities for delivery, and increase quality assurance.
This research has helped all parties in understanding the different risks and costs borne by various parties. Future research is needed to develop predictive approaches to mitigate operational failure. Increased productivity and increased funding certainty would result from operational failure mitigation. Infrastructure owners could achieve significant commercial impacts, which if scaled across the industry could achieve substantial operational savings.
Footnotes
Appendix A. Descriptions of the Exploration of the Operational Issues Sample
| Project Type | Operational Issues | Cost of Quality Failure | Cost of Quality Saving |
|---|---|---|---|
| Project A—Buildings (Car Park) | Incomplete ducting for street lighting resulted in abortive cost from the UK power network. Poor drainage, design, and installation. Not cleaned appropriately (e.g., asphalt blocked) Leaks and patches due to poor water tightness Ponding due to poor quality construction of asphalt being laid. Floor leaking at forecourt due to poor waterproofing. Water bubbles at floor decking due to concrete plank system Emergency exit sign turns off during testing |
X X X X X X |
X |
| Project B—(Water Treatment Plant) | Non-compliance chemicals were used to dilute mixed fluid. Silt clogging the grip blaster. High detergent used causes foaming. |
X X X |
|
| Project C—(Transport Terminal) | Vinyl flooring tiles lifting and bubbling. |
X | X |
| Project D—Buildings (Escalator) | Introduction of parallel system to the security operation. |
X | X |
| Project E—Infrastructure (Resurfacing) | High ambient air temperatures and engine blast heating cause pavement to develop surface defects. |
X |
X |
Appendix B. Interview Questions and Research Outcome
Declaration of Conflicting Interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) received no financial support for the research, authorship, and/or publication of this article.
Note
Author Biographies
