Reframing Systems Integration: A Process Perspective on Projects

The delivery of large-scale technical systems is achieved through project organizing. The concept of systems integration, with its distinct focus on the systems that projects deliver, is theoretically important as projects become more complex and face significant uncertainty. We reframe systems integration in interorganizational projects as a flexible and adaptive process of making constituent parts of systems work together. This process involves boundary-spanning structures and activities to address emergent complexity and uncertainty (that are both technological and organizational in nature). We discuss implications and highlight areas for further research on projects.


Introduction
Systems integration is the process of making constituent parts of systems work together. It has a distinct focus on the systems that projects deliver. Systems integration is particularly challenging on large, complex projects with numerous interdependent parts that have to be coordinated, adjusted to each other, and fitted together (Hirschman, 2015, pp. 43-44), including diverse knowledge and components (Prencipe, 2003) that can be intangible as well as physical in nature. Systems integration refers to the work undertaken across organizational boundaries in interorganizational projects to integrate the systems that these projects deliver. As the world's first dedicated systems integrator firm, for example, Ramo-Wooldridge Corporation, in California, USA, worked across organizational boundaries on the Atlas missile defense project (following World War II) with the responsibility for coordinating "the work of hundreds of contractors and development of thousands of sub-systems" (Mahnken, 2008, p. 38). Yet separating responsibilities for systems integration from those of project management has not been successful on later projects (Hughes, 1998). Systems integration, and the associated practices of interface management, are a natural locus for project management (Morris, 2013).
While this article builds on insights and original ideas in foundational literature (e.g., Sayles & Chandler, 1971) a new stream of research on systems integration in projects is important as the scale, uncertainty, and complexity of modern projects are growing (Flyvbjerg, 2017). Additionally, deliverables on projects are becoming increasingly cyber-physical, with sensors and control systems, data flows and behaviors, as well as physical components. The global climate emergency and COVID-19 pandemic increase uncertainty, and there is greater need for systems integration activities across multiple levels. In articulating a new perspective, we reframe systems integration in interorganizational projects as a flexible and adaptive process of making constituent parts of systems work together to achieve outcomes by delivering systems. We do not argue for return to a closed, technical, engineering approach to project delivery but rather for a processual approach informed by recent work on the organizational as well as technical aspects in the delivery of engineering systems (e.g., De Weck et al., 2011) and on modularity, coordination, and complexity (e.g., Anderson & Meyer, 2016;Oliveira & Lumineau, 2017;Tee, 2019). The large-scale technical systems that interorganizational projects deliver, such as the Sydney Opera House and Channel Tunnel, are often transformative for societies. Their delivery is intrinsically bound with forms of project organizing, shaped through work across their emergent technological and organizational boundaries.
Projects such as megaprojects intervene "in a purposeful and deliberate manner" (Geraldi & Davies, 2021), delivering systems that work interdependently with other systems in operation. Systems integration continues to be a practical challenge in such projects, constraining the delivery of projects and the realization of their value. Systems integration issues often manifest toward the end of projects. One example is the Berlin Brandenburg Airport in Germany, where a fully constructed airport opened in 2020 after years of delay, as roles and responsibilities for systems integration were not clear (Fiedler & Wendler, 2016). Another example is the London Crossrail project in the United Kingdom, where the installation of track and systems in tunnels caused significant delays to the program (NAO, 2019). Such projects involve different levels of systems integration with interfaces and buffers between and within them (Davies & Mackenzie, 2014). Diverse knowledge and physical components are brought together, both in the project's subsystems, systems, and system of systems and in their integration with operational systems. Figure 1 provides a simple representation, summarizing the different levels of systems integration that require interfaces and buffers between and within them.
In this article, we argue that systems integration, with its distinct focus on the systems that projects deliver, is theoretically important for addressing how project complexity and uncertainty are managed. We build on extant research that has developed understanding of complexity and uncertainty in projects and how this emerges (e.g., Daniel & Daniel, 2018;Geraldi et al., 2011). Systems are characterized by emergent properties and nonlinear behaviors (von Bertalanffy, 1968). Complexity grows with increases in the number of components and interfaces (Shenhar & Dvir, 2007); uncertainty means that aspects of the project are not completely known or predictable (Lenfle & Loch, 2010) and constantly changing due to the dynamics technologies and markets (Brady & Davies, 2014). While system integration refers to the integration of one system, in complex interorganizational projects there are always multiple systems. We use the plural term systems integration to encompass the multiple systems involved and work across levels, including the work of the metasystems integrator, operators, and users.
In the next section, we distinguish four different approaches to systems integration in the extant work. While each approach seeks to address complexity and uncertainty, we argue that the technical concerns of engineering and the organizational concerns of management cannot be separately addressed to accomplish systems integration but need to be combined. The following section provides an overview of our reframing of systems integration, how it unfolds over time, and how emergent complexity and uncertainty arise. The next section then considers how such emergent complexity and uncertainty are technological and organizational in nature and managed through systems integration structures and activities. The subsequent section draws out implications for project setup and delivery models, and for firms involved in projects. We conclude by highlighting how this new perspective on projects brings insight into current debates and by suggesting areas for future research.

