Managing Risk Areas in Software Developm Offshoring: A CMMI Level 5 Case

Abstract

Software companies are increasingly offshoring development to countries with high expertise at lower cost. Offshoring involves particular risk areas that, if ignored, increase the likelihood of failure. However, the offshoring client's maturity level may influence the management of these risk areas. Against this backdrop, we present an interpretive case study on how managers perceive and mitigate the risk areas in software development offshoring with a mature capability maturity model integration (CMMI) level 5 software company as the client. We found that managers perceived and mitigated most of the offshoring risk areas in accordance with the findings of previous research. However, the risk area of task distribution was a notable exception. In this case, managers perceived high task uncertainty, equivocality, and coupling across sites as risk mitigation rather than risk taking. The paper discusses how and why managers perceived and mitigated the risk areas in this way and the implications for theory and practice in software development offshoring.

Headnote

Abstract:

Software companies are increasingly offshoring development to countries with high expertise at lower cost. Offshoring involves particular risk areas that, if ignored, increase the likelihood of failure. However, the offshoring client's maturity level may influence the management of these risk areas. Against this backdrop, we present an interpretive case study on how managers perceive and mitigate the risk areas in software development offshoring with a mature capability maturity model integration (CMMI) level 5 software company as the client. We found that managers perceived and mitigated most of the offshoring risk areas in accordance with the findings of previous research. However, the risk area of task distribution was a notable exception. In this case, managers perceived high task uncertainty, equivocality, and coupling across sites as risk mitigation rather than risk taking. The paper discusses how and why managers perceived and mitigated the risk areas in this way and the implications for theory and practice in software development offshoring.

Keywords: Distributed Software Development, Case Study, CMMI, Scrum, Agile Methods, Offshoring, Risk Management, Global Software Engineering.

1 Introduction

Global competition, the need for flexibility, new types of expertise, and cost reduction drive software companies to engage in offshoring (Lacity, Khan, & Willcocks, 2009; Stephan & Silvia, 2008). Successful offshoring requires an organization to effectively manage temporal, geographical, and sociocultural distances (Holmstrom, Conchúir, Agerfalk, & Fitzgerald, 2006) and the many other challenges associated with software development in general. Managers deal with specific offshoring challenges in terms of risk areas in software development offshoring (Iacovou & Nakatsu, 2008; Lamersdorf et al., 2012; Persson & Mathiassen, 2010; Singh & Nigam, 2012). Risk areas represent organizational contexts that include many related risk factors, which together possess a threat to a software development project's success (Boehm, 1991). Persson, Mathiassen, Boeg, Madsen, and Steinson, (2009) argue that eight risk areas are central to managing distributed software development: task distribution, knowledge management, geographical distribution, collaboration structure, cultural distribution, stakeholder relations, communication infrastructure, and technology setup. These risk areas represent the organizational contexts of particular concern to managers of software development offshoring, but, as with any other risks, they are not objective facts (Hansson, 2010). The organizational conceptions of risks derive primarily from what managers consider to be of value both in and for their organizational practice (Corvellec, 2010). What managers consider to be valuable and, thereby, possibly at risk follows from what they consider to be necessary to the success of their managerial practice (Corvellec, 2010).

CMMI and Scrum are prescriptive approaches for successful software development that are highly influential to managerial practice in software companies. CMMI (CMMI Product Team, 2010) includes governing principles and operational elements in a five-level maturity model for software development that range from initial, managed, defined, and quantitatively managed to optimizing at the highest level. Scrum is an iterative and incremental development model where planning is concurrent with the development activities. Studies suggest addressing offshoring risk areas by 1) elevating the organizational maturity of the client in terms of the CMMI (Rottman & Lacity, 2006) and 2) adopting Agile methods such as Scrum (Bannerman et al., 2012). Offshoring managers' perceptions and mitigations of the proposed offshoring risk areas (Persson et al., 2009) follow from what they consider to be necessary to their managerial practice's success. However, little research focuses on how offshoring risk area perception and mitigation follows from managerial practice when the offshoring client is a software company certified at the highest maturity level and also using Scrum. Research on risks and risk mitigation in offshoring and global software development focus on the vendor environment and we lack research that also focuses on the client organization (Verner, Brereton, Kitchenham, Turner, & Niazi, 2014).

We present a case study of how software development managers from the mature software company Systematic and from their offshoring vendor Conscensia consider risk areas both in and for their offshoring practice. In 2005, Systematic reached and has since sustained a CMMI level 5 certification, one of the few European companies to do so (Pries-Heje, Nørbjerg, Aaen, & Elisberg, 2008). Systematic initiated cooperation with the offshoring company Conscensia in 2010. This offshoring relationship provides a unique case for investigating how managers perceive and mitigate risk areas both in and for their offshoring practice involving a mature software company. We address the following research question:

RQ: How do managers perceive and mitigate the risk areas in software development offshoring from a mature (CMMI level 5) software company?

This paper is organized as follows. In Section 2 and 3, we introduce the theoretical background on software development offshoring and risk management. In Section 4, we describe the offshoring case and our interpretive case study approach for collecting and analyzing data. In Section 5, we analyze the managers' perceptions and mitigations of risk areas and identify two risk areas where managers' perceptions and mitigations deviate from the suggestions in the literature. In Section 6, we discuss how our analysis answers the research question and the contributions, implications, limitations, and directions for future research.

2 Software Development Offshoring

Offshoring leverages resources from a different country but in the same company, while offshore outsourcing leverages external third-party resources situated in a different country (Smite, Wohlin, Galvina, & Prikladnicki, 2014). In software development, these external resources can apply to everything from using contract programmers to third-party facilities management. Offshoring setups may pursue high levels of cohesion, interdependency, and integration, while other setups pursue high levels of independence and low coupling among sites. In the pursuit of high cohesion, companies may co-locate software developers (Persson, 2013; Smite, Wohlin, Gorschek, & Feldt, 2010), adopt Agile methodologies (Jalali and Wohlin 2012; Persson et al. 2012), and strive for virtual team setups with high levels of trust (Siebdrat, Hoegl, & Ernst, 2009; Søderberg, Krishna, & Bjørn, 2013). In general, both co-located and offshore processes for software development conceptualize the ideal practice at the operational level differently.

