Aligning and Reconciling: Building project capabilities for digital delivery

Digital delivery of complex projects, using integrated software and processes, is an important emerging phenomenon as it transforms relationships across the associated ecology of project-based ﬁrms. Our study analyses how a project-based ﬁrm, ‘Global Engineering’, builds new project capabilities for digital delivery through work on three major road and railway infrastructure projects. We ﬁnd that it seeks to: (1) align the project set-up with the ﬁrm’s existing capabilities; and (2) reconcile differing agendas and capa- bilities in collaborating ﬁrms across the project ecology. Here, aligning involves inﬂuencing the set-up of digital delivery and renegotiating that set-up during project implementation; and reconciling involves managing across multiple digital systems; accommodating and learning other ﬁrms’ software and processes; and using digital technologies to create shared identity across the ﬁrms involved in delivery. We argue that creating relative stability enables ﬁrms to use existing, and build new, project capabilities, and hence aligning and reconciling are important to project-based ﬁrms in environments where there is high interdependence across heterogeneous ﬁrms and rapid technological change. We ﬁnd that building these capabilities involves both ‘economies of repetition’ and ‘economies of recombination’; the former enabling the ﬁrm to capture value by mobilizing existing resources and the latter, requiring additional work to re-combine existing and new resources. Our study thus provides insight into how project-based ﬁrms build project capabilities for the digital delivery of complex projects in order to remain competitive in their existing markets, and has broader implications for learning in the project ecologies associated with these projects.