Approaches to Systems Integration
In the literatures that focus on projects as a unit of analysis, we distinguish and characterize four approaches to identifying the different aspects of systems integration in complex interorganizational projects, as shown in Table 1. These focus on aspects of systems integration: approaching it as phase, specialist function, project-level technical process, and program-wide strategic function. These four approaches are identified through an interpretive review of work on systems integration across the engineering and management literatures and many conversations with project practitioners. The first two approaches draw largely on engineering literature, bringing a more technical and processual perspective. The second two draw largely on the management literature, which has sought to differentiate levels at which systems integration takes place. Below we consider each of these approaches, summarized in Table 1, in turn. First, the engineering literature discusses systems integration as a phase. This is represented in a systems engineering V diagram process (Fairley et al., 2019;Snoderly et al., 2019), which involves systems decomposition at increasingly detailed levels down to the components (the downward stroke of the V), followed by systems integration from the components up to the system (the upward stroke of the V). The V reminds practitioners of the connections between decomposition and integration, with verification and validation required at every level. In work on complex engineering projects, Eppinger et al. (2014) discuss integration tasks as component testing, subsystem validation, system validation, and system deployment. The focus is thus on later stages of projects, when systems integration challenges often manifest and disrupt projects and is associated with testing. This approach to systems integration is illustrated, for example, in the discussion of systems integration and requirement testing on Crossrail (Bhamra & Georgaras, 2018) or in the recommendation that on the HS2 railway project, the government should seek assurance: "whether any delays against schedule are reducing the time allocated for the critical stages of systems integration and testing of the railway" (NAO, 2020, p. 13).
Second, in the engineering literature, systems integration is also associated with control engineering and specialist crosscutting engineering activities (e.g., Sztipanovits et al., 2011). There are significant areas of research on systems integration around control systems, robotics, cyber-physical, or mechanical-electrical systems. The focus is on the integration of systems seen to be of particular complexity, rather than all systems. In transport engineering research, Wu et al. (2008) focus, for example, on: "online integrating heterogeneous systems such as a real-time vision system, a lateral controller, in-vehicle sensors, and a steering wheel actuating motor" (p. 246). This approach is also taken in projects, with the systems integration contract in London's Thames Tideway Tunnel project focused solely on control systems (Water, 2014). An advantage of this approach is that it directs attention to complex and difficult aspects of systems integration, which can be a major issue in projects. Specialist cross-cutting engineering activities become important where a subsystem interfaces with many parts of the overall system and where there is growing complexity in deliverables, such as where computational devices become embedded in physical components. In the late stages of the Crossrail project, for example, the challenge of integrating three different signaling systems significantly delayed opening (BBC, 2018). Such a narrow approach, however, may encourage a focus on a subset of the whole and failure to consider other important aspects of systems integration on projects. Third, in the management literature, systems integration is conceived as a project-level technical process of coordinating supplier networks (Gholz et al., 2018) and the related organization of project tasks. The focus is on managing technical coordination and changes at the component, subsystem, and system levels (Hobday et al., 2005), with particular attention to organizational boundaries and the interdependencies (Hui et al., 2008;Levitt et al., 1999) across these, which arise because of the: "difficulty in managing and keeping track of the huge number of different interconnected tasks and activities" (Remington & Pollack, 2008, p. 7). Historians of large technical systems have emphasized the social nature of systems integration through projects (Hughes, 1998;Johnson, 2003). Taking the project, rather than the firm as the locus of systems integration, systems integration strategies are found to combine modular architectures and integrating practices (Tee, Davies, et al., 2019). They involve learning on projects (Anderson et al., 2019), with projects playing a strong role in capability development in industries where the supply chain is not dominated or led by a single focal firm (Rutten et al., 2009). Erbil et al. (2013, p. 77) note that: "various actors can be system integrators at the different phases of a project, while a system integrator's role may also evolve over time." For example, responsibility for systems integration may be shared between the lead designer (at the design stage) and the lead contractor (at the construction stage) in the construction sector (Winch, 1998). It is the variety of ways in which the project-level technical processes can be organized that makes systems integration an important consideration in project delivery models.
Fourth, the management literature on systems integration also identifies program-wide strategic processes at a metasystems integration level (Davies & Mackenzie, 2014). These concerns go beyond questions of internal organization in the project delivery team to identify different ways projects can be set up and how they engage with the concerns of project sponsors, clients, and owners. Project sponsors can choose a cooperative strategy (e.g., NASA), with a high degree of involvement and reciprocal systems of organizational control in which they may receive as well as give advice (Sayles & Chandler, 1971, pp. 105-106). In sectors such as defense, both the public and private sectors may make a significant contribution in this approach to systems integration (Howard et al., 2016;Lazaric et al., 2011). Such program-wide processes include the understanding of client needs (Momeni & Martinsuo, 2019), the delivery of integrated products and services (Davies et al., 2007), and digitally integrated approaches used to engage with end users (Whyte, 2019). Managing this wider environment for systems integration can be a challenge on major projects, such as Berlin Brandenburg Airport, which have dispersed "regulatory power, technical expertise, delivery capacity, and financing ability" (Fiedler & Wendler, 2015, p. 1) across public and private sectors and face the added challenges of a high level of public attention or political interest.
These four approaches to systems integration are not in conflict, but each provides a partial view of systems integration. A question arises: Can the organizational concerns of management and the technical concerns of engineering be distinguished and separately addressed to accomplish systems integration in today's projects? We argue that they cannot be separately addressed to accomplish systems integration but need to be combined. In complex interorganizational projects, new questions thus arise about how to organize projects to focus attention on the particular systems integration issues of most concern at a particular point in time; how to plan for issues that may conceivably arise in the future; and how to be adaptable and flexible to address emerging complexity and uncertainty. Approaches will be project specific and also may differ across the different levels within a project. They need to be carefully considered as part of project setup and delivery models as systems integration requires capabilities both to coordinate across known stable components and disciplines at a specific point in time, and to coordinate several trajectories of uneven and dynamically changing developments over time (Sapolsky, 2003).