CMMI (CMMI Product Team, 2010) promotes an ideal method to develop software and is based on five levels of maturity: initial, managed, defined, quantitatively managed, and optimizing. Elevating CMMI certification in the client organization is a best practice in offshoring for closing the process gap between a client and its supplier organizations (Rottman & Lacity, 2006). More than half of the worldwide companies certified at level 5 are located in the popular offshoring destination of India, but offshoring to a level 5 supplier provides no guarantee of successful outcomes (Matloff, 2005). Furthermore, we have limited knowledge about software development offshoring with a certified level 5 company.

CMMI is, in some cases, combined with Agile methods even though the two approaches may contradict each other in some aspects (Persson, 2010; Santana et al., 2009; Turner & Jain, 2002). The case at Systematic presented in this paper documents a successful combination of CMMI level 5 and the Agile method Scrum (Sutherland, Ruseng Jakobsen, & Johnson, 2008a). Scrum is an iterative and incremental development model in which planning occurs concurrently with the development activities, and the product owner divides the work into biweekly or monthly sprints. Each sprint is planned to be self-contained, which leads to a constantly new running version on the road to the final software product (Jakobsen & Sutherland 2009). Agile project management with Scrum in co-located settings may have a positive perceived impact on productivity, quality, and employee satisfaction (Kautz, Johansen, & Uldahl, 2014). Scrum and Agile methods in general involve a high cohesion approach to offshoring with several accounts of success (Bannerman, Hossain, & Jeffery, 2012; Jalali & Wohlin, 2012; Persson, Mathiassen, & Aaen, 2012; Sutherland, Schoonheim, Rustenburg, & Rijk, 2008b).

A high CMMI certification or the adoption of Agile methods does not guarantee successful offshoring. Managers still need to pay attention to the many risks associated with offshoring. In Section 3, we present the theoretical background on risk management in software development offshoring. Based on the literature on risk management, we argue that managerial practice (that can be based on the CMMI and Agile methods) not only is influenced by but also influences offshoring risks in how they are perceived and mitigated.

3 Risk Management

A software risk denotes an aspect of a development task, process, or environment that, if ignored, increases the likelihood of a project's failure (Lyytinen et al., 1998). Both domestic and offshore outsourcing in software development involve risks (Nakatsu & Iacovou, 2009), and a large body of research has investigated the risks particular to offshoring and distribution (Verner et al., 2014). Numerous approaches are available for managing software risks (e.g., the eight presented by Keshlaf and Riddle (2011) in their development effort of a ninth approach for distributed settings). Their ninth approach adds to other research efforts that propose risk frameworks for offshoring and distributing software development (Iacovou & Nakatsu, 2008; Lamersdorf et al., 2012; Persson & Mathiassen, 2010; Singh & Nigam, 2012).

Persson et al. (2009) present a framework compatible with CMMI (Persson & Mathiassen, 2010) that systematically integrates a decade of research on global software, virtual teams, distributed projects, and outsourcing into eight risk areas. Risk areas represent organizational contexts that include several related risk factors, which together possess a threat to a software development project's success (Boehm, 1991). The eight risk areas (Table 1) are each an abstraction of three risk factors (Persson et al., 2009) that pay explicit attention to all of the four basic socio-technical components of organizational change (Lyytinen et al., 1998). The four socio-technical components of task, structure, actors, and technology (Leavitt, 1964) highlight how a risk management approach shapes managers' attention in software development (Lyytinen et al., 1998).

The framework proposes a structured risk assessment of the eight risk areas in Table 1 as a collaborative risk management activity in distributed projects (Persson et al., 2009). Objectifying risks in such a way is, however, not the only way of viewing risk assessment. The risk assessment literature has a growing awareness that risk cannot be reduced to an objective fact but rather that it involves psychological, social, cultural, and political dimensions (Corvellec, 2010). This awareness can be traced back to March and Shapira (1987) who, in investigating managerial perspectives on risk and risk taking, found that the way managers think about risk does not easily fit into classical theoretical conceptions (March & Shapira, 1987). Thus, research need attend to not only "what is risk?" but also "how managers understand something as a risk?". This is a shift in research attention from the nature of risk per se to risk as a social phenomenon (Boholm & Corvellec, 2011).

Conventional risk assessment procedures view risk as a kind of uncertainty that originates in an adverse event and that should be addressed in formal and scientific terms. Risk involves the loss of some, more or less explicit, value. However, value is never self-evident, unproblematic, or indisputable. Risks emerge from the process of attaching value to something. In organizations, this involves paying particular attention to managerial practice. What managers consider to be valuable and, thereby, possibly at risk, follows from what they consider to be necessary to their managerial practice's success. Corvellec (2010) argues that risk is based on how managers value things, what they consider should be done, and how it should be done. From this view, the risk areas that Persson et al. (2009) propose imply assumptions about what managers should value in software development offshoring. Persson et al. (2009) present an implicit concept of value from synthesizing research on what is necessary to managerial practice's success. However, risks and their related values are variable. What is a risk for some can be a valuable end to others. Likewise, the risks of today may become valuable ends tomorrow (Boholm & Corvellec, 2011). Thus, to improve the risk frameworks for helping managerial practice such as the one by Persson et al. (2009), research should also explore how managers perceive and mitigate the risk areas related to such a framework. Researchers can use conceptual risk frameworks for analyzing insights from explorative studies of managerial practice. In this case study, the managerial practice is particularly relevant because it takes place in software development offshoring from a mature (CMMI level 5) software company. The uniqueness of the case makes it an interesting contribution to the large number of previous case-based research works on systems development and outsourcing (Gordon, Blake, & Shankaranarayanan, 2013).

4 Research Approach

In this section, we present the case and its related context and explain how we collected and analyzed the data. The case study approach was, in the terms of Cavaye (1996), a single case with the interpretive use of qualitative data for discovery. An interpretive approach is particularly useful when addressing problems with a dominant social or cultural dimension, such as those frequently encountered when studying work practices in a globally distributed team setting (Clear & MacDonell, 2011). This interpretive research approach allowed us to investigate the management of offshoring in its organizational and cross-cultural context as socially constructed and, thus, open to several interpretations by organizational actors and us as researchers (Klein & Myers, 1999; Walsham, 1995; Walsham 2006). This research approach concurs with the study's social constructionist view of risks (Boholm & Corvellec, 2011; Corvellec, 2010) because, to understand risk definitions, risk researchers should delve into the logic of practice, analyze how people (managers) organize their experience, and follow how they navigate their everyday lives (Boholm & Corvellec, 2011).