Introduction
Road and rail infrastructure, off-shore platforms, nuclear power stations and commercial or military aircraft are delivered through complex projects. This delivery is a significant challenge, as these projects involve work across a project ecology involving heterogeneous firms with differing skills and practices (Miller and Lessard, 2000;Scott et al., 2011). The introduction of integrated software and processes into this delivery is an emerging phenomenon, which alters the nature of a project-based firm's work and its relations with other firms in the project ecology. New generations of software bring previously separate activities together (D'Adderio, 2001(D'Adderio, , 2003, automating workflows and creating new forms of interdependence. They are enabling new forms of project delivery across project-based industries (Levitt, 2011;Whyte and Levitt, 2011); transforming innovation processes (Dodgson et al., 2002(Dodgson et al., , 2005Brynjolfsson and McAfee, 2014) and propagating innovation across the firms involved in the digital delivery of projects (Boland et al., 2007).
In the set-up and implementation of complex projects, we define 'digital delivery' as the use of integrated software and processes across the project ecology, where 'integrated software' is an interconnected set of applications giving access to a shared dataset through a single user interface and delivery involves design, coordination, project management, and governance. Digital delivery is thus not only the local use of software in specific project tasks, but also the more consequential integration across the firms in the project ecology. Research suggests that within firms, using integrated software provides most benefit where there are mature integrative processes (D'Adderio, 2001), and processes that are initially chaotic may later mature, becoming repeatable, defined and managed (Paulk et al., 1993). In complex projects, integrated software brings together computer-aided design tools, extranets, document management tools, schedules and dashboard displays; and is associated with integrated processes that are partially embedded within the software in standard workflows and approval processes. A knowledge-based perspective on the firm focuses on capabilities, competence and learning as sources of competitive advantage (Grant, 1996a,b). For project-based firms, it is project capabilities that are central to competitive advantage (Davies and Brady, 2000;Brady and Davies, 2004;Davies and Hobday, 2006). The literature on 'project capabilities' suggests that project-based firms build project capabilities, where these are the capabilities of the firm to engage in the delivery of projects (Davies and Brady, 2000: 932). Strongly associated with competence and learning, project capabilities are: "the specific knowledge and experience required to engage with internal or external customers, develop bids or offers, and set up and implement projects" Davies, 2004: p. 1602, also see Davies and Brady, 2000). Some capabilities the firm owns, others it controls or has access to via other firms (Helfat et al., 2007). Thus, within the ecology of permanent organizations that are involved in complex projects (Winch, 2014), capabilities are 'co-created' across the project and the firm (Söderlund, 2005); the firm builds these capabilities by engaging with projects, repeating activities and using existing knowledge, while also exploring new areas and developing new knowledge (Söderlund et al., 2008). While research has articulated how firms build new project capabilities to explore new markets (Brady and Davies, 2004), it is more limited in explaining how firms build capabilities to compete in their existing markets as these are transformed by the emerging phenomenon of the digital delivery of complex projects.
This paper draws on an empirical study of a project-based firm, 'Global Engineering', and its learning through three major road and railway infrastructure projects in which new methods for digital delivery were developed. We approach explaining the emerging phenomenon of the project-based firm's involvement in digital delivery of complex projects through the project capabilities lens. Hence, the paper addresses the question: How do project-based firms build project capabilities for the digital delivery of complex projects? The challenge is that digital delivery of complex projects involves rapid technological change and increases interdependence across heterogeneous firms in the project ecology.
Our study contributes by providing insight into how projectbased firms build project capabilities for the digital delivery of complex projects in order to remain competitive in their existing markets, and has broader implications for learning in the project ecologies associated with these projects. The next section discusses the background and prior research. The research design and methods of the study are then described in the following section. Section 4 gives an overview of the empirical case, giving the timeline of Global Engineering's work on the projects 'Railway', 'Highway' and 'Motorway'; an overview of Global Engineering's work within the ecology of firms associated with each of the three projects; and how it built project capabilities for digital delivery. Section 5 shows how our data suggests that, in working on these projects, Global Engineering sought to: (1) align the project set-up with the firm's existing capabilities; and (2) reconcile differing agendas and capabilities in collaborating firms. In Section 6 we argue aligning and reconciling are important to project-based firms in environments where there is high interdependence across heterogeneous firms and rapid technological change to create the relative stability needed to use existing, and build new, project capabilities. Section 7 draws conclusions and discusses theoretical implications for research on project capabilities; as well as practical implications of this empirical work.

Background
We define project capabilities for digital delivery, in set-up and implementation, as the specific knowledge and experience required by the project-based firm to deliver complex projects dig-itally. Such capabilities are at the operational level (Davies and Brady, 2016) and therefore especially important in the often uncertain environments of complex projects. Where they are lacking it can be costly. For example, the delays in delivering the Airbus A380 were due to a lack of integrated software and processes, with German engineers using an earlier software system than the French, reducing the parent firm's earnings by D 2 billion over four years (Clark, 2006). In contrast, in the case study of the B-2 'Stealth' bomber, which was digitally designed by four firms, these firms benefited from project capabilities for digital delivery, as digital design data aided coordination by reducing information processing costs and, along with the conventions of a 'technical grammar', also made governance of the project more efficient (Argyres, 1999).
Project capabilities for digital delivery include broad skills in using information and communication technologies, in particular in using digital systems, which combine digital technologies (computer hardware, software and networks). Capabilities in software and processes are particularly important as current software does not fully integrate all the activities across the project ecology, but rather may create new boundaries between the project and the firm (Yeow, 2014). Integrated software, as the set of applications that give access to a shared dataset through a single user interface, is challenging to achieve and on many projects may be partially implemented. Whyte and Levitt (2011: 367) note that: "Though the benefits of an integrated dataset are widely championed and claimed, such shared development, checking, and use of information is not straightforwardly achieved on projects." Firms need capabilities to use integrated software and processes in their project-based design, coordination, management and governance activities, where Adriaanse et al. (2010) observe that, in construction projects, professionals often do not use integrated software as intended; and Arnold and Javernick-Will (2013) find there is still substantial manual data re-entry as different software is used across the project ecology. Thus one of the most challenging aspects for firms involved in the delivery of complex projects is "establishing processes to maintain stability whilst responding dynamically to uncertain and changing conditions" (Davies and Mackenzie, 2014: 773).
Prior research has examined the use of integrated software for knowledge management within project-based firms (Newell et al., 2006;Criscuolo et al., 2007;Cacciatori, 2008). Research has also considered the role of software in design, where scholars have studied practices of designers and engineers (Bucciarelli, 1994;Ewenstein and Whyte, 2009) and the difficulties they face in working with digital databases (Henderson, 1991(Henderson, , 1999. There have been studies on coordination, where recent work examines model use (Dossick and Neff, 2010) and how digital objects facilitate negotiation across boundaries (Alin et al., 2013); and work has been done on project management, where research examines project management information systems (Braglia and Frosolini, 2014) and digital approval processes (Whyte and Lobo, 2010). Recent work highlights the challenge of governance, the project framework or approach that sets out accountabilities, permissions and responsibilities for digital delivery (Arnold and Javernick-Will, 2013). Research by D'Adderio (2001) highlights how firms in manufacturing need to develop the ability to use integrated software to support interfunctional cooperation and coordination of knowledge across the firm and its supply chain. In our setting, integrated software and processes are increasingly used in complex projects and their associated ecologies of firms.
The use of integrated software and processes is shifting across the different, overlapping, generations of digital delivery (Whyte and Levitt, 2011). In the early days of project management, large main-frame computers were used to calculate schedules (Morris, 1997). With the first personal computers becoming available in the 1980s, knowledge formalization on projects became possible through basic CAD, project management and simulation software. Since the 1990s, computers linked to the internet have enabled better sharing of information and knowledge across teams and firms using visual decision-making and shared workspaces. As mobile computing, data storage and applications became widespread in the 2000s, automated digital search, expert systems and project extranets enabled more agile decentralized methods around centralized data. By the 2010s we have entered an era of cloud computing, mobile devices and 'big data', in which the volume, velocity and variety of data generated on complex projects is again transforming their delivery (Whyte et al., 2016). Project clients are beginning to specify digital data as an output of projects, alongside the complex physical product, to enable longer-term uses of digital data in product life-cycle management (Garetti et al., 2005). In this context, the project-based firm needs to use existing project capabilities for the current generation of digital delivery and to build new project capabilities for next-generation digital delivery.
We know relatively little about how the project-based firm builds project capabilities to compete in its existing markets, as these are transformed through such rapid technological change. In the literature on capabilities, replication involves repeating a successful practice to achieve the firm's objectives (Szulanski, 1996;Winter and Szulanski, 2001;Davies et al., 2010) where this move involves two stages of learning: exploration and exploitation. In building the project capabilities to enter new markets, Brady and Davies (2004) describe the firm taking advantage of economies of repetition by becoming able to execute repeat projects increasingly efficiently. A move from 'exploration' to 'exploitation' mode thus occurs across different learning phases: a 'project-led' phase, when a firm moves into a new technology or market base; an exploratory 'vanguard project' phase; a 'project-to-project' phase of capturing lessons learnt; and a 'project-to-organization' phase when the firm increases its capabilities to deliver many projects. When 'top-down' strategic decisions are taken to create and exploit the companywide resources and capabilities required to perform increasingly predictable and routine project activities, 'business-led' learning (within which the project-led learning is embedded) occurs (Brady and Davies, 2004), improving the firm's effectiveness (Zollo and Winter, 2002).
Through work on complex projects, the project-based firm builds project capabilities at the interface between the firm and the project, within a project ecology (as shown in Fig. 1b). Because each project is a one-off, it may be hard to achieve economies of repetition. Research suggests that, in some contexts, project-based firms may rely on 'economies of recombination' (Grabher, 2002;Manning and Sydow, 2011), more than the economies of repetition referred to by Brady and Davies (2004), where these economies of recombination are generated from established (Kogut and Zander, 1992) and new creative resources. Economies of recombination provide an approach to balancing a need for both one-off solutions and learning reuse through recombining "modules" of technologies, knowledge and lessons from previous projects in novel ways (Grabher and Ibert, 2011). There may also be instances where neither such economies are possible. The majority of work in project-based firms occurs in decentralized, loosely-coupled project teams, focusing on the completion of tasks and deliverables to deadlines (Lindkvist, 2004) rather than on capturing, documenting and disseminating project learning. A failure to learn is costly: scholars have described firms 're-inventing the wheel' (Newell et al., 2006) and repeating mistakes (Prencipe and Tell, 2001) across projects. To be effective the project-based firm has to coordinate its work with other firms in the ecology of the complex project, over different generations of technologies retaining: "the technological knowledge to accommodate changes in one field that may have cascade effects on others" (Brusoni et al., 2001).
When capabilities are built by extending, modifying or creating new capabilities (Helfat et al., 2007) and acquired over time under conditions of change, they are regarded as dynamic capabilities (Amit and Zott, 2001). In fact, there is: "a broad consensus in the literature [. . .] that dynamic capabilities contrast with ordinary (or, operational) capabilities by being concerned with change" (Winter, 2003: 992). Thus, the firm's capabilities need to be dynamic if the firm is to prosper in rapidly changing environments (Teece et al., 1997;Eisenhardt and Martin, 2000), with the firm building dynamic capabilities to continuously pursue competitive advantage, changing the fit between internal and external environment (e.g. Helfat et al., 2007). Projects provide opportunities to build new project capabilities in ecologies of firms, with Newell and Edelman (2008) highlighting the role of dynamic capabilities in this context. Where dynamic capabilities are closely associated with learning (Zollo and Winter, 2002); firms need a systematic capacity to sense and seize new opportunities and to transform themselves accordingly (Teece, 2007); and work on projects, which is often distributed, can be operationally challenging and thus an important source of knowledge and experience for the project-based firm (Manning et al., 2013).

Research design
This study is designed as an embedded case study (Eisenhardt, 1989;Yin, 1994;Stake, 1995;Eisenhardt and Graebner, 2007), with three sub-units of analysis, focused on learning at the interface between the project-based firm 'Global Engineering' and complex engineering projects. Global Engineering is an appropriate research setting for examining project capabilities for digital delivery, as it has a reputation for innovative work on complex projects and a dedicated central team responsible for ensuring best practice in digital delivery. The three projects, described here as 'Highway', 'Railway' and 'Motorway', were identified by managers in this central team as meeting our criteria of pioneering the use of digital delivery and having an impact on later work within Global Engineering. The initial aim was to investigate: (a) digital delivery on projects; (b) lessons learnt about digital delivery on these projects; and (c) transfer of lessons across Global Engineering and onto other projects.
Our study started by examining the interface with Highway, and then considered the earlier work on Railway, from which learning was transferred to Highway and Motorway. This focus on learning at the interface between a single firm and three projects allows for in-depth analysis and substantive theory building, while also enabling us to draw insights across the three projects. We set out to study digital delivery in design, coordination and project management, but early feedback from the firm led us to include governance. These areas of digital delivery were included in the research protocols to focus our data collection. The relationship with the firm was sustained through monthly update meetings throughout the data collection and analysis phases, providing an opportunity for discussion of emergent findings and interpretations.

Data collection
Data collected from the firm and its work on these three projects combines documentation, pre-interview questionnaires and semistructured interviews, access to Global Engineering's intranet, meetings and visits as summarized in Table 1. The main data was collected in 2008-9. Following a project set-up meeting, an associate director working in the central team championed our research proposal, confirming which projects were pioneering digital delivery, gaining support from project directors, and arranging set-up meetings for the data collection.
As we refined our focus, the interface between the firm and each of the projects became treated as a sub-case within the main case. For each project there was extensive interaction with relevant project personnel, who were selected for their potential to provide insight into learning about digital delivery. Thus, data collection for each project started with a 1-2 hour meeting with project technology managers, to obtain background details of the project and the role of digital technologies within it. In this meeting we were directed to internal documents and published material on the project, and the project interviewees were identified. There was a discussion with the technology manager for each project, to understand the technologies used in digital delivery on that project and to identify participants who would be able to provide insight on the use. of those technologies in delivery. Sometimes, a 'snowballing' approach was used, where one interviewee would suggest someone else who would be appropriate for our study. While individuals played different roles in the project and the firm, we sought to identify engineers who used, and managers who set up, the integrated software and processes.
In preparation for interviews, pre-interview questionnaires were sent out by email to these project participants. These ques-

Pre-Interview Questionnaires
• Pre-interview questionnaires: sent to gain background knowledge about interviews that allowed questions to be tailored to particular individual's areas of knowledge and expertise. 22 completed questionnaires were obtained. Global Engineering provided related CVs for other personnel. Interviews • Interviewee selection: Interviewees were selected as those that could provide insight into learning about digital delivery from particular projects, and influence on the project. The interviewees include project managers; senior engineers; CAD managers; interface managers; documentation and information managers, and modellers, across the range of senior positions (including directors) and more junior positions within the firm.
• Conduct: Interviews started by discussing the pre-interview questionnaire and then covered topics on digital delivery and learning, as relevant to the participant, with 8 semi-structured interviews (Highway) 7 semi-structured interviews (Railway) and 23 semi-structured interviews (Motorway). Intranet • External access to part of the corporate extranet: Direct access to archival information on the studied projects, associated people and key internal documents relating to digital delivery.
• Related industry meetings: includes attendance at an 'Information management for major projects' workshop, hosted for industry by this Associate, 21/11/2008. • Informal meetings: informal meetings and discussions with members of staff including Visualization Manager and Head of R&D; and social interaction with key contacts. Visits • Head office: The first author spent 8 h collocated at a desk in Global Engineering, observing, asking questions and using the extranet to locate key internal documents relevant to the research.
• Site office: The first author spent 3 days on a site visit to Motorway project offices and site in Australia to understand digital delivery, and learning between this project and the firm.
• Later project: The second author visited an interviewee in the project offices of a later project in North America, and discussed the learning transferred from Highway to this project.
tionnaires asked for: job title; role on the project; career history (relevant learning on other projects); length of time in construction; and experience using technologies for design, coordination, project management and governance. Detailed background data on these participants was also made available to us by the firm, so we had a good understanding of their roles in the project before collecting more focused data through interviews with them. Table 2 gives more details of the meetings and interviews associated with each sub-case across the embedded case study. Eight out of the 38 people interviewed worked on more than one project, as shown in the 'other projects' column. In the interviews, we started by asking for clarification of the data collected in the pre-interview questionnaire, to prompt the interviewee to narrate their previous project experiences and interpretations of developments over time. We then asked about the main features of digital delivery on the project, the software and processes used in their role, and what learning had been transferred to the project from previous projects and from the project to later projects. Key questions in the protocol were thus designed to prompt conversation around the two main topics of digital delivery and learning. Questions included: What were the key features of IT use on the project? What tools and technologies did you use? What did you learn from other projects that you used on this one? What did you learn from this project that you will use on subsequent projects?
Both authors were involved in all the set-up and feedback meetings across the three projects and in all the interviews for Railway and Highway. As Motorway was located on another continent, the first set of interviews with participants on this project was con-ducted remotely by telephone. This was not found to be effective: many of these telephone interviews were shorter as the time zone difference meant they were scheduled at the end of the interviewees' day and outside our normal office hours. We did not feel we had reached 'theoretical saturation' (Glaser and Strauss, 1967), so the first author visited the Motorway project offices and site, collecting a second round of data in person.

Data analysis
The data analysis used established methodologies for theory building from case study research. We worked backwards and forwards between the data and emerging theory, gaining deep familiarity with the data to generate new insights through a process of constant comparison (Glaser and Strauss, 1967;Klag and Langley, 2013). While this work of moving from data to theory is iterative, we present our analysis in sequential steps: Step 1. Within each sub-case, focused on the interface of the Global Engineering firm with Railway, Motorway and Highway, the first step in our analysis involved tabulating and organizing interview transcripts, documents, our notes from visits and other sources of data into themes, and creating a timeline of key events within the project, the firm, and related projects. This 'within case' analysis drew on the tradition of case study research using process approaches to analysis by developing a chronology as a first step (Langley, 1999). We used the chronology to situate interpretations in context (Pettigrew, 1985), guided by the research question and associated conceptual categories in the protocol, but sensitive to emergent categories and connections. We organized the data into: (1) project overview; (2) digital tools and their selection; (3) benefits and challenges of IT strategy on the project; and (4) Global Engineering's learning at the interface with the projects. The first author led this analysis of the sub-cases and based on these analyses, wrote each 10-12 page 'within case' report that summarized the findings and built an initial explanation for them.
Step 2. Following analysis of the three embedded sub-cases, attention shifted to the main case -building capabilities for digital delivery in Global Engineering -through 'across case' analysis of the three sub-cases and considering the role of Global Engineering's central team in promoting best practice for digital delivery. Findings regarding Global Engineering's work on the different projects were tabulated, compared and contrasted. Timelines for the three projects were put together to highlight the key events for Global Engineering. Explanations were sought for the similarities and differences in the use of digital delivery and Global Engineering's learning across the Railway, Highway and Motorway projects. The first author led this case study analysis, with both authors meeting regularly to discuss findings and interpretations. It was summarized in a 12-page final report, which discussed the findings in relation to the research aim and objectives.
Step 3. Having gained familiarity with the sub-cases and the overall case, both authors revisited the entire data set with an initial focus on learning about digital delivery across the firm-project interface. This coding used pre-established codes from the research protocol and also sought to identify new ones from the data (Stake, 1995). We identified and categorized examples of learning about digital delivery across the firm-project interface; and examples of associated issues (e.g. lack of expected learning). At this stage in the analysis, we looked for themes across the 38 interviews, without particular concern for which sub-cases interviews came from. We labelled textual expressions in each interview transcript with descriptive phrases, then grouped these into first-order codes. Examples of first-order codes include 'negotiating working practice where not contractual' and 'using software developed in a collaborating firm'. Both authors were involved in this coding process, working independently and meeting to discuss interpretations, clarify definitions of constructs and agree a shared coding. We used extant literature to evaluate the significance of different themes in the data set and to clarify our constructs. Together we established links among first-order codes and conducted axial coding to group these codes into second-order codes. Thus we follow Eisenhardt (1989) both in categorizing, sorting and interpreting data to develop theoretical insight; and in iteratively comparing our emerging constructs with the extant literature. This coding process focused our attention away from what was learnt and what technologies were used, to how Global Engineering builds project capabilities for digital delivery.
Step 4. We revisited each of the embedded sub-cases and the overall case, using the second-order codes. In developing theory from the embedded case study, we thus compared "the emergent frame with the evidence from each case in order to assess how well or poorly it fits with case data" (Eisenhardt, 1989: p. 541). At this stage we worked iteratively across the coding and our account of the case, to clarify and refine the fit between case data and theory; we also wrote new text about the sub-cases and the overall case, a process that was further informed by feedback in the review process as we developed the paper.

Scope, limitations, and data validity
Member checks, and the sub-case and case study reports, were used to challenge preliminary interpretations and strengthen the reliability of our analyses, thus enhancing the internal and external validity of the research. Interview summaries were sent back to participants for them to check key information (Lincoln and Guba, 1985). In the first step of data analysis, each sub-case report was circulated to and discussed with the Global Engineering project team and the central team. In step 2, the final case report was discussed in a two-hour meeting with two company directors. The sub-case reports and the final case report were not unquestioningly accepted by Global Engineering engineers and managers: each came back with a set of questions and it was necessary to go back to the data to either justify or modify the claims. As we coded the data set, in step 3, we rigorously examined discrepant as well as supporting data, and where there was disconfirming evidence we discussed it and modified our codes. In step 4, we sought to ensure correspondence between the emerging theory and the case. We revisited, checked and discussed connections in academic workshops and presentations; the feedback obtained further enriched the analysis and interpretation of the data, enabling us to draw sharper distinctions. Our data is thus appropriate to building theory about project capabilities for digital delivery at the interface between Global Engineering and the Railway, Highway and Motorway projects.

Overview of the case: Global Engineering and digital delivery of complex projects
This section gives the timeline of Global Engineering's work on the Railway, Highway and Motorway projects; background information on these projects and their associated ecology of firms; and details of Global Engineering's involvement in their digital delivery. Each project had a major impact on Global Engineering's understanding of digital delivery, and became part of corporate memory. Delivering Railway provided Global Engineering with experience in using an intranet to coordinate project work and in implementing shared project controls; Highway provided experience in using an extranet for approvals, in managing the global distribution of project work internally, and in coordinating data with other firms that worked on different software; while Motorway provided experience in using remote access to servers for real-time design coordination and new uses for 3D modelling.

Timeline of Global Engineering's project work and available hardware and software
Global Engineering's work on the Railway, Highway and Motorway projects is shown on a timeline, alongside the trajectories of change in computer hardware and software, in Fig. 2. The main period of detailed engineering design work across the three projects was in the decade from 2000 to 2010, with Global Engineering appointed for detailed design on the three projects in 1996, 2000 and 2006. We therefore treat these projects as the same generation of digital delivery.
Global Engineering's engineers moved between the Railway and Highway project teams, when there were delays in the Highway project and depending on where their skills were in demand. As they worked across Railway and Highway, engineers transferred learning about the set-up and implementation of digital delivery. This transfer of learning was also facilitated by visits across projects: for example, in considering how to set up the data transfer between design and construction on Highway, an interviewee said: "one of the things I did early on was I went down to [Railway] to find out how they were issuing data to the contractor to set out with the works" (Highway, Interview 1). When Global Engineering became involved in Motorway at the detailed design phase, some engineers brought skills acquired on the Highway and Railway projects to Motorway: one of the engineers interviewed on Motorway in Australia had worked as a contractor on Railway in the UK; and engineers in the local Australian office had also worked remotely on the engineering design of Highway.
The long timescales involved in developing infrastructure contrast with the rapid change in associated hardware and software over the same period. Global Engineering project teams took on different design roles across the delivery process, such as client design advisor, sub-contractor (novated to the contractor) and specialist designer. On both Railway and Highway, they advised the client during the long feasibility phases, which on Highway included an extended period of public inquiries and appeals. These phases involved an earlier generation of digital delivery: "Because of the length of the project, if we think back to the beginning of the project, at the start email didn't exist and the internet didn't exist so therefore the systems are quite different" (Highway, Interview 1). Our research focuses on the integrated software and processes that were set up for project implementation. On each project these were seen as innovative, with, for example, 99% of deliverables computergenerated and almost no paper copies on Highway. However, this use of software and processes was not unproblematic and involved building project capabilities for digital delivery through learning in the project ecology.

Three digitally delivered projects and their associated ecology of firms
Background information on Railway, Highway and Motorway, and the ecology of firms involved in delivery is summarized in Table 3. In the delivery of each of these projects, the ecology of firms within which Global Engineering operated included joint ventures between multiple firms and interdependencies across engineering disciplines, public and private partnerships, regulators, client, construction partners, suppliers and other stakeholders.
On each of these projects, Global Engineering was one of two design firms involved in the detailed design and construction phase, with a design joint venture used to manage the variability in workloads and resources; to share liabilities and risks in the delivery of the design services; and to increase client and contractor confidence in the availability of design expertise. On Highway, one interviewee noted that Global Engineering: "could have resourced that but it would have been at the detriment of other jobs probably" (Highway, Interview 1). Collaborating on complex projects enabled Global Engineering to better manage peaks and troughs in workload across its project portfolio.
Engineers and managers aimed to embed standard project processes into integrated software to ensure compliance across the project ecology in terms of both methods and outputs. Project par- Table 3 Global Engineering's involvement in three projects (adapted from our report agreed with the firm, published documentation and meetings).

Railway
Highway Motorway Public-private partnership, design and build.

The ecology of firms involved in the project Main firms involved in delivery
Four firms, in design and project management joint venture (two design firms).
Six firms, with two design firms in design joint venture; and four contractors.
Five firms in the delivery alliance (two design firms in design joint venture).

Location of firm's project team
Collocated with teams from other firms in project offices.
Not collocated: In firm during design. Collocated with teams from other firms in project offices. Size of design teams at peak 1000 300 100 ticipants stressed the importance of working across firms to set up digital delivery: You need to say, "For this project, this is where I've got to get to. What am I going to do to get there? What checks and balances do I want in that process in getting to that point?" and then write the procedure around it, and that's where I think we're pretty good at that here (Motorway, Interview 26).
The interdependence of firms in the ecology meant that it was usually not possible to directly implement learning from previous projects by using the same software: instead, for each project the set-up had to be negotiated, taking into account the specificities of the project. Thus there was no simple transfer of learning across projects. For example, the strong management and governance processes, seen to be vital to digital delivery on Railway, were not fully implemented on either Highway or Motorway.

Project capabilities for digital delivery
Global Engineering has project capabilities for digital delivery in design (e.g. CAD), coordination (e.g. extranets, standardisation), management (e.g. embedded workflows, schedules, project controls), and governance (e.g. communities of practice, technical lessons learnt, guidance, etc.). On each project, new project-specific integrated software and processes were used across the project ecology and the set-up of the software and processes used for delivery was seen as important, discussed and -on Highway and Motorway -contested. Global Engineering's involvement in digital delivery is illustrated in Table 4.
Building project capabilities for digital delivery within the firm involves embedding and disseminating the learning from complex projects. Railway influenced Global Engineering's involvement in setting up digital delivery on Highway and subsequent projects, as many engineers involved in Railway were also involved in Highway, though Global Engineering had relatively little internal documentation on the lessons learnt on Railway. By most measures, Railway was an order of magnitude larger than the other two projects, and as the largest project we studied, Railway was also the most remote from Global Engineering: the project team was located in the Railway project offices, using project procedures, and lacked access to Global Engineering software, knowledge management and lessons learnt database.
In contrast, Global Engineering's intranet is relatively well populated with Highway 'lessons learnt' documents, quality documents, project close-out reviews and feedback notes. Knowledge about digital delivery from Highway was also transferred through individuals, both through personal communication in phone-calls and email, and in the re-assigning of key team members to similar projects as identified 'experts'; it was embedded and disseminated through Global Engineering's skills network, in-house training courses and presentations. It was made more widely available to the industry through public dissemination, e.g. through contribution to a special issue on Highway in a professional journal; and through input into industry standards, best practices, metrics, and tools. Despite this dissemination success, after completion of Highway some lessons learnt (e.g. management of CAD data) were only put into practice on other projects five years later, as vendors had not embedded this functionality into their software and it took time for Global Engineering to understand how to implement these lessons more broadly in digital delivery.
Unlike the teams on Railway and Highway, Global Engineering's staff on Motorway were relatively inexperienced (on our pre-interview questionnaires, interviewees from Railway had more than 25 years of experience on average; from Highway more than 20 years; but from Motorway less than 10 years). The Motorway project team, with many engineering graduates in their twenties working in a regional office on the other side of the world from head office, felt relatively isolated from the accumulated experience of the firm. Thus, it was surprising to the central team in the head office that, on this project, the team was innovative in digital delivery. Motorway built capability that has since been disseminated across Global Engineering. The firm seeks to learn from such projects, and the purpose of the central team is to embed and disseminate learning from complex projects to build project capabilities for digital delivery within the firm.

Aligning and reconciling to build project capabilities for digital delivery
Our data suggests that to use existing project capabilities and build new project capabilities for digital delivery, Global Engineering seeks to: (1) align the set-up of digital delivery on the complex project with the firm's related project capabilities; and (2) reconcile differing agendas and capabilities in collaborating firms during project implementation.

Aligning involves (a) influencing the digital set-up; and (b) rene-
gotiating that set-up during project implementation. Global Engineering seeks to align the set-up of digital delivery on the project to make use of its existing capabilities and to reduce the additional cost of technology licenses and the investment required for training in new software. 2. Reconciling, in order to work together with other firms in the ecology of firms involved in the digital delivery of complex projects, takes place during project implementation. It involves Global Engineering (a) managing across multiple systems; (b) accommodating and learning other firms' software and pro- Table 4 Global Engineering's involvement in digital delivery and learning across the three projects (adapted from our report that was agreed with the firm).

Global Engineering's involvement in digital delivery Digital delivery
Design: Integrated using software chosen by Global Engineering.
Design: Not integrated -on corporate networks, using firms' preferred design tools.
Design: Integrated using software chosen by Global Engineering, 3D visualization. Coordination: Collocated -Intranet set-up by Global Engineering as a shared internal system across collocated team.
Coordination: Distributed -Using extranet, for the first time, across offices and firms. Licenses mean some software not available across the project.
Coordination: Collocated then distributed -Real-time extranet: shared models real-time distributed working; design team's digital systems.
Management: Strong, using dashboards; and rigorous processes.
Management: Extranet-enabled approvals software set-up by Global Engineering.
Management: Initially set up as a single network for managing delivery, later changed to separate networks for design and construction. Governance: Strong, in the project with shared standards, procedures; weak affiliation with the firm.
Governance: Weak governance of the project, with strong affiliation to the firm.
Governance: Weak governance of the project, with strong affiliation to the firm's local office.

Main areas of Global Engineering's learning Learning
Importance of shared software for project management and project controls; shared standards and procedures; and retaining and reintegrating staff when they return to the firm.
Value of an extranet for collaboration and approvals; integrating work with another design firm, version control, data transfer formats; training, time and effort required to implement new technologies.
Use of design and communication management databases; shared modelling and value of 3D deliverables; capturing ideas of younger engineers; and increased use of social interaction technologies.
cesses; and (c) using digital technologies to create a shared identity across the firms involved in digital delivery.
Our data on aligning and reconciling is summarized in Table 5. The following sub-sections discuss the evidence on aligning and reconciling, using examples from the Railway, Highway and Motorway cases.

Aligning the project and firm
By aligning the firm and the project, Global Engineering seeks to create and capture value from its existing project capabilities for digital delivery; and to build new project capabilities for digital delivery. It does this by influencing the set-up of digital delivery; and renegotiating the set-up during project implementation.

Influencing the set-up of digital delivery
Global Engineering took opportunities to influence the set-up of digital delivery in Railway, Highway and Motorway, as shown in Table 5. This involved using Global Engineering's corporate systems and preferred software where possible; customizing software to Global Engineering's processes; contributing to the set-up of digital delivery for the project; training project participants and documenting processes; standardizing processes across the project; and achieving early agreement on CAD systems and deliverables. Global Engineering had influence over the set-up of digital delivery on all three projects. Railway provides a particularly good example.
On Railway, Global Engineering anticipated that the set-up of the digital systems would be done by another firm in the joint venture, as this firm had a reputation for project management. The Global Engineering team found they had more influence than they expected. Hence, they provided the network and had significant input on digital design processes, specifying design and route alignment software. Team members from Global Engineering and other project-based firms in the joint venture worked together, through a series of workshops, to identify appropriate integrated software and processes. As one interviewee noted: "one of the things we agreed, very early on, is it was absolutely crucial we had solid and broad and consistent information platforms" (Interview 14). The overarching principle for selecting the software for use on the project was to: "use the most appropriate tools for the most appropriate place" (Interview 9). Such software needed to be developed and customized specifically for the delivery of Railway, as: "because of the scale of the project, we didn't have systems [. . .] we didn't have readily adoptable systems" (Interview 12).
On Highway, Global Engineering similarly had input into the set-up of integrated software and processes: it was able to use capabilities for digital delivery developed through work on Railway, and also to select new software for a digital approval process and to customize this software to suit existing workflows and thus enable the various stages of document review and sign-off. On Motorway, Global Engineering wrote the plan for digital delivery when it became involved at the detailed design stage, and had influence over the design software.
The Motorway delivery team identified the use of integrated software as potentially improving efficiency and saving cost, with both the construction and design teams hosted and supported on a single network to share project data. Prior to the project start, conventions such as numbering of drawings were developed through a consultation exercise, to enable efficient working across teams in this highly interdependent environment. One of the contractors took responsibility for the set-up of the network and integrated software for collaboration. The other design firm, which we will refer to as 'Other Design', had worked with this contractor before, but it was Global Engineering, as the lead design firm, that had a more significant influence and took a leading role in the choice of design software on Motorway. Global Engineering provided 80% of the design staff for Motorway, as 'Other Design' was concurrently responsible for work on another large project. An interviewee from Other Design explained: As far as the designers are concerned, because [Global Engineering] was taking a lead role then they had dominancy in the software that was required. But having said that, they wouldn't turn round to [us] and say, "Well we use this type of software for designing bridges, you must use that type of software," it's not like that (Interview 32 [from Other Design]).
In project implementation, Global Engineering experienced difficulties in working with Motorway network and collaboration technologies that had been set up by the contractor. The alignment between the project and Global Engineering was not good, and the set-up of digital delivery had to be renegotiated during project implementation, as described in the next section. Standardizing processes across the project: "an early activity for us was to get the whole project on a consistent coordinated grid, a consistent database. We used a GIS information platform, and all processes were standardized, all documents had a standard system or information platforms were on the same basis" (Railway, interview 14). Achieving early agreement on CAD systems and deliverables: "I concluded early on, that we had to have everything in the same CAD system, and we had to have as much as we could in three dimensions. And it took quite a time to get everybody doing the same. You can imagine, with 1000 people coming together, with lots of different disciplines, you have people who are creating tunneling drawings, you have people who are creating bridge drawings, people creating drawings for consents, which, of course, have bridges and tunnels on them, all those things, and you've got to find a way of bringing them together. So I actually held a series of workshops to try and get people talking in the same language, and decide what the deliverables would be" (Railway, interview 9).

Renegotiating the set-up
Reverting to own server set-up: "So part way through there, when we won the bringing in [integrated software], we just said, 'No more, we've set up our own server, [integrated software], the whole lot,' and we just take charge. [. . .] and went, "Right, the best way for us to actually run our business is to do what we always do, set up the servers, set up the IT, set up the licensing, and then get on and do it." So we − it was a steep learning curve" (Motorway, interview 26).

Accommodating and learning other firms' software and processes
Negotiating working practice where not contractual: "if the client [. . .] said 'Right all the data must be delivered in this format and all the data must be created in this format using these tools' then we would have just changed or [the other firm] would have changed but nobody took that view and put it into a contract if you like to say 'This is what you are going to have to do'. Therefore it was [. . .] a kind of suggestion to [the other firm] 'Well you could come and use the same things' but then they are saying 'But look at all the retraining costs that we have got. We haven't got the time to retrain people and do that"' (Highway, interview 1). Accepting other design firm's software use: "Basically you can't force a company to change [. . .] all their technicians have to be trained or you can't force a company to change its normal operating mode" (Highway, interview 7). Ensuring quality of other firms' work: "the documents that they're delivering and actually the products they're delivering that they're not conforming and, therefore, yeah, in spite of a number of warnings, that's why we've had to take measures to put senior staff in just now to address problems" (Motorway, interview 38).

Shared project identity
Using software developed in a collaborating firm: "they had access to the source code, [. . .] I'm a [Global Engineering] employee. It was, sort of, an interface between some of the [Global Engineering] staff and some of the [project management firm] staff. Now, we were all sitting in one project team together [. . .] it was trying to make that process of integration of different companies quite − more efficient than it might have been. And again, after a while, the company you work for is irrelevant" (Railway, interview 12). Promoting shared understanding: "Done some temporary works. I created a little construction sequence and a little movie to help show the construction team. [. . .] That was a valuable thing that when the construction team came into the office, I would bring up the 3D model and show them, rotate the views and show them − give them a clearer understanding of what they're building" (Motorway, interview 38).

Renegotiating set-up during project implementation
Global Engineering took opportunities to renegotiate the setup of digital delivery during project implementation, as shown in Table 5. This involved realignment, to make better use of Global Engineering's existing project capabilities for digital delivery and to reintegrate the project team back into the firm.
In our data, we observed the renegotiating of alignment during project delivery on Motorway. The alignment between the project and firm broke down. Global Engineering felt it had to explain to the contractor how a design firm works: Whilst we worked together, we run very different businesses as well and they fundamentally don't understand how our businesses work. So information management for us is our business. [. . .] So, we just had to sell it to them, explaining, "This is how we work", access to our licensing data, our tools, our databases, all the standard templates and whatever else, we needed all that for us just to be able to do our job (Interview 26).
The contractor had been selected to set up the integrated software for Motorway because it had worked with Other Design before and had experience in delivering integrated software to these previous projects. However, its set-up for the integrated software did not work for Global Engineering. An interviewee explained how the contractor had changed the original plans for the project, and how Global Engineering then changed these plans again, to better accommodate the designers' need for iteration in design: I wrote the IT plan for [Motorway] initially, which didn't include [the contractor, which] then came later to the deal and decided to change it. And then ultimately the [contractor] network solution didn't work, so [Global Engineering] was then asked to provide a solution for the designers, again (Interview 31).
A few weeks into the project, the design joint venture began to work on a separate network from the contractors, using Global Engineering's networks, software and processes. On this new setup, Global Engineering used a design management database to integrate design work and manage the coordination of this work across the different firms involved in the project. The team also used model management, which they saw as a significant benefit. One project participant noted that it: . . . Through these developments, the local office of Global Engineering gained significant knowledge and experience. The interviewees indicated: "Our sophistication in terms of how we manage our jobs, how we design and how we document and so forth started to go up quite quickly" (Interview 26).
At the end of Railway, however, there was realignment to reintegrate staff from the project back into the firm. This challenge related to the decision on Railway to set up and retain integrated software through the project duration, without updates or version changes: "But once you say you're going to work to something and everyone understands it, why not, if it's working, keep it going for the duration of that project?" (Interview 14). The integrated software and processes used provided efficiencies, as interfaces were well understood, with the same software packages and versions used across the project. However, the same computers were used for a decade and so the project did not benefit from advances in computing capabilities. When staff left the project, they had to upgrade their software skills and found it difficult to transfer their learning to the rest of Global Engineering, which was significantly ahead in terms of software versions.

Reconciling across the project ecology
Where Global Engineering was not able to align the digital setup of the project with its existing project capabilities for digital delivery, our data suggests that it had to reconcile the different agendas and capabilities of other firms involved in delivery in order to work collaboratively as part of the project ecology. On each project, significant work was required to reconcile differing agendas and capabilities in the project ecology. Through reconciling, Global Engineering was able to take advantage of other firms' project capabilities for digital delivery as well as building its own capabilities. Reconciling involved managing across multiple systems; accommodating and learning other firms' software and processes; and using digital technologies to create shared project identity.

Managing across multiple systems
On both Highway and Motorway, decisions were taken to keep some activities separate, and during project implementation Global Engineering had to reconcile differing agendas and capabilities in collaborating firms by managing across multiple systems. Table 5 shows how this involves bridging across different software and networks; overcoming the hurdle of access; dealing with gaps in project set-up and training; and connecting project intentions with Global Engineering's local resources.
On Highway, the client had not mandated the design software, so the two design firms used the software in which they had project capabilities for digital delivery. A manager from Global Engineering explained that: It was not feasible to force everyone to use the same software like in both [an airport and the Railway] projects. There was no time to train everyone (Interview 5).
Because a design software was not mandated, Global Engineering did not need to re-skill its engineers to work in unfamiliar software. However, as there were different ways of working in the two design firms, the project team needed to manage the work across multiple systems.
The decision to separate from the contractor system on Motorway meant that the Global Engineering project team on Motorway also had to manage multiple software applications across different networks. With the design management database, there were then four different systems providing communication and integration across firms: the contractor's document management software; the design management software; the communication management software, which provided a searchable archive of all project-related email; and each individual's personal email accounts. The lack of integration between these, which were hosted on two separate networks, caused issues. These were emphasized in our interviews with Other Design: The construction guys were on a completely separate server to the design guys. That causes all sorts of problems [. . .] when you're trying to directly communicate with them, and share files and things like that. There might be a reason for it, but it's certainly a hindrance. And then there are too many levels, and they all copy each other, to a certain degree (Interview 33, Other Design).
For design engineers, this lack of integrated software and processes was problematic because design and construction teams worked closely together.

Accommodating and learning other firms' software and processes
To work with collaborating firms in the project ecology, the Global Engineering team had to accommodate and learn other firms' software and processes. Table 5 shows how this involves negotiating working practices, where these are not contractual; and accepting the other design firm's software use while ensuring the quality of other firms' work. On Highway, for example, using different design software allowed the two firms to draw on their existing project capabilities for digital delivery. Global Engineering and Other Design designed different sections of the road. However, keeping activities apart led to coordination issues: We had two different CAD systems [. . .] and they were subtly different [. . .] and if when you drive from the section that [Global Engineering designed to the section designed by the other design firm] there's a slight bump in the road, that's because the two systems didn't line up (Interview 7).
On Highway, there was also a focus on using digital design data in construction, with an engineer seconded to the contractor. In this secondment, the boundaries of different integrated software systems and the challenges of licenses became clear to the engineer. Design software and databases that were easily accessible within Global Engineering were now out of reach, as the engineer was no longer able to access Global Engineering's systems, making it difficult to accomplish her role. The engineer became a strong advocate of establishing shared digital systems, e.g. project licenses for software, to enable project team members from different firms to access software appropriate to their delivery responsibility in the project.

Using digital technologies to create shared identity across firms
Building shared project identity enabled Global Engineering to use and build project capabilities for digital delivery. As shown in Table 5, this involves using software developed in a collaborating firm, and promoting shared understanding.
On Railway, the scale of delivery, with new interdependencies between the knowledge and expertise of different firms, made it important for the team to be integrated: You can't separate [Global Engineering] away from the others. We were managing, as I say, a totally integrated team. So we had our own people. That was just support and we had our own IT system, so all of the machines and servers were dedicated to this project. I mean, at that scale, it's like running a medium sized company [laughs] (Interview 9).
For team members, the association with the project could be stronger than the association with the firm, especially where contractors were used, as one interviewee from Motorway, who had worked on Railway as a contractor, explained: I was a contract worker then and I could be working for [other design consultant] and then they would change me over so that I was working for [project management company], but I'd actually gone nowhere more or less. [Interviewer: So you're still sat at your desk?] Yeah, it was just because getting the numbers right − it was a joint project (Interview 38).
On Motorway, an engineer explained how modelling in 3D meant liaising with people more, as they would come and look at the model, with five or six people from different disciplines in a huddle around his desk, and work out things that might otherwise have taken many meetings to resolve. Where modelling was done in 3D, an advanced animation tool was also used for the first time to produce visual explanations of the design. Thus, modelling was used to understand the relation of design to construction, and the engineer explained that this gave construction professionals: "a clearer understanding of what they're building" (Table 5: Interview 38). But this was only useful where interactions were complex, not when relatively simple geometry was involved. Another interviewee drew attention to the resource implications of modelling in 3D: "there's got to be a level of judgment where you, sort of, decide when the 3D is the right way to go, and when 2D'is the right way to go" (Interview 29).

Discussion
As integrated software and processes are introduced into the delivery of complex projects, we find that aligning and reconciling are important to project-based firms that work on these projects. Aligning and reconciling create relative stability for learning within project ecologies that involve interdependencies across heterogeneous firms, under conditions of rapid technological change. By relative stability we mean that across its projects, the project-based firm experiences a more stable and predictable environment in which to build project capabilities. This is important because the project-based firm lacks power in its negotiations with the complex project, and so cannot fully achieve a replication strategy, but through aligning and reconciling it can achieve economies of repetition and economies of recombination. Table 6 summarizes how aligning and reconciling creates relative stability, and enables project capabilities for digital delivery to be built and value to be created and captured.
Our empirical data on digital delivery suggests that, in our case, aligning the complex project and the project-based firm reduces the need for training in new software and processes, through influencing the set-up and renegotiating that set-up during project implementation. Through aligning, Global Engineering was able to create and capture value by mobilizing existing staff competences and software resources to build project capabilities that extended the firm's existing project capabilities for digital delivery.
The data suggests that reconciling involves managing multiple systems, accommodating and learning from other firms and building shared project identity. Through reconciling, the project-based firm Global Engineering was able to build project capabilities for new aspects of digital delivery, or to turn competencies in the digital interfacing with other firms into firm-level project capabilities. Here, value was created within the ecology of firms, with the firm benefiting as part of that ecology. Such reconciling sometimes involved unproductive cycles of work, and in Motorway, this caused the firm to revisit the alignment of digital delivery across the project and firm during implementation.
Aligning and reconciling enable the firm to develop the technological knowledge required to accommodate future changes (Brusoni et al., 2001). We did not observe the move from exploration to exploitation that was observed by Brady and Davies (2004) in their work on project-based firms entering new markets. We find that Global Engineering collaborates with different firms on each complex project as digital delivery transforms its existing markets. Across the three projects we studied, there was significant capability building and learning, but not a straightforward replication or progressive move from exploration to exploitation. Instead, we find that building digital capabilities continues to involve both 'economies of repetition' and 'economies of recombination'; the former enabling the firm to capture value by mobilizing existing resources and the latter, requiring additional work to re-combine existing and new resources.
Although the projects studied, Railway, Highway and Motorway were the same generation of digital delivery, with integration of work achieved through project and program management tools, intranets and extranets, Railway was not a vanguard project developing project capabilities that were then exploited by Global Engineering in Highway and Motorway. Engineers who had worked on Railway felt they had learnt the need for strong management and governance with integrated software and the associated processes set up at the start. Yet this was not achieved on Highway, where, in contrast, there was substantial data conversion at the Table 6 Aligning and reconciling as important in creating relative stability for building project capabilities for digital delivery.

Aligning Reconciling
Relations involved across the ecology of firms involved in the project Relative stability created through: • Influencing the set-up of digital delivery; and • Renegotiating that set-up in project implementation.
• Managing across multiple systems; • Accommodating and learning other firm's software and processes; and • Building identity through shared digital systems. Enables project capabilities to be built by: Extending existing project capabilities for digital delivery to create and capture value in the firm.
Building project capabilities for new aspects of digital delivery; and for interfacing digitally with other firms.

Captures value through:
Economies of repetition: Reduces the need for training in new software and processes, enabling the firm to mobilize existing resources.
Economies of recombination: Can require additional work to interface with the software and processes of other firms in the project ecology.
interfaces between firms, to allow the firms to work on separate corporate design technologies while delivering data to the client in the required format. Nor was it achieved on Motorway, where, six weeks into the project, the firm had to make changes in the software set-up in order to accomplish its engineering design role. Instead, the analyses extend prior research (Brady and Davies, 2004;Davies and Brady, 2016) suggesting that within the rapidly changing environments associated with digital delivery, Global Engineering aligns and reconciles capabilities on these complex projects through a mixture of exploratory and exploitative elements to create relative stability. We see aligning as enabling the economies of repetition associated with exploitation (Brady and Davies, 2004) and reconciling as enabling the economies of recombination associated with exploration (Manning and Sydow, 2011;Grabher, 2002). This explanation acknowledges the difficulties of learning observed by previous scholars (e.g. Newell and Huang, 2003;Williams, 2008;Prencipe and Tell, 2001), and the difficulty of moving beyond exploration in volatile or uncertain environments (Davies and Brady, 2016).

Conclusions
Digital delivery of complex projects, using integrated software and processes, is an important emerging phenomenon which transforms work and relationships across the associated ecology of project-based firms. This research has explored how a projectbased firm uses existing, and builds new, project capabilities for digital delivery through its work on three complex projects. It highlights the importance of aligning and reconciling, where the firm aligns the set-up of delivery of the complex project with the firm's related project capabilities; and reconciles differing agendas and capabilities in collaborating firms during project implementation. We argue that aligning and reconciling are important in enabling project-based firms to build capabilities through work on complex projects with project ecologies that involve interdependencies with heterogeneous firms and conditions of rapid technological change.
Here learning about digital delivery, though it occurs (Table 4), is difficult to achieve, and aligning and reconciling can be seen as dynamic capabilities, which enable areas of knowledge to be leveraged across projects through a combination of economies of repetition and economies of recombination.
The central team in Global Engineering was tasked with deploying digital methods of delivery across projects. It was not simply able to progressively learn and exploit capabilities; instead it had to align and reconcile existing and new project capabilities across the project ecology of each complex project in order to achieve its strategic objectives. This interaction between project and dynamic capabilities has implications for managers. Replication across projects is not achieved as different project ecologies may have differing objectives, digital technologies and levels of complexity. However, if managers align capabilities for digital delivery at project set-up, there is less of a need to reconcile these, in the implementation stage.
Where there is interdependence across collaborating firms, aligning and reconciling are important in creating the relative stability needed to build project capabilities through learning at the interface between a project-based firm and a complex project. The challenges of high interdependence explains why the project-based firm, which is able to use a vanguard project and transition from exploration to exploitation in entering new markets (Brady and Davies, 2004), is not able to make this transition when building project capabilities for the digital delivery of complex projects in existing markets. Such project capabilities are needed to remain competitive, with different successive generations of digital delivery increasing interdependence across firms in the project ecology. Here we find the firm needs to have broad knowledge and dynamic capabilities, as suggested by Brusoni et al. (2001), though our data does not show the ability of firms to reduce interdependence and specialize because of the rapid technological change in the integrated software and processes used for digital delivery.
Our research identifies aligning and reconciling as important in building project capabilities for digital delivery of complex projects. Aligning and reconciling can be understood as dynamic capabilities. Referring to Teece et al. (1997); Teece (2007) and Helfat et al. (2007), the firm's capabilities need to be dynamic if the firm is to prosper in rapidly changing environments. Newell and Edelman (2008) and Manning et al. (2013) refer to projects as providing opportunities to build such knowledge and experience, with Newell and Edelman (2008) highlighting the role of dynamic capabilities in this context. Our findings extend this by showing that the dynamic capabilities of aligning and reconciling enable the building of project capabilities for digital delivery in the firm, thus enabling the project-based firm to prosper in rapidly changing environments. We find that establishing processes to maintain stability requires the dynamic capabilities of aligning and reconciling, if the firm (in the project ecology) is to achieve competitive advantage in digital delivery. Such a conceptualization raises new questions for research on project-based firms and their capabilities in dynamic and uncertain environments. There is a need to further examine how such dynamic capabilities are used by project-based firms that work on complex projects to build other kinds of project capabilities; and how these firms build such dynamic capabilities. There is also a need to examine the project capabilities that need to be built for the next generation of digital delivery of complex projects where the focus is on cloud computing, mobile devices and 'big data' (Whyte et al., 2016). We see aligning and reconciling as of continued importance in this next-generation context, and future research can build on these constructs to examine other aspects, including the dynamic capabilities required at the strategic level, for the next generation of digital delivery of complex projects.