Reframing Systems Integration
Systems integration in interorganizational projects is concerned with designing, building, and testing delivered systems, and bringing the constituent parts together. Emergent properties, such as safety, security, and resilience are not identifiable in components or modules, but emerge across technological and organizational boundaries and are of critical importance to project outcomes for owners, users, and stakeholders. These properties need to be carefully managed as work is done across boundaries to make the systems that interorganizational projects deliver operational outcomes. We reframe systems integration to provide a new process perspective on projects, to achieve outcomes by delivering systems, with strategies to address project complexity and uncertainty arising in the organization of delivery and affecting the delivered system.
The concept of a project delivery model identifies how the multiple parties involved in a complex project are organized to create and capture value on a one-time basis for a client and disbanded when the project is completed . This research on project delivery models offers insights into how a lead organization is assigned responsibility for systems integration and creates and captures value in large, interorganizational projects. The challenge is to select or develop a delivery model to do this throughout the life cycle of the project-from design, construction, integration, fit out, testing, and handover to the provision of services to operate and maintain the asset over an extended period of time. Systems integration is one of the core processes or activities of a project delivery model (Denicol et al., 2020), determining how deliverables will be integrated across organizational boundaries, how design changes and assurance will be managed, and how integrity will be achieved (Whyte et al., 2016). In a review of Crossrail, the National Audit Office argued that not only was "the absence of a realistic plan […] set against an atmosphere where 'can do' became unrealistic" (NAO, 2019, p. 11), but responsibilities were devolved downward, with no requirement for individual contractors to manage interfaces with other contractors, which led to many issues with integration (NAO, 2019). Design of the project delivery model has to consider how systems integration will be achieved practically at the different levels, devolving responsibility for systems integration to the groups with both the technical expertise and organizational connections to enable progressive assurance. Subsystems may be treated as modules that can be progressively integrated, for example, as a new urban development or metro system is built in phases.
Decisions on project delivery model shape organizational design and processes, and hence the interfaces among practices of the delivery team.
We reframe systems integration by moving beyond a static approach to consider the emergence of complexity and uncertainty across technological and organizational boundaries. We first describe a processual view of systems integration, drawing together the organizational concerns of management and the technical concerns of engineering to consider the coordination across known stable components and disciplines and then extend this to consider emergent complexity and uncertainty.