4.1 The Case

Systematic is a software company, established in 1985, with more than 450 employees in offices in Denmark, the United Kingdom, the United States, Australia, Germany, Finland, and Sweden. It is the largest privately owned Danish software development company and one of the few European companies that has reached and sustained a CMMI level 5 certification (Pries-Heje et al., 2008). Some government customers require a high maturity level. Its later addition of the Agile method Scrum in 2006 supposedly reduced every category of work (defects, rework, total work required, and process overhead) by almost 50 percent (Sutherland et al., 2008a).

Systematic initially outsourced development activities offshore for some years, primarily with a cost reduction focus, with varying degrees of success. In 2010, it initiated cooperation with the offshoring provider Conscensia. Conscensia is a Danish company, established in 2006, that sells the facilitation of software development offshoring to Ukraine (cities of Lviv and Kiev). In autumn 2012, Systematic bought 25 percent of Conscensia. This decision follows the evolutionary framework for establishing and progressing client-vendor relationships in offshore software development that result in ownership to retain control (Clear, Raza, & MacDonell, 2013; Mirani, 2006). This part ownership blurs the clear distinction between offshore insourcing and outsourcing (Smite et al., 2014), which is why we name this case offshoring. Conscensia markets its service as nearshoring; however, the Smite et al. (2014) taxonomy suggests that this case is farshoring because more than 2 hours flying time are involved. Nearshoring involves a flying time less than 2 hours, which makes it possible to travel back and forth in a day and still have time for a 3-4 hour meeting (Smite et al., 2014). However, the time difference is small with 4 hours or less, which allows at least half of a normal workday to be overlapping.

The case study followed one of the divisions of Systematic that develop a main product line of missioncritical software. At the time our study, the division had more than 100 software engineers in seven groups, all divided into one or more teams. Each team was staffed by both Danish and Ukrainian developers. We focus on two teams: Team F (20 persons, seven in Ukraine) and Team H (35 persons, 10 in Ukraine). The Ukrainian software engineers resided in facilities belonging to Conscensia. Conscensia provided offices including infrastructure and recruits competences matching clients' needs in relation to both technical and interpersonal skills. Other human resource services for software engineers included local facilitation by coaching, cultural training, career advice, and assistance with communication between the teams across countries. In Lviv, Conscensia had two delivery managers (A and B) that answer to the vice president (VP) of global delivery and a chief operating officer (COO) with reference to the chief executive officer (CEO). The CEO and VP were located in Denmark. A local IT department manager, a recruitment manager, and a career advisor support the COO. In all, more than 100 developers were located at the Lviv premises.

The two Systematic teams, supported by delivery manager A, developed mission-critical software based primarily on .Net and Java. Both teams applied Scrum in their development process and sat in their own open plan offices at each location. The teams used Intelli/IDEA as the integrated development environment (IDE), rational team concert (RTC) to manage source code, and concurrent version system (CVS) to manage documentation. Lync facilitated the majority of communication, such as live calls and shared screens. Scrum meetings were held daily in the morning for 15 minutes in dedicated rooms using large screens and laptops showing each other's environments. A project manager, a product manager, and a Scrum master for each sub-team were central to the team's organization.

4.2 Data Collection

We collected data including document studies and individual semi-structured interviews with team members and management from both Systematic and Conscensia (Table 2). We initiated the case study through informal meetings with managers in Systematic (in Denmark) and Conscensia (in Ukraine) in spring 2012. To obtain an overview of the overall organization, we carried out exploratory interviews with managers and developers in early summer 2012 in Lviv. We developed an interview guide based on this explorative phase focused on their offshoring challenges and mitigation strategies (all guides are available in Appendix A). This guide supported our semi-structured interviews in Lviv and Aarhus in autumn 2012 and spring 2013. After the pilot interviews conducted with managers of Conscensia and two software engineers, we made several changes to the interview guide, such as framing and focusing questions for software professionals. These interviews furthermore helped explain the environment and challenges the organizations faced. In addition, they helped identify additional candidates for interviewing. In general, we followed Myers and Newman's (2007) recommendations for qualitative interviewing by situating ourselves as actors, minimizing social dissonance, representing various voices, using inclusive interpretation, mirroring questions and answers, using flexibility, and ensuring the confidentiality of disclosures.

The interview protocols developed over time. Protocol 1 was explorative but used the terminology from Lacity et al. (2009). Protocols 2 and 3 focused on cross-site projects and cooperation, whereas protocol 4 was informed by our observations of work practices and tools seen during earlier interviews.

We interviewed four members of each team with different roles and nationalities and managers from Conscensia and Systematic. After interviewing the Danish side of the case, we interviewed the Ukrainian side once more to qualify the observations and challenge the provisional findings (Table 2). Each interview lasted from 40 to 60 minutes, was recorded, and was fully transcribed verbatim. To ensure correct information regarding, for example, the use of technology and to maintain good relations with interviewees, we verified the transcriptions with the interviewees. In all, we conducted 19 interviews combined with informal meetings. In addition to the interviews, we took pictures of the premises (offices and facilities for Scrum meetings) and collected supporting documents such as organograms, workplace sketches, presentations, and product descriptions.

To ensure we had alternative interpretations and questioning of the findings (Klein & Myers, 1999; Myers & Newman, 2007), the two researchers interviewed individually to take advantage of their different backgrounds and experiences. Both researchers are Danish computer scientists and professors in information systems (first author specialized in systems development, second author in management and implementation). In addition, the second researcher is an honorary professor at a leading Ukrainian Business School and has established a reasonable insight into the Ukrainian context through years of close contact.

4.3 Data Analysis

