The interstitiality of IT risk: An inquiry into information systems development practices

Information systems development (ISD) has been part of the core of information systems for over 40 years. Throughout its history, the issue of risk has been closely related to ISD projects, and significant efforts have been made by researchers and practitioners to improve their quality. While important headway has been made in assessing and resolving ISD risk, the literature shows that new and salient risks emerge outside the scope of extant risk management regimes. As a consequence, organizations still struggle with leveraging new technology as projects continue to fail at almost the same rate, albeit for different reasons. Understood as the distinction between reality and possibility, risk is inherently intertwined with practice and rooted in the knowledge, goals, power, and values of specific actors in particular contexts. Hence, to understand how risks emerge, we present a longitudinal case study in which we trace the origin and locus of risks in contemporary ISD practices. We draw on these insights to theorize information technology risk as increasingly interstitial, originating from sources positioned in between established practices and therefore outside the scope of conventional risk analyses. In conclusion, we discuss interstitial risks as an important form of emergent risk with implications for both research and practice.

In defining risk as "the distinction between reality and possibility," Renn (1998) highlights the consequentiality of human activities in the production of both reality and possibility. Furthermore, he emphasizes that risk is inherently rooted in practice, produced in part by the knowledge, goals, power, and values of different actors in specific contexts.
He also notes how "ignoring the connections between social organizations and technological performance may seriously underestimate the likelihood of failures […] reality is seen as both a system of physical occurrences (independent of human observations) and constructed meanings with respect to these events, and to abstract notions" (p. 61). To investigate how risks are implicated in ISD, we must therefore examine ISD practices with a particular focus on the intrinsic interplay between social context and technological manifestations.
Against this backdrop, we present a longitudinal case study of the development, support, and sales of an increasingly integrated IT services at ISD-org (pseudonym), a global consultancy firm, to investigate the following research question: How do risks emerge in the development of complex information technology services? To uncover the origin and locus of IT risk emergence, we focus on the everyday practices of ISD professionals and the structural conditions at ISD-org over a 10-year period. A key finding is that salient risks emerged interstitially at ISD-org. More commonly used in medicine and physics, the term interstitiality refers to the space between established structures or bodies. Here, we use it to theorize how the origin and locus of IT risks moved as the technology changed, from being located within practices, services, and projects to the spaces between them. This led to new insights into the area of ISD risk, with implications for both research and practice.