A Processual View of Systems Integration
For each component within the project, the process of systems integration involves actors and activities working from the subsystem, systems, system of systems, and operational systems levels. This process is represented in relation to a component in a model shown in Figure 2. The representation draws on those process models used and advocated by clients as best practice (e.g., ProRail, et al., 2013, p. 33), across the levels set out in Figure 1 in the introduction. Verification tests the subsystem, system, or system-of-systems to ensure the compliance with designs, regulations, and specifications, whereas validation ensures it meets client needs. Figure 2 draws attention to the relationships of system integration among the project phases of designing, building, and testing deliverables. At the start of a project, requirements and outcomes are considered and used to develop a first iteration of the systems architecture to address operator needs at project close. The approach to project organizing can thus assume the ability to fully define requirements and systems architecture at the outset or may retain the flexibility to evolve requirements and architectures in a controlled way during delivery. Using this system architecture, subsystems integrators with responsibility for integration of components into a subsystem, work with systems integrators with responsibility for the system of which their subsystem is a part. These systems integrators work with a metasystem integrator with responsibility for the system of systems, and the metasystems integrator in turn works with the operator with responsibility for ongoing operations.
Thus, Figure 2 provides a processual view of systems integration, building on work on systems integration as a phase to represent systems integration as a process that needs attention at project start; the designing, building, and testing of deliverables; and project close. Figure 2, like Figure 1, provides a high-level template for organizing to address known technological complexity and uncertainty in projects, managing it through hierarchical breakdown structures and well-defined processes. These representations provide powerful simple rules (Sull & Eisenhardt, 2015) that focus on time and effort. We do not think that complex interorganizational projects can be delivered without such relatively simple explanations that provide a shared vision and understanding across the project. Beyond the idea of systems integration as a testing phase toward the end of the project, temporal structures (Orlikowski & Yates, 2002) enact a template of what should be done, as diverse organizations are involved in the development of components and subsystems based on more or less mature technologies. Where technologies are underdeveloped or rapidly developing, the systems architecture and process can seek to buffer the development of other parts of the system. However, as complexity and uncertainty emerge across technological and organizational boundaries, this process needs to be flexible and adaptive, guiding and enabling complex conversations that enable expertise to be mobilized to address interfaces rather than becoming overly prescriptive processes.

Emergent Complexity and Uncertainty
Complexity and uncertainty become particularly challenging when systems integrators coordinate different trajectories of uneven and dynamically changing developments (Sapolsky, 2003) during various phases of delivery-from the project start, to designing deliverables, building them, and testing them through project close. Processes need to be adaptive and flexible to address emergent complexity and uncertainty across these phases and the associated boundaries. Projects are organizations that face challenges of interdependent subunits and time-dependent decisionmaking (Perrow, 2011). Within a project, practitioners sense that they have a short amount of time to change the future (Vaagaasar et al., 2020), with a multiplicity of timelines associated with the development of different components and subsystems. While centralized decision-making enables coordination and planning, complexity and uncertainty need to be addressed at different levels, through practices that are both framed by systems integration structures such as interfaces, buffers, roles, and responsibilities and those that engage in systems integration activities such as cooperation and questioning.
Recent work recognizes that organizing is inherently challenging, and that complex systems have dynamically emergent properties understood through abstract analyses and lived experience (Tsoukas & Dooley, 2011), with nonlinear behaviors in which "small changes can produce large effects and vice versa" (Anderson & Meyer, 2016, p. 128). Approaching systems integration as a phase or as a specialist engineering function focuses attention on the complexity intrinsic to the project, which grows with increases in the number of components and interfaces. Approaching systems integration as a project-level or program level function also focuses attention on the technological and market uncertainties faced by the project. To address complexity and uncertainty, a process view of systems integration draws attention to how deliverables will be integrated across organizational boundaries, how design changes and assurance will be managed, and how integrity will be achieved. Achieving this requires the processual and temporally unfolding nature of systems integration be considered in the setup of project organization and project delivery models, with careful consideration of how roles and responsibilities are set out as the project builds organizations and technologies to deliver outcomes. Table 2 describes how complexity and uncertainty emerge across technological and organizational boundaries. Shenhar and Dvir (2007) describe complexity as residing in the product and the task. Brady and Davies (2014) describe uncertainty in projects arising in relation to the market and technology, with Shenhar and Dvir (2007) relating market to project goals and technology to tasks. We indicate where we see systems integration structures such as interfaces, buffers, roles, and responsibilities, and activities such as cooperation and questioning as particularly useful in addressing emerging complexity and uncertainty. We also recognize that there are evolving understandings of project complexity and its relationship with uncertainty (Bakhshi et al., 2016) see these as aspects that need to be addressed together.