We analyzed the interview transcripts and documents to uncover the involved participants' attention to or mitigation of risks related to offshoring. We searched for deviations from established theory by approaching the analysis as a critical dialog between the theoretical frameworks presented in the background section and our empirical work (Alvesson & Kärreman, 2007). The inference mechanism that guides this kind of theory development is labeled abduction.

To identify incidents, mitigations, or perceptions related to offshoring risks, we searched and coded the transcripts in NVivo (Bazeley, 2007). We coded statements pertaining to offshoring risks and grouped them to reveal patterns or other findings. This coding did not emphasize explicit statements of something being a risk but rather what the different stakeholders considered to be necessary to the success of managerial practice (Corvellec, 2010). We compared these value positions to the generic risk areas for distributing software development (Persson et al., 2009) presented in Table 1. When we classified the statements, we went back to the transcription and re-read the contexts in which the statement and related statements were given. Based on this, taking potential conflicting observations into consideration, we formulated the risk taking and risk mitigation approach in the case. In this way, our analysis was not an attempt to formulate new risk areas or make a comprehensive risk mapping but rather to explore and explain managerial practice (Corvellec, 2010) related to some generic risk areas (Persson et al., 2009).

For further triangulation, managers in Systematic and Conscensia reviewed the analyses at a meeting attended by the vice president, delivery managers, and interviewed software developers. This review provided some more alternative interpretations and questioning of the findings (Klein & Myers, 1999). For example, how the roles of Conscensia employees in finding and recruiting competences that match clients' needs in relation to both technical and interpersonal skills support the dynamics of the offshoring setup and the inherent task distribution capability. The review also resulted in revisions regarding the history of the cooperation. In Section 5, we present our findings related to the eight risk areas (Table 1) for software development offshoring.

5 Findings

In this section, we present managers' perceptions and mitigations of risks in the Systematic / Conscensia case. Managers were notably consistent in their accounts of managerial practices across the two organizations and at the different levels. Thus, our analysis focuses on discrepancies with the research literature rather than among the managers (Alvesson & Kärreman, 2007). For each of the eight risk areas in Table 1, we identified the level of risk according to the framework and the associated perspective in the case (Table 3) from the interviews with management. Furthermore, we present the two main risk mitigation initiatives for each risk area in Table 3.

Three risk areas (task distribution, knowledge management, and stakeholder relations in Table 3) call for special interest since the managerial practice represents a high level of risk according to the framework (Persson et al., 2009), yet the managers did not perceive it as such. Below, we analyze these three risk areas in more detail.

5.1 Task Distribution

Systematic's managerial practice of intentionally providing very limited specification of development tasks for the Ukrainian site is, according to the framework (Persson et al., 2009), a high-risk strategy for the task distribution risk area. Limited specification requires extensive cross-site coordination for carrying out development tasks, which managers should avoid according to Persson et al.'s (2009) framework. The sourcing manager at Systematic stated:

When talking about outsourcing, you tend to forget what the task is about. It is about a team that produces software together. Then, they may sit in different places and talk different languages, but that does not change the basic task of collaborating on making software. We would never write a large requirements specification and throw it after someone internally. We would never ask a customer for a large requirements specification and then ask them to stay away. Why should you do that just because it's outsourcing.

In Systematic, the managers argued that the limited specification of the tasks that the Ukrainian developers would perform was beneficial for the process since it promoted local understanding and engagement and forced cross-site team integration through dialogue: "their contribution is simply larger" (Systematic department manager) and "there shall not be more Ukrainians than Danes, all should be integrated into teams, able to fulfill all tasks" (Systematic project manager). This attitude towards task distribution led to more engaged Ukrainian software engineers and a more productive environment: "they appreciate getting more responsibilities...and I believe that in the future they will be more engaged in training new colleagues" (Systematic project manager).

Daily Scrum meetings by video-conferencing appeared to support the management of high task uncertainty. This support was combined with well-defined processes and the division of responsibilities as imposed by Systematic's CMMI level 5 structure. Thus, the cross-site teams managed high task uncertainty and equivocality by establishing a high certainty for working with these tasks. Furthermore, they coped with high task coupling by establishing high coordination and collaboration capabilities, which is reflected in the pursuit of low risk for the risk area related to this (see the collaboration structure in Table 3) and supported by the Conscensia delivery manager A, who constantly monitored and coached the working processes.

5.2 Knowledge Management

Following Persson et al. (2009), the managerial practice in Systematic represents a medium risk by mainly creating and capturing knowledge on the client side as opposed to all sites contributing equally as Persson et al. (2009) suggests. The sourcing manager at Systematic stated: "We must get our domain experts to visit Ukraine; the more Ukrainian team members know, the better....it matters in the daily small decisions how things works in the larger context". Furthermore, a Systematic project manager argued that the limited knowledge integration should be reduced as "it would be nice to have more local domain knowledge...we must improve that". The limited creation of knowledge on the Ukrainian side exposed Systematic to further risk of losing Ukrainian staff due to their desire to learn more: "a small issue related to their career development, they can't get to know everything...the best of them (can) be lost at the top....we have decided to accept that risk" (Systematic department manager). Thus, managers at Systematic were less coherent in their understanding of the knowledge management risk area and its need for mitigation. Our analysis also suggests that managers pursued the medium-risk exposure on knowledge management less intentionally compared with task distribution.

Systematic approached the knowledge management risk area in several ways. Managers sent domain experts to Ukraine to train the local staff. However, Systematic also benefitted from partially owning Conscensia. This ownership assures that knowledge (e.g., about processes) will not be lost and can be influenced indirectly at the board level. At the same time, Conscensia assists in staff retention by providing alternative employment and career paths for Systematic team members when needed. This reduces the risk of losing knowledgeable staff. Thus, the Systematic / Conscensia setup mitigates the risks in managing the creation and integration of domain knowledge by strong management and the structuring of process knowledge.

5.3 Stakeholder Relations

The managerial practice of maintaining some differences between sites and the attitude of staff towards colleagues from other sites, even though they recruited team-oriented staff, represents a low/medium risk in the framework. This difference is especially visible in two areas. First, trust was not directly mirrored: "it seems that in Denmark trust has a swift nature, whereas in Ukraine....trust must be earned" (Systematic sourcing manager). Second, there was a difference in how fast Danish and Ukrainian software engineers were up to speed and in the sub-teams' own understanding of how effective they were. Managers in Systematic perceived Ukrainian developers as cheap but also slower compared with the more expensive engineers in Denmark. Conscensia assisted Systematic by providing local cultural training and mediation.