| ISD risk
Risk management is considered fundamental to project performance (Kutsch, Denyer, Hall, & Lee-Kelley, 2013), and the discourse on risk and risk management within IS research has evolved over more than 4 decades. The earliest works were produced by pioneers such as Boehm (1973) and Alter and Ginzberg (1978). Over the years, many researchers have contributed to the field, making the discourse rich in theoretical approaches and diverse in both methodological choices and studied phenomena. Research relating to ISD has consistently formed a stable core of the discourse (Alter & Ginzberg, 1978;Bannerman, 2008;Boehm, 1989;Charette, 1989;Currie, 1998;Keil, Tiwana, & Bush, 2002;Lyytinen, Mathiassen, & Ropponen, 1996;McFarlan, 1981;Persson et al., 2009;Taylor et al., 2012). A characteristic of the discourse is its close relationship with practice, and as the use and importance of IT has evolved, research has followed. As a result, research on risk in IS encompasses a great richness of conceptualizations and theories. In keeping with the field's closeness to industry, most of these approaches can be characterized as applied, and cover dimensions ranging from the technical (Boehm, 1991) to the managerial (McFarlan, 1981) and behavioural (March & Shapira, 1987). While many analyses have been conducted at the project level, studies conducted at the organizational (Dhillon & Backhouse, 1996), interorganizational (Aron, Clemons, & Reddi, 2005), and even societal (Mumford, 1996) levels have also been reported. Complementing the extensive research on software development projects are investigations of risk related to various other phenomena and areas, such as outsourcing (Aubert, Patry, & Rivard, 2005;Bahli & Rivard, 2003), enterprise resource planning (Aloini, Dulmin, & Mininno, 2007;Sumner, 2000), security (Cremonini & Nizovtsev, 2010;Straub, 1990), knowledge management (Alhawari, Karadsheh, Talet, & Mansour, 2012;Massingham, 2010), and IT investment (Otim, Dow, Grover, & Wong, 2012).
However, the bulk of the reviewed publications (67 of 128) concern ISD. This is also reflected in previous literature reviews summarizing the discourse on ISD risk (Bannerman, 2008;Ciborra, 2004;Lyytinen et al., 1996;Taylor et al., 2012).
Our literature review yielded several insights. First, the most prevalent approaches in ISD risk management are standardized checklists of project-level risk factors, building on a monolithic view of risk from the perspective of individuals such as project leaders. By assuming that individual risks can be generalized across contexts, analyses of such lists have contributed significantly to practice by revealing common ISD risks (Alter & Ginzberg, 1978;Boehm, 1989;Gemino, Reich, & Sauer, 2007;Schmidt et al., 2001;Tesch, Kloppenborg, & Frolick, 2007). At the same time, this approach has been criticized for shaping the attention of risk managers in ways that increase the likelihood of overlooking potential risks absent from the list (Keil, Li, Mathiassen, & Zheng, 2008;Lyytinen et al., 1998), and for offering little guidance as to which list should be used in specific situations (Bannerman, 2008). These efforts view risk in terms of uncertainty, on the basis of the idea that risk managers can obtain sufficient knowledge for both risk assessment and risk resolution at the start of a project. As such, they cannot account for risk emergence.
Second, situated approaches offer an alternative way of thinking about risk. Both process and nonprocess frameworks are common in the literature. Process frameworks usually prescribe a stepwise sequence of actions in relation to risk assessment and resolution (eg, ISO31000, 2009). Nonprocess frameworks focus on aggregated risk categories on the basis of sources of risk (Huang, Chang, Li, & Lin, 2004;McFarlan, 1981;Persson et al., 2009;Ropponen & Lyytinen, 2000) rather than on specific risks and require risk managers to account for the specifics of their situation.
Like contingency approaches (Barki, Rivard, & Talbot, 2001;Ghobadi & Mathiassen, 2016;Mathiassen, Tuunanen, Saarinen, & Rossi, 2007;McFarlan, 1981;Taylor et al., 2012), these frameworks recognize emergence to the extent that they offer decision support for risk managers as events unfold. Still, these situated approaches build on the same basic notion of risk as the standardized approaches, ie, they treat risk as a form of uncertainty. In relation to Renn's (1998) definition of risk, they emphasize "possibility," directing risk managers' attention towards certain sources, characteristics, and specific risks commonly occurring in ISD projects. However, they only indirectly address "reality" and do not account for the role and nature of technology.
Third, and in keeping with the general trajectory of the IS field, there have been recent attempts to account for the impact of increasing complexity on issues of risk. Information infrastructure theorists have adopted a sociological notion of risk on the basis of the work of Beck (1992Beck ( , 1998 and Giddens (1990) to describe the logic and evolution of control and change in complex socio-technical contexts. Hsu, Backhouse, and Silva (2014) build on the work of Giddens to analyse operational risk management. Scott and Perry (2009) draw on practice theory to investigate how risk management is enacted. Finally, Mitev (2011) explores the relationship between risk and regulation through the notion of paradoxes, and the notion of systemic risk is gaining traction (Carlo et al., 2012;Carlo, Lyytinen, & Boland, 2004;Hu et al., 2012). In addition, an alternative conceptualization of risk has been introduced into the IS discourse through work on information infrastructure theory (Blechar & Hanseth, 2007;Ciborra et al., 2000;Hanseth, Ciborra, & Braa, 2001;Hanseth, Monteiro, & Hatling, 1996). This body of work largely builds on a notion of risk developed by Beck (1992;Beck et al., 1994) and Giddens (1999) in their research on reflexive modernization as a way to characterize and explain the dynamics of contemporary society. At the core of Beck's argument is the assumption that the world is becoming increasingly unpredictable and unmanageable because of the development and use of complex technology and organizational forms. In this context, the dynamics of change are understood as consequences of unintended side effects. Side effects are effects that propagate through multiple layers of a complex system and are ultimately reflected back onto the thing that triggered them, either directly or by changing the conditions in a way that calls the initial action into question (Beck, Bonss, & Lau, 2003). Research on information infrastructure (Blechar & Hanseth, 2007;Ciborra et al., 2000;Hanseth et al., 2001) has thus shown how technology intended to increase control has had the side effect of reducing it.
Similarly, the notion of systemic risk (Carlo et al., 2004;Hu et al., 2012) has been advanced as a way of addressing issues of risk emergence based on the relationship between risk and complexity. Systemic risk refers to risks that cascade through interconnected parts of a network-ie, when failure in one part of a system triggers failure in other parts.
The main difference between the notion of systemic risk and that of side effects is the nature of the source: While both notions build on the idea of risks cascading through multiple interconnected layers, systemic risk starts with a failure whereas side effects can come from any action. Put differently, systemic risk refers to the process of how risks propagate outwards through networks, while side effects relate to the way actions trigger effects that ultimately reflect back on their source. As such, side effects do not necessarily create risks or become risky in other layers or parts of the system or network.
Both side effects and systemic risk can be seen as comments on the changing nature of ISD reality because they build on ideas about how the character of technology has changed and thereby increased the likelihood of emergent risks. Both approaches reflect the general movement within IS towards recognizing emergence as a salient feature of IT use and have thus opened up the risk discourse in important ways. In this paper, we extend these contributions to explaining IT risk emergence on the basis of a detailed and empirically grounded longitudinal study of how emergent risks are managed in a contemporary ISD context.

| ISD practice
Understanding risk as "the distinction between reality and possibility" (Renn, 1998) implies that we must consider both realms and their relationship to understand and explain how risks emerge in an ISD setting. First, philosophers have debated the notion of reality and its nature for as long as they have been around. However, certain aspects of reality stand out as more important than others in the context of IT risk and ISD-in particular, notions of technology, agency, and structures. The organizational consequences of IT are a long-standing concern in IS research (Markus & Robey, 1988;Robey & Boudreau, 1999), and many studies have sought to explain and understand the complex relationship between organizations and their technology. As such, IT risks result from and can be managed by specific agencies that are intended to shape the use of IT as part of the ongoing structuring of organizations.
In this paper, we position our ontological assumptions within the emergent perspective on causal agency (Markus & Robey, 1988), meaning that we understand organizational change as an effect of forces that simultaneously promote and oppose social change as reflected in information infrastructure theory (Hanseth & Braa, 1998), structuration theory (Orlikowski, 1992), actor-network theory (Walthsam, 1997), sociomateriality (Leonardi, 2012), and practice theory (Feldman & Orlikowski, 2011). Building on the emergent perspective, we view digitalization as a driving force that changes the foundations of all aspects of organizational life (Brynjolfsson & Saunders, 2010;Tilson et al., 2010;Yoo, Henfridsson, & Lyytinen, 2010). This change in the fabric of reality has made ISD practices increasingly complex (Baskerville, Ramesh, Levine, Pries-Heje, & Slaughter, 2003;Lyytinen & Robey, 1999;Lyytinen, Rose, & Yoo, 2010) as increased processing power and higher storage and transmission capacities have tied together systems, actors, and functions within and across organizational boundaries (Hanseth & Lyytinen, 2010).
The context of ISD is also characterized by constant adaptations to turbulent environments (Holmberg & Mathiassen, 2001) as green field development of single, isolated systems sold and maintained as products has transitioned to adaptation of standardized software solutions and software service provisioning (Syed, Barqawi, & Mathiassen, 2017) and platform-based development by third-party developers (Bergvall-Kåreborn & Howcroft, 2014).
The installed base of standards, practices, and technologies to which new technology must be adapted during development and implementation is increasingly heterogeneous, interconnected, and deeply embedded, both socially and technologically (Tilson et al., 2010). Moreover, ISD increasingly operates in hypercompetitive markets introduced by the internet boom , where the ability to cope with rapid change is essential (Baskerville et al., 2003;Pries-Heje, Baskerville, Levine, & Ramesh, 2004). At the same time, the move from product orientation to a service-dominant logic (Mathiassen & Sørensen, 2008;Barqawi, Syed, & Mathiassen, 2016) has significantly affected the way ISD organizations operate and are structured. Information systems development has therefore become increasingly polycentric (Constantinides & Barrett, 2014), with control being continuously negotiated between multiple spheres of authority including platform owners, service providers, customers, and government agencies. Moreover, control is multivocal (Bernardi, 2009) because ISD processes involve many different interdependent practices and stakeholders, each with their own knowledge, goals, and needs (Markus & Mao, 2004) with new levels of complexity across projects as a result (Kang, Hahn, & De, 2017).
Second, there is the notion of possibility-which includes both what we think will happen and what will actually happen. This distinction is significant in several ways: (1) It separates "reality" from our interpretations of it; (2) it highlights the notion of knowledge as the foundation of our assumptions about the world and how it works; (3) it recognizes our ability to be imaginative based on our knowledge; (4) it stresses the importance of our values and goals as they guide our decisions; (5) it makes risk fundamentally related to the perspective of the risk identifier; and (6) it emphasizes the importance of authority with regard to which interpretations will be prioritized and whether they can be acted upon. Risk is thus highly pragmatic, rooted in the knowledge, goals, power, and values of specific actors and connected to their decisions about future actions in particular contexts.
Practice theory is useful for addressing the "possibility" aspect of risk because it offers a way to chart changes in "reality" through longitudinal studies that trace the interplay between reality and possibility. Practice approaches have recently made inroads into IS research (eg, Leonardi & Barley, 2010;Orlikowski, 2007;Schultze & Orlikowski, 2004) and have become important in management and organization studies in general (Newell, Robertson, Scarbrough, & Swan, 2009). For example, Marabelli and Newell (2012) revealed how conventional views of knowledge in the literature are inconsistent with knowledge management practices. As contemporary organizing is increasingly performed in uncertain, novel, and indeterminate circumstances, practice approaches offer powerful analytical tools to investigate organizational dynamics and complexities (Feldman & Orlikowski, 2011). Practice approaches have also been used previously to explore the design and implementation of infrastructures (Kuk & Janssen, 2013). There is no "one true" practice theory (Feldman & Orlikowski, 2011;Marabelli & Newell, 2012); instead, practice theory can be seen as an umbrella term encompassing a range of theories for investigating "specific instances of situated action and the social world in which the action takes place" (Feldman & Orlikowski, 2011, p. 1241. Against this backdrop, we use a practice lens to investigate how risks emerged in the development of a complex IT service. We pay particular attention to the technology being developed, and the actions taken by individual actors, including how, where, and why they acted, as well as the organizational context in which their actions were taken. As such, we understand practice as "the coordinated activities of individuals and groups in doing their 'real work' as it is informed by a particular organizational context" (Cook & Brown, 1999, p. 386).

| RESEARCH METHOD
We adopted a qualitative methodology to gain a detailed understanding of the development of a complex and dynamic character within an information infrastructure service (Benbasat, Goldstein, & Mead, 1987;Walsham, 1993;Yin, 2013). To investigate the emergence of IT risks in this context, we adopted a process perspective (Newman & Robey, 1992;Pettigrew, 1997). This allowed us to focus on the sequence of events that occurred over time and to explain how and why certain outcomes were reached. Adopting a practice approach, we traced everyday information infrastructure practices at ISD-org, focusing on their constituting activities and conditioning structures over a 10-year period. Data were gathered through interviews, document analysis, and participatory observations by an insiderresearcher (the second author).

| Research site
ISD-org is a global IT consultancy firm delivering IT services such as process consulting, systems integration, and outsourcing services based on customer requirements and billable hours. During the studied period, external customers were charged significantly higher hourly rates than were internal ISD-org customers. ISD-org offices operated locally with external customers while also participating in the organization's general service deliveries. All projects were required to use a standard risk management model (Predictive Risk Model (PRM); see Figure 1) focused on 4 processes: general business management processes (including sales, delivery, support, and improvement), information security review, financial review, and technical review. The PRM focuses primarily on financial risks to help determine a project's price tag. The greater the financial risk for ISD-org, the higher the price.

| Data collection
We first made contact with ISD-org in 2005, when the second author was employed by the firm. From 2009 to 2014, he acted as an insider-researcher as active member of an industrial PhD program. This approach afforded rich access to relevant data sources (Coghlan & Brannick, 2014) and created an opportunity to obtain a detailed understanding of the intricacies and nuances of the empirical setting (Adler & Adler, 1994). Moreover, ISD-org provided access to multiple data sources on the basis of purposeful sampling (Patton, 2002;Yin, 2013). As noted by Pettigrew (1997), such rich access is especially relevant for longitudinal process studies. To ensure the credibility of our insider-researcher approach (Unluer, 2012), it is important to state that the second author worked as a project and maintenance manager in the team central to this study. As such, he was a native of the group being studied and familiar with the organization as a whole. To mitigate the risk of bias, we triangulated using several different data collection techniques and sources ( Figure 2 and Table 1). Furthermore, the insider-researcher did not conduct any of the interviews.
First, a focus group was conducted with 4 key actors: the 3 core team members (the architect, developer, and project manager) and the head of their ISD-org office. An outsider-researcher (the third author) acted as the moderator. The topic was "challenges and risks related to ISD." In addition, we used qualitative interviews (Mason, 2002) to generate data related to risk identification and risk management strategies. Three rounds of interviews were conducted during 2009 and 2010. The first round concentrated on the period from the initiation of the infrastructure project to 2009. The second round focused on follow-ups as new questions were raised by the initial data analysis.
The third round centred on events that had occurred since the first round. The aim was to generate data regarding risks, risk management practices, team practices, and interrelated ISD practices more generally as they played out over The standard risk management model used at ISD-org FIGURE 2 Overview of data sources used during the studied period time. Because the data were mostly retrospective, we analysed project proposals, project contracts, meeting minutes, presentations, and email conversations to corroborate and substantiate team member narratives (Table 2). This documentation included specifics about the content of change, eg, characteristics of the technology. The insiderresearcher was the main data source for the context of the changes.

| Data analysis
We conducted data analysis in stages. First, we performed an open coding procedure where the insider-researcher and an outsider-researcher (Coghlan & Brannick, 2014) independently coded the empirical data. The interviews were the point of departure, but all results were verified against the written documentation. The following coding steps were taken: 1. The first round of interviews and the focus group session were transcribed and entered into Atlas TI together with other documentation.
2. The data were arranged chronologically to establish a timeline. We used the transcripts to identify key events and major challenges connected to risk management in the context of ISD-org.

Qualitative interviews
Eleven interviews lasting approximately 1 h each. The interviews were recorded and transcribed.
We used these data as the primary source for analysing risk and risk management, as well as other aspects of practice related to the research question.

Participant observation
The insider-researcher's daily informal discussions concerning ISD services.
These data complemented data from the focus group and the interviews and provided an indepth source of data on contextual backgrounds, structural conditions, and everyday risks and challenges in the firm's ISD practices.
Projects proposals Ten proposals from the period, including approved and rejected proposals.
We used these data to chart the changing nature of technology over time, to corroborate data from the interviews, and to provide detailed descriptions of, eg, functionality.

Project contracts
Six project contracts. We used these data to chart changes in formal arrangements and trace changes in the nature of technology.

Meeting minutes
Formal minutes from monthly and weekly meetings within the management group and internal team, totalling nearly 200 meeting minutes.
We used these data to trace risk identification and risk resolution actions throughout the timespan of our study. They also provided detail concerning when and how internal, customers, and exogenous actors and practices related to the team's ISD efforts.

Email conversations
Email conversations between the project and maintenance manager (insider-researcher) and internal and external stakeholders during the period, totalling over 1100 emails.
We used these data to trace relationships between actors within and across practices.

Presentations
The various presentations used to describe the technology service to internal and external stakeholders during this period, totalling close to 40 presentations.
We used these data to analyse how the technology's character changed over time, to identify changes in stakeholders related to the ISD practice, and to trace changes in the kinds of service the technology afforded.
Abbreviation: ISD, information systems development.
3. Transcripts were analysed and coded using 4 categories of codes building on our practice approach and theoretical framing: context, technology, practice, and risk.
4. Subsequently, each category was coded in detail using the subcategories in Table 2.
5. The insider-researcher and one of the outsider-researchers iteratively coded and discussed the events that occurred over the observed period to identify specific and meaningful codes.
6. The analysis formed the foundation for the second and third interview rounds, which focused on collecting data that would allow us to analyse blind spots in the first data set relating to the research question and the insights from the first round of analysis.
7. These transcripts were coded using the scheme developed in the first sequence.
8. The insider-researcher and one of the outsider-researchers independently coded the transcripts with respect to subcategories for each outcome. These subcategories were discussed, and the final number of instantiations of our analytical framework was agreed by merging or separating codes as required.
We conducted 3 rounds of data analysis. The first round was exploratory and consisted of the aforementioned steps 1 to 5. These 5 steps generated significant insights into how the technology had developed over the years, how the team had identified and managed what they remembered as significant risks, and how their way of performing their everyday work had changed. This first round of analysis allowed us to identify 3 distinct phases on the basis of the shifting character of the technology. After analysing the other data sources, we had an overall view of the technology, practices, and risks connected to ISD but lacked detail; we needed specifics regarding stakeholder changes, structural changes, and in the particularities of the evolving practices. The second round of analysis and additional interviews therefore focused much more on specifics and the details of IT risks and risk management across the 3 phases, in contrast to the broader focus and more exploratory approach of the first round. The coding in the second round followed the same logic as in the first round, but the new data (and insights from the first round) affected our analytical subcategories. The coding scheme developed during the second round is depicted below. After the first 2 rounds, some time had passed, and the ISD team had continued their work. We therefore conducted a third round of interviews to gather data on events and decisions taken during this period. The third round of analysis and follow-up interviews therefore focused on the 2 years that had passed since the second round. We applied the coding scheme developed during the second round. In this round, we also discussed our first 2 rounds of analysis with key stakeholders at ISD-org, allowing us to rectify some small mistakes and obtain additional insights into previously discussed issues.

| RESULTS
We describe how risks were implicated in the development of the studied information infrastructure service at ISD-org over a 10-year period. We detail the key supplier practices related to the development of technology and provisioning of the service, along with the key risks and risk management approaches used by the practitioners.
The 10-year period is presented in 3 phases: developing systems, developing a platform, and growing a digital infrastructure. These phases are distinct in terms of the character of the technology, the related ISD practices, and the implicated risks.

| Developing systems (2001-2004)
In early 2001, FinanceCorp approached ISD-org with a very specific request. FinanceCorp was a rapidly growing organization whose growth was primarily due to acquisitions. Consequently, it needed a system to manage inventory and user accounts in terms of information, system, and process rights. At the time, no suitable tools were readily available, so the local ISD-org office allocated 2 of their 10 consultants to develop a web-based network management system, Alpha, for FinanceCorp. Alpha was developed collaboratively on-site using a beta version of Microsoft's .Net environment. It was locally hosted by FinanceCorp, and no maintenance agreement was signed. The unit manager at ISD-org described the initial period as follows: "We had a solution, and we were partially financed by the customers.
We partially financed it ourselves simply because we saw that this was an area where there was a great need and a possibility for us to develop expertise […] If we could develop a solution for this customer and retain the rights to the code, we could reuse it." During the implementation of Alpha, FinanceCorp was bought by another organization, and the requirements changed to include email administration through integration with MS Exchange. Further functionality was added in response to new developments and increased integration of the network technology targeted by Alpha. Alpha was subsequently sold to 5 different customers, in each case as a unique installation that was locally hosted and customized to the specific customer context and requirements. With each new installation, however, the team strove to keep the code base as generic as possible to minimize maintenance costs. Keeping the code base generic also facilitated future market expansion.
In this phase, there were 3 different, albeit interrelated, practices related to the platform-development, support, and sales. A small team of 2 developers was responsible for development, working on-site in close collaboration with the customer. This included all aspects of the development cycle: requirements analysis, customization, installation, and support. With each new project, the team focused on understanding the idiosyncrasies of the customer organization's business practices, thereby increasing the challenge of retaining a generic code base. Influenced by FinanceCorp's ideas of Alpha's potential use, ISD-org cofinanced its development to secure ownership of the code base, a precondition for developing Alpha as a platform rather than a one-off solution. While the FinanceCorp project was a joint venture, the next 4 customers paid for their own solution, and the continued development of the code base was based on the small team's resources because code base ownership was at odds with ISD-org's strategy as consultancy firm: "I was the solution manager, so I designed the solution. The whole time we've had this [standardization] in front of us, because we know that we would never get the support from our organization to develop something like this" (team architect).
There was no clear boundary between development and support, and because no maintenance agreements were signed, the team provided customer-driven, ad hoc, support for the installations, on the basis of time and material contracts. In addition, the team needed to engage in sales to both internal and external customers owing to a recession in the Swedish economy (2000)(2001)(2002). The team members risked losing their jobs unless the sale of Alpha was successful because ISD-org was downsizing throughout the organization. Consequently, during the 2 years after the FinanceCorp installation, the team focused locally on face-to-face meetings with potential customers. They also marketed Alpha nationally within ISD-org to promote the use of Alpha in ISD-org projects outside the local region.
The successful sale of Alpha during this phase ensured that the team members avoided layoffs. The marketing effort within ISD-org gave the team opportunities to share the technical and organizational knowledge generated through the development, support, and installation of Alpha with other ISD-org practices. It also allowed them to establish contacts and develop an understanding of how other areas within ISD-org operated.
Throughout this phase, the team members identified several risks. During the initial development of Alpha, the main risk was immature technology: There were no pre-existing or competing technologies, and no readily available way to meet customer requirements. Consequently, the team had to acquire knowledge about FinanceCorp's organizational needs and the network technology on which Alpha was based. Because of ISD-org's strategy as a consultancy firm, the team also had limited resources to develop the platform; as one team developer put it, "We are consultants and we are supposed to charge for each hour of work that we do for customers […] It messes things up, that we are not a product company that has a budget." In each project, customer requirements had to be negotiated against the team's platform building strategy, so they ran the risk of insufficient customization of the platform because of their long-term strategy of consolidating a generic code base. Beyond these organizational and technical risks, the team faced the risk of being discontinued because both members could be transferred to other assignments at any time, and because as the most junior consultants in the office, they were first in line for redundancy. As it turned out-thanks to their successful development and sale of Alphaboth team members stayed on board while more senior consultants were laid off.
During the first project with FinanceCorp, the PRM risk management model ( Figure 1) highlighted a number of risks and helped the 2 developers, who were both junior consultants at the time, to implement basic project management disciplines. The team's internal and external sales efforts helped address other risks. As Alpha was developed, they identified markets beyond smaller, local companies by looking at ISD-org's internal processes and service production as a gateway to large customers outside the region. This exploration across internal boundaries had a significant impact on the trajectory of the information infrastructure. Finally, the team's development strategy afforded opportunities to cater to both the requirements of different customers and their own requirement to build a sustainable platform. "Throughout, we've had the same basic idea of recycling, that we are able to use the work already performed in one organization in another without us having to re-do everything. I have no doubt: this is the single most important reason for the success we have had" (team architect). Because the team was in control of both customer projects and the code base, they could influence the convergence of the dual requirement sets.

| Developing a platform (2004-2008)
In 2004, the internal marketing efforts paid off, and Beta, a customized version of Alpha, was requested by ISD-org's service production-the channel through which day-to-day ISD-org services were produced for external customers.
Compared with Alpha, Beta had increased connectivity to support network management of multiple data sources but scaled down functionality to align with ISD-org's service production infrastructure. Unlike Alpha, Beta was centrally hosted by ISD-org and customizable for multiple concurrent customers. "When we started working on a proposal for ISD-org service production, we realized immediately that the hard coded configuration approach of Alpha was not going to work as we were supposed to manage 15 to 20 customers at the same time […] We needed to develop something that made configurations less expensive and required less work" (team architect). The central hosting of Beta was made possible to use the existing infrastructure for ISD-org's service delivery as the gateway to external customers. During this phase, 17 external customers either purchased new configurations of Beta or migrated to Beta from other network management systems. This growth highlighted the need to increase Beta's functionality to meet customer demands. However, although the team developed Beta accordingly, ISD-org's service production relied on a conservative strategy without adding the new functionality.
In 2006, the team decided to develop a new version of Alpha, Gamma, prompted by an external technological shift in which the network provider moved towards a more generic and integrated platform. Gamma included extended network management functionality and increased connectivity. Unlike Alpha, Gamma was modularized, allowing for standardization and more efficient configuration. Its development was also an attempt to address the customers' changing needs. Drawing on knowledge and experience gained while working on Beta, the team recognized some customer demands that were not met by ISD-org's service: "We shifted focus from expert users to end users, from administrative functions to configurability […] to support organizational processes rather than administrators. This was a way of keeping costs down and of differentiating us from other solutions that already had larger customer bases" (team architect).
Gamma was hosted by the team, and, during this phase, 4 external customers were enrolled and supported. The Alpha installations from previous years remained active, and, together with Beta and Gamma, the 3 versions were shared across multiple community boundaries and kept open for new components to afford opportunities for customization to a wide variety of contexts. Consequently, the 3 information infrastructure versions were heterogeneous, spanning boundaries of user communities, governance structures, operators, and operations.
During this phase, the information infrastructure was affected by practices outside development, support, and sales. The introduction of Beta increased the importance of ISD-org's service production practices and sales practices at the central level. The development practice changed because of the boundary between the team and end customers; consequently, the team had to rely on second-hand knowledge of contexts and requirements. Beta was developed as an infrastructure component of ISD-org's service production, in close collaboration with the internal customer. This increased the complexity of its development because there were 3 different sets of requirements: those of ISD-org's service production, those of external customers as filtered through ISD-org's service production, and the team's own requirement to keep the information infrastructure code base sustainable. In 2005, the scope of the information infrastructure had grown, and, as a consequence, the team's organization was formalized and a new team member was added. Three team roles were defined-architect, developer, and project manager-to cope with the increasing development and support workload. This helped with managing the important relationship between the team and ISDorg's service production. The initial development of Gamma was financed by the local ISD-org office. Although this decision was at odds with ISD-org's principles, the office made a strategic investment choice: "We have certain possibilities for investments, but we are not supposed to take on any financial risk […] The office had grown and the circumstances were better than a few years earlier. Even though we are a consultancy firm, there are ways of creating opportunities like this. It is also a matter of creating a profile for ourselves within ISD-org. But, by and large, we can only make these shifts within the scope of larger delivery projects, so it's a matter of timing as well" (office manager).
The conditions relating to support and sales also changed and affected infrastructure practices. While Alpha customers were still supported on the basis of informal time and material contracts, maintenance agreements had been signed for Beta, and a maintenance manager was appointed. A team member also worked across boundaries for 2 years, assigned to ISD-org's general service line to support Beta. "The opportunity for me to work on the general service line gave us, as a group, access to a new internal network, and we also became much more involved in the dialogue with the external clients regarding changes and configuration" (team project manager). The team wanted to sign maintenance agreements with all Gamma customers but only succeeded with one customer. In one case, the support of customer-defined functionality was outsourced to another ISD-org office. To reduce costs, the general support line for Gamma was provided by ISD-org's offshore unit in India. The defined roles helped the team focus its efforts and manage its increasingly important relationship with ISD-org's service production. There were ongoing discussions about replacing Beta with Gamma as part of a redevelopment of ISD-org's service. There was also a focus on external sales meetings because external customers paid significantly more per hour than did ISD-org's internal customers. ISD-org's central sales became an important facilitator for the sale of Gamma, and a downturn in the economy created pressure on the team to participate in local ISD-org offices' sales initiatives. This created a boundary between sales and development. "We kind of lost touch with the end customer; instead, the architect and the project manager participated in sales meetings, trying to gather as much information as possible. Let's just say that they didn't bring a lot of documentation back […] This made everything more difficult in terms of development" (team developer).
During this phase, ISD-org's service production practices, including service sales and service development, were increasingly important, not only for Beta but also for the whole information infrastructure. Although the team had a heavy workload managing the many customers of Alpha, Beta, and Gamma, they also had to engage in 2 new local ISD-org projects that were independent of the information infrastructure.
The risks identified by the team members shifted during this phase. In the case of Beta, balancing the dual requirements of infrastructure sustainability and ISD-org service production was increasingly difficult because the team had no direct relationship with the end customer whose processes Beta supported. The way ISD-org's service production viewed Beta also affected the potential for efficient infrastructure management by the team because for new functionality to have any effect on the end customers, the ISD-org services needed to be developed as well. Within ISD-org, there were other competing technologies, both for internal use and for the external customers of ISD-org's service production, as well as boundaries between conflicting goals of ISD-org units. This organizational protectionism was an important risk during the efforts to establish Beta and when subsequently advocating for the integration of Gamma into ISD-org's service production. "It became a threat internally as well, and that's one of the reasons we keep running into opposition. People see this as a potential threat to those working in service production because we can automate what now is done manually […] It becomes really important who you talk to in the organization" (team architect). The team's sustainability also depended on the market scope: It needed Gamma (and Alpha, to some extent) to reach a wider market of external customers because internal sales yielded significantly lower rates than did external ones.
Even though it was mandatory for all project proposals to go through the PRM risk management model (Figure 1), this model had little to do with the risk management strategies that the team used during this phase. Hosting Beta and Gamma centrally was vital to keep the cost of customization and configuration low. The explicit focus on standardization and customization was an important part of the team's risk management strategies, especially in terms of managing the market scope and competing technology risks. "Thanks to our focus on standardization we have had a great advantage. We can actually customize our solution while keeping the price down, no other system could do that" (team architect). Financing the initial stages of Gamma was an important part of managing the risk of multiple requirements and limited control. Knowledge about new technologies and customer demands played a significant role in finding new market niches and continuously developing the infrastructure. "We have some really hungry wolfs here […] The team architect, for example, he is always the frontrunner, eating new technologies for breakfast and always seeing the possibilities with them" (office manager).

| Growing a digital infrastructure (2008-2010)
By 2008, the information infrastructure had grown to 4 external Gamma installations in addition to those based on Beta and Alpha. Gamma now included support for centralized computer and application management, and the team saw Gamma as a potential replacement for Beta within ISD-org's service production. While Beta was an integrated part of the service delivery infrastructure at ISD-org, Gamma competed with other technologies for participation in service delivery projects. The code base was now comprehensive and allowed for customization with only minor development work as part of ISD-org's service delivery projects. During a large project in 2009, the customer requested an end-user portal in addition to the existing administrative focus. In response, the team developed Delta-an end-user interface partially decoupled from Gamma. "Gamma was part of a large project proposal, and it was very important for ISDorg to get this deal. The customer wanted certain functionality that we couldn't deliver with existing technology, and I was assigned to develop what would become Delta. There were competing technologies at the time, but nothing with the specific functionality the customer wanted" (team project manager). Delta offered customers a SharePoint-based interface in addition to the administrative interface provided by Gamma. It was locally hosted, and decoupling the interface from Gamma made it highly configurable to suit end-user preferences without the constraints of the underlying layers. Outside this project, Delta was sold to 2 external customers during this period.
The introduction of Gamma and Delta increased the number of practices related to the information infrastructure and affected the way the team worked on development, support, and sales. ISD-org had developed its services, and both Gamma and Delta competed with other technologies to be part of the organization's service delivery projects.
The team saw Gamma as a replacement for Beta and pushed its development in that direction in every project. To ensure efficient customization and support, there was a sustained focus on modularization and standardization. In terms of functionality, the development of Gamma and Delta was based on extensive team experience and knowledge. "10-15 of ISD-org's largest customers are in Sweden-I've configured those installations, so we have a pretty good grasp of the requirements now. We have built up a knowledge base over these ten years, and we're always on the lookout for where things are heading" (team project manager). The team grew from 3 to 15 members as the number and scale of projects increased, and ISD-org's offshore team was used as an additional development resource. As a consequence, the need for coordination and task specification across boundaries grew significantly, and the control over infrastructure development declined.
The team was involved in several parallel projects in which they no longer controlled customer requirements. "We are too far away from the customer nowadays […] That makes it really hard for us […] Other people interact with the customer and it's hard for us to know what exactly we are supposed to be doing" (team developer). The development of Delta was separated from Gamma as it was seen as a high-risk project that had the potential to help ISD-org establish a new large customer. Successful sales of the infrastructure were still vital for the team and were primarily organized and implemented by the architect and the project manager as part of other engagements.
Gamma's functionality and customizability had made it the "go to" technology for ISD-org service projects.
However, after successfully completing the test period in a large project that included both Gamma and Delta, Gamma was suddenly terminated by the firm's management. In an unrelated ISD-org service production project, the Service Desk at ISD-org decided to adopt a competing technology for the administration of employee information and access control. Since the Service Desk was an important part of ISD-org's service production, Gamma was in effect dropped from all ISD-org service delivery projects. However, the Delta project, despite building on the Gamma workflow and integration logic, remained unaffected.
The risks identified by the team were, to a large extent, connected to increased infrastructural complexity and team size. As the team became part of large-scale projects, they became increasingly dependent on other actors and subprojects for information and specifications. They also had to balance the multiple requirements of end customers, ISD-org's service production and service delivery projects, and the information infrastructure itself, all while depending on second-hand information about customer requirements for ISD-org service projects. As the team expanded, they identified knowledge transfer as a risk: "In 2008, when we began letting new developers in we kept a lot of it in our heads, so there was definitely a threshold […] I think the quality has gone down a lot. You can't blame the new developers, I mean, they didn't have any specs. They did their best. And the project manager had to focus on sales, sales, and sales. It was a difficult situation" (team developer). As the situation became increasingly complex, so did the dependence on key members. While the strategy for managing the increased workload of key members had been to expand the team, they had no strategies for coping with the risks resulting from the expansion. Nevertheless, to manage the growing information infrastructure and find new opportunities, the team continued with the strategy of standardization and modularization of the infrastructure components.

| DISCUSSION
Building on a longitudinal case study of risk emergence in IT service provisioning at ISD-org, we investigated how ISD professionals identified and managed risk. While emergence has long been established as a salient feature of IT use in the literature (Robey & Boudreau, 1999;Truex et al., 1999), it has only recently been recognized in the IS discourse on risk. Work on information infrastructure theory and the introduction of side effects (Ciborra et al., 2000;Hanseth et al., 2001;Henfridsson & Bygstad, 2013) and systemic risks (Carlo et al., 2004(Carlo et al., , 2012Hu et al., 2012) has opened up the discourse in important ways. Understanding risk emergence as a consequence of situated complexity and uncertainty, we traced how changes in ISD practices, technological characteristics, and structural conditions impacted the locus and origin of salient risks. We found that IT risks at ISD-org were typically interstitial; ie, they emerged over time and originated between established ISD practices. The longitudinal character of the study and the intimate access to data afforded by the insider-researcher allowed us to explore in detail the emergence of risks and the origin of their emergence, ie, how they moved from being primarily immersed within practices to being primarily interstitial in nature. This revelation of IT risk emergence as interstitial extends the literature by detailing how the origin and locus of salient risk changes as a result of the interplay between practice, the nature of technology, and structural conditions.
Our findings demonstrate how 3 general types of practices interacted to shape the evolution of the information infrastructure and the associated risk emergence: customer practices, internal practices, and exogenous practices ( Figure 3). Throughout the 10 years of ISD service provisioning at ISD-org, varying levels of IT risk were introduced by the increasingly complex interplay between constituting activities and related conditioning structures. Although the nature of the relevant technology evolved significantly over the studied period, from isolated systems to platforms and digital infrastructures, the structures at ISD-org did not. At all times, projects were the primary organizational structures within the firm, and a consultancy logic dictated the funding and governance of operations. As a result, the ISD team and their practices became increasingly dependent on other types of practices. Notably, the formal risk management method offered less and less support as the situation unfolded. Consequently, during the development of Gamma and Delta, team practices became dependent not only on ISD-org service production practices, infrastructure, and end customers but also on a range of customers independent of ISD-org's service production, each with their own customized versions of Alpha, Beta, Gamma, or Delta.
Adopting a practice lens (Feldman & Orlikowski, 2011;Marabelli & Newell, 2012) helped us identify the sources, tensions, events, and interactions that caused risks to emerge. We identified 3 main types of interstitial IT risks. First, risks emerged in the interstices of different spheres of authority. Interstitial IT risks of this kind are identified by actors involved in a practice, but these actors cannot control the risks without negotiating with related practices. As the character of technology evolved from the development of isolated systems to platforms and digital infrastructures, the ISD context became increasingly polycentric (Constantinides & Barrett, 2014;Mindel & Mathiassen, 2015). The ISD-org development team therefore had less and less control over issues directly related to the risks they identified.
With Beta, they lost control over the development of the code base in terms of functionality to ISD-org's central FIGURE 3 Information systems development risk forces service production, and they were forced to develop Gamma to manage the risk of not meeting changing customer demands. Working through ISD-org's service production, they also lost control over customer requirements in the project. The team identified this as a major risk but was unable to manage it within their development practice or through negotiations with other ISD-org service production practices.
Second, risks emerged in the interstice of diverging goals or interests. Information technology risks of this kind are difficult to identify because they emerge in the blind spots between the goals of related practices. The ISD context became increasingly multivocal (Bernardi, 2009) as the number of stakeholders with different goals, needs, and knowledge grew during the different phases, increasing the levels of complexity across projects (Kang et al., 2017).
For example, following their previous strategy, the team focused on end customer demands as a strategy for platform development and spent internal resources on developing a new version of the platform for the next generation of ISD-org service deliveries. However, ISD-org's service production had other goals, leading to the termination of Gamma during a large project and the selection of a competing platform for service delivery by Weilgo. The termination of Gamma created a situation where the team relied on old and insufficient knowledge of related practices and structural dynamics, making them unprepared for the way events unfolded. The decoupling of Delta from Gamma turned out to be vital for the infrastructure's survival, but ironically, it was a serendipitous consequence of ISD-org's policy of not taking on financial risks rather than the result of explicit design efforts.
Third, risks emerged in the interstices of spheres of knowledge, both lateral and temporal. This type of risk is difficult to identify and manage because both of these processes build on extant knowledge within practices. Our case shows how experienced individuals were able to bridge these gaps, but also how increased specialization, division of labour, and multiple dependent and interdependent practices increased the manifestations of such risks. ISD-org is a consultancy firm, and most of the studied work was done within the scope of projects financed by customers. From an organizational standpoint, every project was more or less regarded as an isolated entity. This was a source of risk for the longterm sustainability of the team and its technology. One associated risk related to knowledge transferability between projects. As long as the team consisted of 2 to 3 consultants, knowledge transfer was not a problem because the consultants collaborated closely and all members of the team participated in all projects and related practices. As the infrastructure grew, team roles were designed and implemented to cope with the heavier work load, and different practices (development, support, and sales) were more clearly defined. This affected knowledge transfer because the consultants became more specialized. However, it was the team's rapid growth to 15 consultants that highlighted the knowledge transfer risk. Experiences from previous projects and the shared understanding of the platform were largely not documented or formalized. This made it difficult for new team members to perform at a high level. Paradoxically, growing the team increased the workload of, and dependency on, key team members-especially since the digital infrastructure at this point was so complex. This interplay between structural conditions and practices shows how the effects of a single structural condition, ie, the project, can differ depending on practices and related structural conditions.
Our theory complements existing research by considering how information infrastructure risks emerge. Whereas previous theories explain why information infrastructure risk emerges quite well (Ciborra et al., 2000;Hanseth & Ciborra, 2007;Hanseth, Jacucci, Grisot, & Aanestad, 2006), we have shown in detail how it emerged at ISD-org by tracing the interplay between reality and possibility, ie, between the evolving nature of technology and the knowledge, goals, interests, and reach of interrelated ISD practices. Our study shows how the origin and locus of risk in the ISD service provider setting moved from within structures and practices to being centred on the interstices between them as the technology became increasingly interconnected and complex. The notion of interstitiality is related to both side effects and the notion of systemic risk. Even though risks can be systemic, in that a failure or risk in any part of the infrastructure can propagate to the whole (Hu et al., 2012), systemic risks do not originate in the interstices between practices or structures. Conversely, an interstitial origin does not necessarily imply that risk is systemic because it does not always propagate throughout the network of interconnected practices. Similarly, while side effects are a fundamental part of the dynamics of information infrastructure evolution (Hanseth et al., 2006), they are reflected back onto the specific actions that triggered them, which may or may not be interstitial. The notion of interstitiality relates to the specifics of the origin and locus of risk in information infrastructures and can thus help focus the attention of both researchers and practitioners onto sources of risk not otherwise captured by current risk management methods, frameworks, or tools.
The recognition of interstitial sources of risk thus offers new insights into IT risk management theory and practice.
It questions the conventional wisdom of focusing on project-level analysis and extends our understanding of the limitations of risk lists (Bannerman, 2008;Barki et al., 2001). Moreover, it calls into question the ontological assumption of risk in the IS discourse and highlights the importance of reflexivity in both research on and the practices of risk management in ISD (Mathiassen, 1998). To identify relevant risks and find novel ways of managing them, IT professionals must be reflexive, must reassess their practices and the context of those practices, must approach risk management at levels other than those of models and projects, and must actively transform knowledge from outside their own practice context. Indeed, risk management must become a primary practice in its own right for ISD risk to be effectively identified and managed.
As with any research, this work has limitations. Our single qualitative case study design limits our ability to generalize and requires careful attention to data collection and analysis. As a result, we adopted systematic data coding and analysis procedures on the basis of our analytical framework (Table 1). Also, to manage the risk of retrospective bias, we triangulated using several different techniques and sources (see Figure 2 and Table 2). However, single qualitative case studies can and should go beyond idiosyncratic insights and explanations, so we leveraged our empirical investigations to advance new perspectives on managing information infrastructures and IT-related risks (Mason, 2002;Walsham, 1995;Yin, 2013).
In doing so, we have interpreted the empirical material from the perspective of information infrastructure and risk practices. However, the application of other theories (possibly drawn from the literature on IT capability and governance) could potentially have highlighted additional interesting aspects of the case.

| CONCLUSIONS
Risk is concerned with the effects of complexity and uncertainty on objectives or goals. Where practices intersect, multiple-often conflicting-goals are in play. This work presents a longitudinal study of IT risks as they manifested in practices related to ISD service provisioning at a large consultancy firm. Our analysis shows that as the nature of technology evolved and grew in complexity, new and important risks emerged at the interstices between different but interdependent internal, exogenous, and customer practices, and between spheres of authority, spheres of interest, and spheres of knowledge. We characterized the origin of these risks as interstitial because they manifested between practices and outside the scope of established risk management approaches. As a result, this work extends the literature on emergence in IT risk research and contemporary ISD risk research.