Addressing Emergent Complexity
Systems integration activities are used to address emergent complexity, which arises in technical work and in the supply Relational and client complexity, managed by roles and responsibilities Market or goal uncertainty, managed by questioning chain and in the external relationships of the project including those with the client. In this section, we discuss how systems integration structures such as interfaces, buffers, roles, and responsibilities, address emerging complexity.

Managing Emergent Technological Complexity
As deliverables are often one-off or bespoke in complex interorganizational projects, the architecture of the system and its interfaces are developed across the levels: subsystems, systems, system of systems and operational systems. Knowledge of both product architecture and the organization become important to the decomposition of systems, their modularity across firm boundaries, and systems integration (Tee, 2019). Modular architectures seek to manage this complexity by reducing interdependencies across subsystems (Baldwin & Clark, 2000;Schilling, 2000;Tee, 2019). The architecture of the project organization mirrors the architecture of systems, and the system reflects the organization (Colfer & Baldwin, 2016). The organizational structure and relationships on a project reflect the technical patterns of dependency in the paths performed. This creates interfaces and buffers around which there are decisions for the operator in designing the project delivery model to achieve verification and validation from the single subsystem to the systems-of-systems. Whereas the product breakdown structure is a simple technique used to delineate product or system components and deliverables, the work breakdown structure decomposes the project into manageable pieces of work (Morris, 2013). Yet, while a hierarchical breakdown is efficient as a form or organization for decision-making, such architectures enable near decomposability of complex systems (where intra-component linkages are greater than inter-component links; Simon, 2019), and complex systems and organizations cannot be fully represented as a hierarchy. Hence a product breakdown structure provides a static snapshot of complexity-both through a hierarchy and through the cross-cutting systems that need to be managed-and can provide a baseline, against which larger changes with many systemic effects can be managed. There still needs to be clear ownership of interfaces in complex systems. Modularity is an increasingly important way of simplifying the systems integration process and achieving "economies of repetition" (Davies & Brady, 2000, p. 932) by performing standardized, reliable, and efficient tasks in large interorganizational projects. For example, the Small Modular Reactor program in the United Kingdom aims to deliver nuclear power through smaller repeatable projects (Locatelli et al., 2014). Modularity is an efficient strategy that may add to the certainty of delivery by leveraging prior experience in an exploratory or novel vanguard project (Brady & Davies, 2014). It requires detailed attention to interfaces to understand the traceability of requirements through the different levels of complex interorganizational projects. Risks may arise where there is the possibility of common-mode failures; this occurs when a system or process is connected to others, thus its failure can cause seemingly these unconnected systems or processes to fail unexpectedly at the same time (examples are given by Perrow, 2011). Where emergent properties become important and interconnections are associated with risks that need to be managed, a modular product architecture is not a substitute for the process of systems integration (Tee, 2019). In a study of Heathrow Terminal 5, Tee, Davies, et al. (2019) find that a complex interorganizational project may involve both modular product architectures and integrating practices.

Managing Emergent Organizational Complexity
With a distributed set of systems integration actors and activities, there is the potential for systemic failure, where delivery models normalize poor practice with a lack of clarity of roles and responsibilities, leading to inadequate overview of the delivered system. This happened in construction following a refurbishment project, which resulted in a major fire at Grenfell Tower, a residential tower block in London. In addition to the investigation, there was also a broader regulatory review (Hackitt, 2018) advocating systemic change, with a stronger understanding of roles and responsibilities and a "golden thread of information" (Hackitt, 2018, p. 14) to provide consistency across such projects. Therefore, the project delivery model requires clearly defined responsibilities for managing interfaces and buffers in systems integration and roles of subsystems integrators, systems integrators, metasystems integrators, and owners at different levels. In each case, the systems integrator engages with suppliers in conversations about R&D and innovation (Melander et al., 2014), and how to integrate deliverables into use. While the clarity of these roles and the responsibilities is essential, the expertise to take on the roles may be project specific and dependent on the degree of complexity and whether it is well known and understood. For example, systems integration was successfully treated as a cross-cutting engineering function on the Atlas Project, with systems integration and project management responsibilities colocated but performed separately by two distinct organizations (Davies, 2017, pp. 46-48). Systems integration was the responsibility of Ramo-Wooldridge, with a focus on technical advice and technical direction, whereas project management, with concerns for military objectives and contractual control, was undertaken by the Western Development Division (Hughes, 1998, pp. 116-124) that had a wider remit including concerns such as budgets, deadlines, and scope. The question that arises in such organizing, where Western Development Division managed the work of Ramo-Wooldridge as part of their wider remit, is the organizational boundary between project management and systems integration, and the management of organizational and temporal complexity and uncertainty. Hughes (1998) describes how the diffusion of ideas from the significant mid-20th century projects, which delivered relatively closed systems, exasperated the problems on the Boston Big Dig infrastructure project. This latter project needed a different organizational setup and a closer connection between technical systems integration and integration with end users, as it was delivering a more organizationally complex open system that included multiple and diverse social, political, and environmental stakeholders. In such projects, the integration of the technical architecture cannot be managed through technical processes alone, as separation from management, governance, and politics becomes difficult. A more devolved structure, which enables systems integrators at different levels to interact and coordinate, changes the view of overarching frameworks from prescribing practice, to framing and assuring work (McChrystal et al., 2015).