To monitor and be able to react to any decreasing levels of trust and satisfaction, Systematic performed biweekly online surveys among staff (both Ukrainians and Danes). One of the issues identified during these surveys and related performance talks was to remember to share customer and product stories with the Ukrainian side as done in the Danish offices. Thus, Systematic managers mitigated the offshoring risk area of stakeholder relations by treating Ukrainian and Danish developers as equals, while still maintaining differences in trust, identity, and integration.

5.4 Integration of Risk Areas

We identified three risk areas where Systematic's managerial practice represents a medium or high risk that involved a different risk perception and mitigation to that proposed in the literature (Persson et al., 2009). What emerged from our analysis of managerial practice in the Systematic / Conscensia offshoring case was a strong integration among the risk areas and their associated mitigation. Thus, instead of associating the managerial practices for mitigation with individual risk areas as in Table 3, we propose using the relations between the four socio-technical components (namely, task, structure, actors, and technology (Leavitt, 1964)) that underlie the eight risk areas in the framework (Persson et al., 2009). In the Systematic / Conscensia offshoring case, the managerial perception of the task-related risk areas involved task uncertainty, equivocality, and coupling as mitigation rather than risk taking. This perception was, however, associated with managerial practices that integrate the task with the structure, actors, and technology-related risk areas. Figure 1 shows how the managerial practices integrated the risk area components using the risk mitigation practices presented in Table 3.

The managerial practices shaping the perception and mitigation of tasks integrated the task not only with the three other socio-technical components but also among them (Figure 1). Each of the managerial practices that integrates the four components can individually explain the managerial perception and mitigation of task-related risk areas. However, together they formed a socio-technical system that provides a much more comprehensive explanation of what these managers considered to be necessary to the success of their managerial practice. Thus, managers do not perceive the risk area for task distribution as involving certainty and de-coupling as a valuable prerequisite for their socio-technical system of managerial practices. In Section 6, we discuss how the managerial practice and its attention shaping of common offshoring risks contributes to previous research, as presented in the theoretical background section.

6 Discussion

In this section, we answer the research question and discuss how the answer contributes to previous research in the contributions section. We also discuss the 1) implications for research and practice in software development offshoring, 2) our study's limitations, and 3) directions for future research.

6.1 Contributions

We review our analysis of the Systematic / Conscensia offshoring case in relation to the theoretical background section and our research question: How do managers perceive and mitigate the risk areas in software development offshoring from a mature (CMMI level 5) software company?

The investigated case shows that the managers perceived and mitigated most risk areas in accordance with previous research on software development offshoring risks (Persson et al., 2009). Task distribution, however, was a notable exception because Systematic intentionally and successfully pursued high-task uncertainty, equivocality, and coupling. Persson et al. (2009) argue for the task distribution risk area based on research suggesting reducing uncertainty (Herbsleb & Mockus, 2003; Sakthivel, 2005), equivocality (Bell & Kozlowski, 2002; Xue, Sankar, & Mbarika, 2004) and coupling (Carmel & Agarwal, 2001; Herbsleb & Grinter, 1999). This finding is in line with research on task distribution that argues that "to avoid problems between sites, the main tactic is minimization of collaboration needed between sites, since this minimizes the negative impact of communication and coordination problems. This can be achieved by minimizing coupling, i.e., the dependencies between tasks assigned to different sites" (Lamersdorf, Munch, & Rombach, 2008). This line of research develops frameworks and decision making models for task distribution in software development offshoring (Lamersdorf et al., 2012; Narendra, Ponnalagu, Zhou, & Gifford, 2012; Ruano-Mayoral, Colomo-Palacios, Fernández-González, & GarciaCrespo, 2011). However, the findings from our case study of a mature offshoring client (CMMI 5 certified since 2005) give reason to question the assumed need for de-coupled and well-defined tasks for successfully offshoring software development. The maturity level of the offshoring client suggests that managers do not base their view of task distribution on a lacking capability of achieving such task distribution. Those at various organizational levels in the Systematic / Conscensia case perceived the risk factors of task distribution more in terms of risk mitigation rather than risk taking. This finding reflects how the conception of risks derives from what these managers consider to be valuable, both in and for the success of their managerial practice (Corvellec, 2010).

We explain the managerial practice in the Systematic / Conscensia case by using Leavitt's (1964) sociotechnical model of organizational change, a model used by previous research to explain how a risk management approach shapes managers' attention to software development (Lyytinen et al.. 1998) that forms the underlying structure of the eight risk areas (Persson et al.. 2009) investigated in this case study. We use the model in Figure 1 to illustrate how the managers' attention to the risk areas related to structure, actors, and technology shaped the perception of task distribution. Figure 1 explains a managerial practice that allows high task uncertainty, equivocality, and coupling but that also uses these three risk factors of task distribution as supporting characteristics of the managerial practice to support and align the structure, actors, and technology. This finding is an important contribution to understanding the risk areas for offshoring software development (Persson et al., 2009) in a mature managerial practice. Persson et al.'s (2009) framework integrates risks related to software development offshoring in accordance with CMMI (Persson & Mathiassen, 2010) and socio-technical terms (Leavitt, 1964; Lyytinen et al., 1998). However, the findings from our case study show the framework's limited attention to a different framing of task distribution in a mature managerial practice involving Agile methods. Our case study shows how integrated managerial practices can be very important for understanding risk perception and mitigation, which one can see with the risk area for task distribution. This study finally complements Lyytinen et al.'s (1998) use of Leavitt's (1964) socio-technical model to show how risk areas may be mitigated indirectly by not only addressing the other three components in the model but also recognizing the perception of a risk area in a specific component.

6.2 Implications

This case study's findings have implications for both research and practice in software development offshoring. Managers of software development offshoring should consider the potential of task uncertainty, equivocality, and coupling as a risk-mitigation strategy rather than only risk taking. Our findings from a mature software development organization as the offshoring client suggest this can be a viable risk mitigation strategy. However, adopting such a strategy requires a strong emphasis on mitigating the risk areas associated with structure, actors, and technology.

Our finding that managers can perceive task distribution as risk mitigation rather than risk taking suggests that researchers should question the widespread assumption of the opposite (Herbsleb & Mockus, 2003; Persson et al., 2009; Sakthivel, 2005). We propose understanding task distribution in software development offshoring through the integration of socio-technical components: structure, actors, and technology (Leavitt, 1964; Lyytinen et al., 1998). Researchers studying software development offshoring should consider how task distribution derives from what managers consider to be valuable, both in and for the success of their managerial practice (Corvellec, 2010). This insight needs to be accounted for in research on offshoring risk management and associated managerial practices in general. Our finding also confirms previous research that argues for the importance of process facilitation on the client side when working with software requirements (Yadav, Adya, Sridhar, & Nath, 2013).

6.3 Limitations

This case study's limitations and findings need careful consideration from managers considering adopting Systematic's approach to offshoring or from researchers interested in testing and generalizing our findings. The Systematic / Conscensia offshoring case is not representative of software development offshoring in general. We chose the case because of its uniqueness in having a mature (certified CMMI level 5) software company as the offshoring client. Thus, while we strongly encourage practitioners and researchers to take our findings into other settings, the results may not be similar to those in the Systematic / Conscensia offshoring case. Our case study investigated risk perception and mitigation as embedded in their managerial practices with an interpretive approach. While we report a rich description of the case and our analysis, important insights concerning the managers and our role as researchers remain tacit. Finally, we focused on a limited range of stakeholders in investigating risk areas and did not specifically attend to the ethical risks inherent in software development projects (Gotterbarn & Rogerson, 2005; Gotterbarn, Clear, & Kwan, 2008).

6.4 Future Research

We need future research on managers' perceptions and mitigations of risk areas in offshoring to further understand the integration of practices that derives from what they consider to be of value both in and for the success of their managerial practice. Our study provides an in-depth interpretive study of a case with a mature software development organization as the offshoring client. However, we need investigations of representative offshoring cases through alternative approaches for descriptive and proactive research. Design science-oriented research on task distribution strategies and decision making (Lamersdorf et al., 2008; Lamersdorf et al., 2012; Narendra et al., 2012; Ruano-Mayoral et al., 2011) may use our findings to develop tools, models, and frameworks that build on an alternative to minimizing coupling and collaboration across sites. Our findings also illustrate the importance of future research on managing relationships between risk components (El-Masri & Rivard, 2012; El-Masri, 2013). While our findings show how managerial practices shape the risk perception of task distribution, we still need additional research on the relationships between different risk components, on the underlying software ecology, and on how trust influences the processes.

Acknowledgments

The research received support from the Center for IT Project Management and Innovation at Aarhus University. We also thank Conscensia and Systematic for their helpfulness and participation. Ternopil National Economic University provided a living discursive atmosphere and highly appreciated logistical support during stays in Ukraine.

Sidebar

Marcus A Rothenberger acted as Senior Editor for this paper.

Contribution:

This paper contributes to IS research in that it is the first in-depth study of managers' perceptions and mitigations of risk areas in development offshoring from a mature (CMMI level 5) software company. We analyze eight common risk areas for software development offshoring (Persson et al., 2009) in relation to what managers consider to be valuable both in and for their organizational practice (Corvellec, 2010). The resulting analysis shows that, contrary to approaching high task uncertainty, equivocality, and coupling across sites as risk taking, a mature organization can approach these factors as risk mitigation. We propose a socio-technical explanation of this capability based on interrelating the task, structure, actors, and technology (Leavitt, 1964; Lyytinen. Mathiassen, & Ropponen, 1998). The study offers new insights that can prove useful for risk management practice and research investigating how to understand, support, and improve the management of software development offshoring.

References

References

Alvesson, M., & Kärreman, D. (2007). Constructing mystery: Empirical matters in theory development. Academy of Management Review, 32(4), 1265-1281.

Bannerman, P. L., Hossain, E., & Jeffery, R. (2012). Scrum practice mitigation of global software development coordination challenges: A distinctive advantage? In Proceedings of the 45th Hawaii International Conference on System Sciences (pp. 5309-5318).

Bazeley, P. (2007). Qualitative data analysis with NVivo. London: Sage.

Bell, B. S., & Kozlowski, S. W. (2002). A typology of virtual teams implications for effective leadership. Group & Organization Management, 27(1), 14-49.

Boehm, B. W. (1991). Software risk management: Principles and practices. IEEE Software, 8(1), 32-41.

Boholm, Å., & Corvellec, H. (2011). A relational theory of risk. Journal of Risk Research, 14(2), 175-190.

Carmel, E., & Agarwal, R. (2001). Tactical approaches for alleviating distance in global software development. IEEE Software, 18(2), 22-29.

Cavaye, A. L. M. (1996). Case study research: A multi-faceted research approach for IS. Information Systems Journal, 6(3), 227-242.

Clear, T., & MacDonell, S. G. (2011). Understanding technology use in global virtual teams: Research methodologies and methods. Information and Software Technology, 53(9), 994-1011.

Clear, T., Raza, B., & MacDonell, S. G. (2013). A critical evaluation of failure in a nearshore outsourcing project: What dilemma analysis can tell us. In Proceedings of the 8th IEEE International Conference on Global Software Engineering (pp. 178-187).

CMMI Product Team. (2010). CMMI® for development, version 1.3, Improving processes for developing better products and services. Software Engineering Institute.

Corvellec, H. (2010). Organizational risk as it derives from what managers value: A practice-based approach to risk assessment. Journal of Contingencies and Crisis Management, 18(3), 145-154.

El-Masri, M. (2013). A decision support system for software project risk management: A three-essay dissertation (Doctoral dissertation). HEC Montréal.

El-Masri, M., & Rivard, S. (2012). Towards a design theory for software project risk management systems. In Proceedings of the International Conference on Information Systems.

Gordon, S. R., Blake, R. H., & Shankaranarayanan, G. (2013). Case-based research in information systems: Gaps and trends. Journal of Information Technology Theory and Application, 14(2), 47-68.