Addressing Emergent Uncertainty
Systems integration activities are used to address emergent uncertainty, which arises through unforeseeable events with unpredictable consequences (Lenfle & Loch, 2010). The actual practices of systems integration matter, with Van Der Meer et al. (2015) finding the need for guidance for collaborative decision-making as well as the allocation of responsibilities. Collaboration across boundaries requires both coordination (the ability to collaborate) and cooperation (the motivation to do so; Tee, 2019;Tee, Davies, et al., 2019). To manage the uncertainties requires managing in time, through cooperation as well as coordination and through questioning as well as optimization.

Managing Emergent Technological Uncertainty
Cooperation is important to managing complexity and uncertainty in the flexible and adaptive processes of systems integration. In contrast with technical coordination, the role of cooperation in systems integration was explored in Sayles and Chandler's (1971) study of the Apollo Program (also discussed in Söderlund, 2012). Building on Lawrence and Lorsch (1967), Sayles and Chandler identify the systems integrator as a distinctive form of organization and systems integration as a key task, describing the intermediaries' roles required to translate across specializations (Sayles & Chandler, 1971, p. 236). Sayles and Chandler draw attention to how such integration challenges arise across the boundaries of the project, as the evolving context of the project requires cooperation among a wide range of different organizations, including government, firms, and non-government organizations. In a dynamically changing environment the systems integrator cannot assume that all the ill-defined interfaces-or boundaries between subsystems-have been identified up front. Using persuasion and bargaining-rather than confrontation and control-the systems integrator must engage in a continuous interaction with organizations responsible for subsystem development to make any technical problems or ill-defined interfaces visible and work collaboratively to develop solutions to overcome them (Sayles & Chandler, 1971, p. 236).

Managing Emergent Organizational Uncertainty
Across an interorganizational project, subcultures may have different understandings of tasks (van Marrewijk et al., 2016). Cooperation is important in bridging organizational and cultural boundaries to achieve systems integration, given the diverse incentives and organizational cultures that arise across the boundaries between subsystems in interorganizational projects. There may be different ways to organize integration. Relationship quality (Hanisch & Wald, 2014) may substitute here for formal coordination mechanisms, hence there are a range of emerging flexible and adaptive project delivery approaches that seek to address systems integration challenges through fostering cooperation. These approaches include the implementation of systems emergency wards (Berggren et al., 2008) that bring teams together daily to discuss integration and report defects, thus signaling the management attention given to systems integration. In such approaches, flexibility and adaptability are used to increasingly focus on and bring expertise to bear on the interfaces.
We thus also recognize that complexity and uncertainty require a questioning approach to the process of systems integration. Klein and Meckling (1958) extend understanding beyond a static understanding of the physical components and knowledge toward a more adaptive and processual understanding. They do this by recognizing in their study of weapons systems projects that knowledge of the component parts of a system may develop unevenly and small adjustments have to be made to integrate components that are "out of phase" with others into a whole (discussed in Brady et al., 2012). While they characterize the optimizer as seeking to rely on careful upfront planning, with rational and formal approaches to selecting optimal approaches, Klein and Meckling (1958) argue that a more adaptive (bounded rationality) approach may be required to address emergent uncertainties, with a skeptic characterized as engaged in ongoing questioning and adaptation throughout delivery. Such work points to the need for "disciplined flexibility" (Sapolsky, 1972, p. 250) as some components or subsystems in complex projects may be technologically stable, whereas others are uncertain and require further development and adjustment prior to their integration.