Gotterbarn, D., Clear, T., & Kwan, C. (2008). A practical mechanism for ethical risk assessment-A SoDIS inspection. In K. E. Himma & H. T. Tavani (Eds.), The handbook of information and computer ethics (pp. 429-471). Hoboken, New Jersey: John Wiley & Sons.

Gotterbarn, D., & Rogerson, S. (2005). Responsible risk assessment with software development: Creating the software development impact statement. Communications of the Association for Information Systems, 15, 730-750.

Hansson, S. O. (2010). Risk: Objective or subjective, facts or values. Journal of Risk Research, 13(2), 231-238.

Herbsleb, J. D., & Mockus, A. (2003). An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering, 29(6), 481-494.

Herbsleb, J. D., & Grinter, R. E. (1999). Architectures, coordination, and distance: Conway's Law and beyond. IEEE Software, 16(5), 63-70.

Holmstrom, H., Conchúir, E. Ó., Agerfalk, P. J., & Fitzgerald, B. (2006). Global software development challenges: A case study on temporal, geographical and socio-cultural distance. In Proceedings of the 2006 International Conference on Global Software Engineering (pp. 3-11).

Iacovou, C. L., & Nakatsu, R. (2008). A risk profile of offshore-outsourced development projects. Communications of the ACM, 51(6), 89-94.

Jakobsen, C. R., & Sutherland, J. (2009). Scrum and CMMI going from good to great. In Proceedings of the AGILE '09 Conference (pp. 333-337).

Jalali, S., & Wohlin, C. (2012). Global software engineering and agile practices: A systematic review. Journal of Software: Evolution and Process, 24(6), 643-659.

Kautz, K., Johansen, T. H., & Uldahl, A. (2014). Creating business value through agile project management and information systems development: The perceived impact of Scrum. In B. Bergvall-Kåreborn & P. A. Nielsen (Eds.), Creating value for all through IT (pp. 150-165). New York: Springer.

Keshlaf, A., & Riddle, S. (2011). Web and distributed software development risks management: WeDRisk approach. International Journal on Advances in Software, 3(3-4), 447-460.

Klein, H. K., & Myers, M. D. (1999). A set of principles for conducting and evaluating interpretive field studies in information systems. MIS Quarterly, 23(1), 67-93.

Lacity, M. C., Khan, S. A., & Willcocks, L. P. (2009). A review of the IT outsourcing literature: Insights for practice. The Journal of Strategic Information Systems, 18(3), 130-146.

Lamersdorf, A., Münch, J., & Rombach, D. (2008). Towards a multi-criteria development distribution model: An analysis of existing task distribution approaches. In Proceedings of the 2009 IEEE International Conference on Global Software Engineering (pp. 109-118). Washington, DC: IEEE Computer Society.

Lamersdorf, A., Münch, J., Viso Torre, A. F., Sánchez, C. R., Heinz, M., & Rombach, D. (2012). A rule-based model for customized risk identification and evaluation of task assignment alternatives in distributed software development projects. Journal of Software: Evolution and Process, 24(6), 661675.

Leavitt, H. J. (1964). Applied organization change in industry: Structural, technical and human approaches. In W. W. Cooper, H. J. Leavitt, & M. W. Shelley (Eds.), New perspectives in organizational research (pp. 55-71). New York: Wiley.

Lyytinen, K., Mathiassen, L., & Ropponen, J. (1998). Attention shaping and software risk-a categorical analysis of four classical risk management approaches. Information Systems Research, 9(3), 233255.

March, J. G., & Shapira, Z. (1987). Managerial perspectives on risk and risk taking. Management Science, 33(11), 1404-1418.

Matloff, N. (2005). Offshoring: What can go wrong?" IT Professional, 7(4), 39-45.

Mirani, R. (2006). Client-vendor relationships in offshore applications development: An evolutionary framework. Information Resources Management Journal, 19(4), 72-86.

Myers, M. D., & Newman, M. (2007). The qualitative interview in IS research: Examining the craft. Information and Organization, 17(1), 2-26.

Nakatsu, R. T., & Iacovou, C. L. (2009). A comparative study of important risk factors involved in offshore and domestic outsourcing of software development projects: A two-panel Delphi study. Information & Management, 46(1), 57-68.

Narendra, N. C., Ponnalagu, K., Zhou, N., & Gifford, W. M. (2012). Towards a formal model for optimal task-site allocation and effort estimation in global software development. In Proceedings of the 2012 Service Research and Innovation Institute Global Conference (pp. 470-477). California: IEEE.

Persson, J. S. (2013). The cross-cultural knowledge sharing challenge: An investigation of the co-location strategy in software development offshoring. In Proceedings of IFIP WG 8.6 International Working Conference on Transfer and Diffusion of IT (pp. 310-325).

Persson, J. S. (2010). Managing distributed software projects (Doctoral dissertation). Aalborg University.

Persson, J. S., & Mathiassen, L. (2010). A process for managing risks in distributed teams. IEEE Software, 27(1), 20-29.

Persson, J. S., Mathiassen, L., & Aaen, I. (2012). Agile distributed software development: Enacting control through media and context. Information Systems Journal, 22(6), 411-433.

Persson, J. S., Mathiassen, L., Boeg, J., Madsen, T. S., & Steinson, F. (2009). Managing risks in distributed software projects: An integrative framework. IEEE Transactions on Engineering Management, 56(3), 508-532.

Pries-Heje, J., Nørbjerg, J., Aaen, I., & Elisberg, T. (2008). The road to high maturity: How the first Danish company reached CMMI level 5 in 100 months. In P. A. Nielsen & K. Kautz (Eds.), Software processes & knowledge: Beyond conventional software process improvement (pp. 163-192). Aalborg: Software Innovation.

Rottman, J. W., & Lacity, M. C. (2006). Proven practices for effectively offshoring IT work. MIT Sloan Management Review, 47(3), 56-63.

Ruano-Mayoral, M., Colomo-Palacios, R., Fernández-González, J. M., & García-Crespo, Á. (2011). Towards a framework for work package allocation for GSD. In Meersman, R., Dillon, T., & Herrero, P. (Eds.), On the move to meaningful internet systems: OTM 2011 workshops (pp. 200-207). Springer.

Sakthivel, S. (2005). Virtual workgroups in offshore systems development. Information and Software Technology, 47(5), 305-318.

Santana, C., Gusmão, C., Soares, L., Pinheiro, C., Maciel, T., Vasconcelos, A., & Rouiller, A. (2009). Agile software development and CMMI: What we do not know about dancing with elephants. In Proceedings of the 10th XP 2009 International Conference (pp. 124-129).

Siebdrat, F., Hoegl, M., & Ernst, H. (2009). How to manage virtual teams. MIT Sloan Management Review, 50(4), 63-68.

Singh, A., & Nigam, A. R. K. (2012). Risks identification in an offshore-onshore model based it engagement. International Journal of Computer Applications, 48(14), 31-41.

Smite, D., Wohlin, C., Gorschek, T., & Feldt, R. (2010). Empirical evidence in global software engineering: A systematic review. Empirical Software Engineering, 15(1), 91-118.

Smite, D., Wohlin, C., GalviHa, Z., & Prikladnicki, R. (2014). An empirically based terminology and taxonomy for global software engineering. Empirical Software Engineering, 19(1), 105-153.

Søderberg, A., Krishna, S., & Bjørn, P. (2013). Global software development: Commitment, trust and cultural sensitivity in strategic partnerships. Journal of International Management, 19(4), 347-361.

Stephan, M., & Silvia, M. (2008). A dynamic perspective on next-generation offshoring: The global sourcing of science and engineering talent. The Academy of Management Perspectives, 22(3), 3554.

Sutherland, J., Ruseng Jakobsen, C., & Johnson, K. (2008a). Scrum and CMMI level 5: The magic potion for code warriors. In Proceedings of the 41st Annual Hawaii International Conference on System Sciences (pp. 466-474).

Sutherland, J., Schoonheim, G., Rustenburg, E., & Rijk, M. (2008b). Fully distributed Scrum: The secret sauce for hyperproductive offshored development teams. In Proceedings of the AGILE 2008 Conference (pp. 339-344).

Turner, R., & Jain, A. (2002). Agile meets CMMI: Culture clash or common cause? Extreme Programming and Agile Methods - XP/Agile Universe 2002. In D. Wells & L. Williams (Eds.), Lecture Notes on Computer Science Volume 2418 (pp. 153-165).

Verner, J., Brereton, O., Kitchenham, B., Turner, M., & Niazi, M. (2014). Risks and risk mitigation in global software development: A tertiary study. Information and Software Technology, 56(1), 54-78.

Walsham, G. (2006). Doing interpretive research. European Journal of Information Systems, 15(3), 320330.

Walsham, G. (1995). Interpretive case studies in IS research: Nature and method. European Journal of Information Systems, 4(2), 74-81.

Xue, Y., Sankar, C. S., & Mbarika, V. W. (2004). Information technology outsourcing and virtual team. Journal of Computer Information Systems, 45(2), 9-16.

Yadav, V., Adya, M., Sridhar, V., & Nath, D. (2013). Control, process facilitation, and requirements change in offshore requirements analysis: Indian IT provider perspective. Journal of Information Technology Theory and Application, 14(3), 30-47.

Appendix

Appendix A: Interview Protocols

Interview 01:

Interviewee: Manager

1) General background information

* Presentation and purpose of the interview

* Your background (experience, education)

2) Structure of Conscensia

a. Your role

b. How is the company structured?

3) Who are the customers and why do they chose Conscensia?

4) The employees

a. What the principles of remuneration?

b. Who are they?

c. How do they differ for e.g. Danish employees?

d. How do you attract and select staff?

5) Why is it attractive for foreign companies to outsource to Ukraine?

a. Macro-economic issues

b. Educational issues

c. Competencies

d. Do you have any opinion on the outsourcing/near-sourcing debate?

6) How do you manage cooperation across borders and cultures?

a. Any specific differences in work style and approach?

Interview 02:

Interviewee: Managers

1) General background information

a. Presentation and purpose of the interview

b. Your background (experience, education)

2) Your role

a. What is your role here in Conscensia/Systematic?

3) The projects

a. Please describe a typical project

i. Content

ii. Size

b. What do you think is special about being a programmer in cross-border projects?

c. How do projects differ between UA and DK?

d. What are the major obstacles or problems?

4) The staff

a. How do DK and UA staff differ?

b. Do you receive any specific training at Conscensia?

5) How do you manage cooperation across borders and cultures?

a. Any specific differences in work style and approach?

Interview 03:

Interviewee: Programmer, Conscensia, Ukraine

1) General background information

a. Presentation and purpose of the interview

b. Your background (experience, education)

2) Your role

a. What is your role here in Conscensia?

3) The projects

a. Please describe a typical project

i. Content

ii. Size

b. What do you think is special about being a project manager in cross-border projects?

c. How does PM differ between UA and DK?

d. What are the major obstacles or problems?

4) The staff

a. How do DK and UA staff differ?

5) How do you cooperate across borders and cultures?

a. Any specific differences in work style and approach?

Interview 04: Follow-up

This interview has several (distinct) purposes:

1) To confirm factual observations from the last interview

a. Composition of teams, roles etc.

b. Usage of tools

2) To dig into issues and observations regarding cooperation in co-located teams

1) Conformational part

a. Can we please draw a picture / organogram of your team, roles, and physical settings?

i. HQ

ii. Frontline

iii. Management

b. Can we sketch how tools are used?

i. By whom and for what purpose? (Technical / Management)

ii. How are they related?

iii. Who decides these things?

2) Organizational issues

a. In what circumstances do you use the different tools?

b. Please sketch the ongoing working schedule for a week / cycle

c. How do you feel or observe the balance of power between the two development sites?

d. Please explain the communication patterns

e. How do you act / take action when you are concerned, mad, angry, or disappointed with colleges from Denmark?

i. How is this related to the use of (software) tools?

ii. What aspects of the tools and routines lead to a successful project?

f. How will you characterize an SW product on balance, a project deemed to be a success?

g. Who takes the lead?

h. Why do we not have any Ukrainian (or do we?)

i. Product managers

ii. Project managers

iii. Team leaders

iv. Scrum masters

v. Feature leads?