Implications
This article suggests that future research on systems integration needs to move beyond thinking about systems integration as distinct technological (engineering) or organizational (management) tasks. A new perspective is required to address both the technological and organizational aspects of systems integration as a process. Systems integration capabilities are needed to coordinate stable components and disciplines at a specific point in time and manage several trajectories of uneven and dynamically changing developments over time (Sapolsky, 2003). In the next section, we discuss the implications for firms involved in projects and for project setup and delivery models.

Implications for Firms Involved in Projects
Reframing systems integration in interorganizational projects as a flexible and adaptive process of making constituent parts of systems work together has implications for firms involved in projects. While research has extended understanding of systems integration capabilities in firms (Hobday et al., 2005;Prencipe, 2003), in interorganizational projects the process of systems integration is distributed among different parties, with structures and activities involving participating firms, but also potentially public-sector project sponsors or the project delivery client. In taking the complex interorganizational project rather than the firm as a unit of analysis, the framing differs from work that frames systems integration as a task performed by a firm (e.g., Davies et al., 2007;Hobday et al., 2005), with questions of systems integration associated with that firm's make or buy decisions (Brusoni et al., 2001).
This reframing leads to a more pluralistic and distributed understanding of systems integration structures and activities. The distribution of responsibilities may be limited, where one organization takes primary responsibility for crossorganizational integration and supplier participation is motivated by the potential for future collaborations (Ahola et al., 2017(Ahola et al., , p. 1006, although the outsourcing of responsibility for systems integration to a single firm may be an expensive option (Ceci et al., 2014;Oliveira & Lumineau, 2017). Alternatively, outsourcing may be more extensive, with different parties taking on responsibility for systems integrator activities at different stages of the process. The responsible government agency, client, or eventual owner responsible for a complex interorganizational project faces the challenge of knowing how much systems integration capability to develop in-house for the duration of the project and how much to share capability development with a delivery partner or contractor (Davies & Mackenzie, 2014).

Implications for Project Setup and Delivery Models
Our work reframing systems integration suggests that project setup and delivery models need to consider and shape the structures and activities of systems integration. Fiedler and Wendler (2016) attribute the failure to integrate systems in Brandenburg Airport to the lack of a comprehensive project governance framework designed to hold managers accountable for ensuring expertise on all levels and appropriate assurance. Thus project setup and delivery models, including assigning responsibility for systems integration to a focal organization, need to account for and manage the emergent technological and organizational complexity and uncertainty.
Systems integration is the critical capability because of the need to understand the whole system, including the interfaces among its component parts; coordinate a large network of component suppliers; and preside over the various stages of system development. Although a delivery model is defined at the project level, many systems integrators are often responsible for large, complex projects that form part of a program of interrelated projects for clients, such as ongoing expansion of an airport including a new baggage handling system, terminal buildings, and other facilities. The challenge facing the program-level systems integrator and client is how to improve overall performance of the program over time. Understanding how delivery models at the project and program levels interact with a client's overall business model is likely to be a promising avenue for future research.

Conclusions and Directions for Research
We offer a new perspective on projects that reframes systems integration as a flexible and adaptive process with distinctive focus on the systems that projects deliver, addressing emerging complexity and uncertainty within and across boundaries in interorganizational projects. By defining the concept of systems integration-with its distinct focus on the systems that projects deliver-we make a novel contribution to work on integration in project organizing, which has previously focused on delivery rather than deliverables. These are not the same, as a project may be organizationally complex and use integration to manage this in delivery without adequately considering the integration of the systems that are delivered. Systems integration processes require attention to the organization of delivery and also the delivered system and contexts-of-use.
This reframing shifts our understanding from a narrow, technical view, which still underpins the four perspectives in the existing literature, to a wider processual understanding of systems integration. This new perspective is required to address the many examples of the failure to integrate systems that have led to significant delays and cost over-runs, such as in the Crossrail example, described in the introduction. Projects are organizations that face challenges of interdependent subunits and time-dependent decision-making (Perrow, 2011). The number of interfaces to be managed, degree of project complexity, and the level of technological and market uncertainty will shape, and be shaped by, the approach to systems integration (Brady & Davies, 2014;Shenhar & Dvir, 2007). Systems integration focuses attention on the different organizational vehicles established to manage across boundaries and levels. Central decision-making allows for coordinating work and for planning to integrate systems; yet at the same time, complexity and uncertainty are addressed at different levels through practices that are both framed by systems integration structures such as interfaces, buffers, roles, and responsibilities, and engage in systems integration activities such as cooperation, questioning, future making, and managing change. Where boundaries are known, firms may, but do not always, take on the role of one of the systems integrator.
Theorizing on systems integration has the potential to shape debates about project-based organizing. By making the case for systems integration as a theoretical way of addressing emerging complexity and uncertainty, we suggest a new trajectory of research that will evidence and test this proposition in the context of interorganizational projects. We reframe systems integration as a flexible and adaptive process across and within technological and organizational boundaries, providing new ways to theorize and address emerging complexity and uncertainty within projects. Questions of project governance, as well as project management, arise as the need for systems integration pervades all aspects of project setup, from the product and work breakdown structures and the approach to procurement and monitoring and assurance of completed work. Our theorizing has the potential to shape and inform emerging research areas and themes, for example, on everyday project practices, digital delivery, materiality, and temporality.
Research on systems integration and project organizing may generate new insights into how systems integration activities are, and should be, distributed, across levels and across stages, in project delivery. Moving down from the program and project levels, this takes project scholars beyond the concerns of management and managers (Geraldi & Söderlund, 2018) to examine the everyday practices of coordination and cooperation through which collaboration is achieved across complex interorganizational projects. There is much extant work in this rich area for practice research but also opportunities to extend this to understand how collaboration in the present relates to the systems that projects deliver in the future. Such work can extend understanding of how and when systems integration takes place, the potential areas of flexibility, capabilities to achieve integration, their location institutionally, and also behavioral questions regarding personal capacity and accountability. Further theorizing on systems integration practices is timely and important as there is growing complexity in the complex products and systems-such as aircraft, experimental facilities, and railways that are delivered through interorganizational projects-and growing concerns about their resource use and interactions with natural environments.
Digital information has become a project deliverable, changing the supply-base interactions and relationships with owners, operators, and end users (Whyte, 2019). Digital information is also creating new forms of interdependence (e.g., Kache & Seuring, 2017). New forms of systems integration may be needed to address the emerging forms of organizing associated, for example, with the sharing economy and distributed ledgers and increased legal, ethical, and transparency requirements on projects. Activities within complex interorganizational projects may blend entirely different approaches to working, with different understandings of time and interconnections. Although these topics are not fully addressed in this article, there are opportunities for researchers to extend our theorizing to advance understanding of how systems integration is enacted through new digital forms of project organizing, and how digital information becomes embedded in project deliverables, as project deliverables become cyber-physical systems.
Materiality matters. Rather than assuming that systems integration is confined to the firm as a unit of analysis, the focus on systems integration in projects brings the open systems that they deliver into view. A variety of systems integrators and systems integration activities may be located across a complex landscape of actors. This raises new questions about the decomposition of systems and their modularity across firm boundaries. Interorganizational projects are a significant part of the industry structures in many project-based industries, along with firms and public sector clients, such as those delivering infrastructure megaprojects. Their deliverables are consequential. Reframing systems integration to provide a new perspective of projects provides opportunities for scholars to examine how projects deliver and implement large systems. In so doing, there are new opportunities to articulate how largescale technical systems delivered through interorganizational projects are transformative for societies. They are becoming more complex as they become cyber-physical in nature, and their impact is important at a time of a global climate emergency and the COVID-19 pandemic. The notion of systems integration brings the material nature of technology back in, enabling theorizing about the inseparable technical and organizational aspects of how integration of the systems that projects deliver is accomplished and drawing attention to the complexities and uncertainties that arise in relation to the systems that projects deliver.
Time is important to our understanding of systems integration. We propose a process view of systems integration, linking to work on coordination trajectories and temporality. This suggests new areas of work on the dynamics of systems integration and the impact of urgency and pace. Temporal boundaries emerge with different understandings of time and orientations to pasts, presents, and futures (Stjerne et al., 2019;Whyte & Nussbaum, 2020), with different futures envisioned as technologies are evolving and different generations of technologies need to be integrated or as different future contexts of use need to be accommodated. We anticipate there is work that can build on systems integration as a process. We need to better understand how emergent events require adaptation and engage and how projects are organized to address issues such as temporal boundary spanning, knowledge, and knowing and evolving cultures of coordination within complex interorganizational projects and across their boundaries. We also need better understanding of the adaptation and flexibility needed for today's complex, dynamically changing, and uncertain projects to deliver societally important systems and outcomes.