A Process for Managing Risks in Distributed Teams

This article first appeared in IEEE Software magazine and is brought to you by InfoQ & IEEE Computer Society.

Today, many software projects are geographically distributed, so software man­agers must know how to manage distributed teams.[1],[2] For example, they need to know how to build teams across sites, how to break down and distribute tasks, how to share knowledge across time, space, and cultural differences, and how to coordinate work to produce coherent outcomes.

The current literature offers rich insights into these challenges,[3] ,[4] ,[5] ,[6] but it offers no process for managing risks that apply to distributed team structures. We’ve developed a comprehensive pro­cess that’s compliant with CMMI, the Software Engineering Institute’s maturity model for as­sessing and improving organizational processes. CMMI offers a comprehensive set of generic pro­cesses to support development of products and services[7]. One of its processes focuses on risk management to help identify and analyze poten­tial problems before they occur so that managers can plan risk-handling activities and invoke them across the project life cycle. We adapt this approach to avoid redundancies and focus on managing risk in distributed teams. We describe a series of steps that are easy to understand and follow. However, practicing risk management requires nontrivial skills and insights[8], so it’s important to remember that a rigorous recipe for action must always be adapted to become useful in practice:

A recipe tells you the ingredients, how to mix the ingredients, what temperature to use, and how long to cook those ingredients. How­ever, it does not teach you the techniques of slicing and dicing, mixing, beating, whipping, blanching, grilling, poaching, etc. And recipes also leave room for some experimentation and modification[9].

Process Foundation

To create a solid foundation for the process, we syn­thesized state-of-the-art research on managing dis­tributed teams[10]. Analyzing 72 scientific articles, we identified inherent risks in distributed teams, tech­niques to solve them, and guidelines for applying the techniques. We then integrated these findings into a framework to support risk management in distributed teams; a Web-based tool implementa­tion of the framework is freely available at www.distributedprojects.net.

We synthesized the risks into a two-level taxon­omy. First, we identified eight risk areas[11]:

• task distribution,
• knowledge management,
• geographical distribution,
• collaboration structure,
• cultural distribution,
• stakeholder relations,
• communication infrastructure, and
• technology setup.

Then, we identified specific risk factors to further characterize each risk area[12]. Table 1 defines risk areas and factors that are characteristic for distrib­uted teams. Some of these might seem typical for any project, but the table focuses on risks related to distributed teams. Distributed environments can significantly intensify risks, to an extent that tradi­tional project management approaches might not apply.

Table 1: Identifying and analyzing distributed-team risks

For example, the collaboration structure risk area includes a risk factor for collaboration capabil­ity (see Table 1)[13],[14],[15]. This factor describes team members’ understanding and appreciation of com­petency differences and how effectively they use technology to gather and share information over geographical and functional distances[16],[17]. It’s prob­lematic if distributed team members have limited understanding of each other’s competencies - for example, when a distributed team needs to manage software requirements across sites[18],[19],[20].

Language barriers are another risk factor[21],[22],[23].They arise when distributed team members don’t share the same language or communication norms. Such situations can easily lead to misinterpretations and unconveyed information[24], which are well-known problems in distributed teams[25],[26],[27],[28].

We also synthesized four different types of reso­lution techniques: planning, control, social integra­tion, and technical integration[29]:

• planning techniques help design and organize projects so that they can be effectively executed in distributed contexts;
• control techniques facilitate tracking progress across sites and help manage discrepancies in relation to plans;
• social integration techniques integrate team members and help manage cultural differences across sites; and
• technical integration techniques increase con­nectivity and technical compatibility across sites.

Finally, we identified a portfolio of specific tech­niques for each type and guidelines for how to ap­ply them to distributed-team risks (see Table 2). So, the eight areas of risks, the four types of resolution techniques, and the guidelines for combining them are syntheses of state-of-the-art research on distrib­uted teams and form the conceptual foundation for our risk management process.

Process Architecture

We structured the risk management process into the three steps shown in Figure 1: identify and analyze risks, develop risk mitigation plans, and implement risk mitigation plans. We adopted a risk-action list approach in the risk management processes that offers directions for how to apply the four types of resolution techniques to the eight areas of distributed-team risks[30]. Managers of dis­tributed teams can adopt our process when prepar­ing for risk management, which is CMMI’s first specific goal for risk management. Because the fo­cus is on risks related to or exacerbated by project distribution, managers must adopt other processes for complete risk management when addressing CMMI’s first specific goal.

Figure 1. Steps and outcomes in the risk management process. Circles are process steps and rectangles are outcomes. The first step addresses CMMI’s second specific goal for risk management. The second and third steps address CMMI’s third specific goal for risk management.

The first process step in Figure 1 helps distrib­uted team managers identify and analyze risks - CMMI’s second specific goal for risk manage­ment[31]. We have identified and categorized the risks (see Table 1), so risk management participants can focus on analyzing risk probabilities and impacts and prioritize how to address them. It’s particu­larly important to involve team members during this step because the project manager might have limited knowledge about different sites. For a given project, the first level of analysis therefore focuses on developing risk assessments at each site. The sec­ond level focuses on developing risk assessments for the entire project based on the local estimates. This requires a collocated or mediated project meeting where participants uncover differences in perspec­tives and experiences across sites and negotiate how to prioritize overall distributed-team risks. Manag­ers can distribute the resulting risk assessment data to the rest of the organization, allowing for risk management across subprojects and comparisons and learning among independent projects.

The process also helps distributed-team manag­ers mitigate risks - CMMI’s last specific goal for risk management[32]. Following the CMMI process, mitigating risks includes two specific practices: de­veloping and implementing risk mitigation plans, steps 2 and 3 in Figure 1, respectively. Developing a risk mitigation plan is supported by the list of resolution techniques and guidelines for how to ap­ply them to address specific risk areas (see Table 2). During this step, participants can adopt resolution techniques from the list or develop novel resolu­tion techniques to address distributed-team risks in their project. In the final process step, implement­ing risk mitigation plans, participants study proj­ect objectives and decide on practical approaches. To do so, they consider responsibilities, resources, deliverables, and milestones as key elements in implementation[33].

Table 2: Developing risk mitigation plans

Process Illustration

We illustrate the risk management process with a software project from ScandicBank, a large finan­cial company based in northern Europe. (Scandic­Bank is a pseudonym, but our discussion is based on data from a real-world distributed software project.)

ScandicBank has a long history of national mergers and is now expanding by acquiring companies in neighboring countries. Each ac­quisition requires a significant effort from Scan­dicBank’s IT division. The strategy is to achieve economies of scale by implementing the bank’s standard IT platform as quickly as possible in all new branches. The responsibility for the IT platform resides at ScandicBank’s headquarters. However, some acquired companies have their own IT departments. After an acquisition, these are typically engaged in making the IT platform adhere to specific financial software system re­quirements in their respective countries.

ScandicBank’s most recent acquisition is a com­pany that’s different from previous acquisitions. It’s significantly larger, has a sophisticated IT plat­form, and is located in a country with a different language tradition from the dominant language within ScandicBank. Previous acquisitions were smaller, had an inferior IT platform, and involved a language tradition similar to ScandicBank.

The implementation of ScandicBank’s standard IT platform is organized as an integration project (IP), as shown in Figure 2. The project consists of 20 subprojects, has more than 500 participants over its life cycle, and has a strict one-year dead­line.

Figure 2. ScandicBank’s integration project. Rectangles are organizations, ovals are different types of subprojects spanning the organizations, and the large dotted oval indicates the entire integration project.

The project participants are located in the acquired company’s IT department and at four different sites of ScandicBank’s IT division. Fur­thermore, the IP requires an unusually large num­ber of IT professionals, so ScandicBank has en­gaged an Indian software outsourcing provider. Seven of the 20 subprojects have team members distributed across all three organizations, as illus­trated in Figure 2; 11 subprojects are distributed across ScandicBank’s IT department and one of the two external entities; and only two subprojects aren’t distributed.

Identifying and Analyzing Risks

Identifying and analyzing risks is a nontrivial task in distributed teams. There are many types of risks and the knowledge to uncover them is typically dis­tributed across team members and sites. Table 1 supports this task. The eight risk areas and related risks factors are defined by analytical questions and evaluation criteria related to the qualitative indica­tors of low, medium, and high.

Our approach takes into account the difficulties of communicating and sharing knowledge across distributed teams. First participants from each site individually use Table 1 to identify and analyze risks. Next the risk management participants dis­cuss the local assessments at joint meetings across sites to arrive at an overall risk assessment and pri­oritization of risks. In large projects consisting of multiple subprojects, each subproject assessment would become the basis for a risk management meeting between subproject representatives.

Risk management participants apply Table 1 as follows to identify and analyze distributed-team risks. For each risk factor, the participants assess the probability of an unsatisfactory outcome P(UO) and the loss to the parties affected if the outcome is unsatisfactory L(UO). These assessments can be made on a scale with numeric values from 0 to 8, categorized into low (0–2), medium (3–5), and high (6–8). The qualitative indicators of low, medium, and high risk in Table 1 support the probability assessment.

Next, for each risk factor, the Web-based tool calculates the risk exposure (RE) based on the equation RE = P(UO) × L(UO)[34]. The average RE for the three risk factors constitutes the risk area’s RE value. On the basis of these values, the partici­pants derive a prioritized list of the eight significant risk areas.

In ScandicBank’s IT division, management gives high attention to the challenges related to the geo­graphical distribution of software teams. Limited experience with distributed teams and the strate­gic importance of the company’s most recent ac­quisition prompt management to adopt the risk management process. Development support makes the Web-based tool[35] available in the company’s software methodology portfolio and includes the process in the IT division’s process library. The IP manager initiates the process early during the re­quirements phase. Each subproject manager en­gages team members from the involved sites to complete a local risk assessment according to Table 1 in preparation for a joint risk management meet­ing. At this point, the IP manager decides to repeat the risk management process at frequent intervals throughout the project’s life cycle.

Several subprojects are in the fortunate posi­tion of having their first risk management meetings face-to-face, because collocated collaboration is em­phasized for a few weeks during the requirements phase. So the IP participants predominantly carry out multinational requirements engineering in a collocated setting. This early stage collocation is fea­sible because the team has only a few members dur­ing the requirements phase (100), compared to later in the project (up to 500). Team members present and discuss local assessments of each risk factor us­ing the Web-based tool and a projector.

Some subprojects can’t meet face-to-face. They conduct risk management meetings using telecon­ferencing and desktop sharing of the results from the Web-based tool. In the beginning, participants are reluctant to comment on each others’ risk as­sessments. In an effort to kick-start the discus­sion, one project manager points out the details of her risk assessment and volunteers to explain the grounds on which they were developed. To cre­ate an open and safe communication climate[36], she then asks one of her more experienced and outgoing colleagues, who is not afraid to disagree with her, to elaborate on his assessment. Managers of dis­tributed teams can undertake similar initiatives to overcome differences between high-context culture (India) and low-context culture (northern Europe) team members[37].

With all subproject risk assessments in hand, the IP manager calls for a risk management meet­ing with all subproject managers. The procedure for this meeting is similar to that of the subproj­ects. However, participants compare and contrast the assessments of each subproject instead of the local assessments from each site. During the re­quirements phase in the first meeting, the project managers identify cultural distribution as the most significant risk area across subprojects. Also, it be­comes clear that some subprojects have low assess­ments of all risk areas. These subprojects are pri­marily located at a single site within the IT division of ScandicBank with only a few team members at the IT department of the acquired company. As a consequence, the IP manager decides to in­clude only six of the 20 subprojects in future risk management.

At later IP stages, the project managers evalu­ate task distribution as the most significant risk area. Over the project’s life cycle, task distribution and cultural distribution frequently have high-risk-exposure assessments whereas communication infrastructure and geographical distribution fre­quently have low-risk-exposure assessments.

Developing Risk Mitigation Plans

Awareness of high-priority risk areas is an impor­tant first step in addressing them. However, it isn’t sufficient. Effective risk management is based on comprehensive risk mitigation plans.

A variety of resolution techniques is available for developing risk mitigation plans. Table 2 as­sociates techniques to different risk areas. In some situations, the proposed techniques oppose each other—for example, “Standardize and train in methods across sites,” on one hand, and “Handle differences in methods between sites,” on the other hand. The challenge is therefore to select a portfo­lio of coherent techniques that effectively address the risks at hand.

Instead of adopting the generic resolution tech­niques we suggest, users of the process can develop novel or company-specific techniques. The partici­pants should develop risk mitigation plans at the joint risk management meetings and base them on the overall risk assessments for the project.

The IP adopts resolution techniques at both the overall project and subproject levels. For example, in a subproject with cultural distribution as a pri­oritized risk area, the participants choose the reso­lution technique “improve capability to manage cultural differences.” The Web-based tool provides detailed resolution suggestions as follows[38]:

• Establish courses in cultural diversity during the startup phase of the project. If team mem­bers are stationed at remote sites, the cultural training should take place before departure.
• Focus on creating understanding and accep­tance of differences - for example, by letting each team member make a presentation on their individual culture, values, and expectations.
• Promote understanding and acceptance rather than seeking to streamline the project organization.
• Focus on the strengths that diversity offers rather than weaknesses.
• Acknowledge and discuss cultural differ­ences in a respectful and civilized manner, and keep in mind that there are limits to cultural adaptation.
• Adjust management style according to cul­ture - for example, team members’ preferences for well-defined tasks versus preferences for loosely defined tasks and self-management.

Not all resolution suggestions are practically or financially feasible for the subproject. However, specific resolution suggestions spur debate and more specific ideas about how to address cultural distribution. The second resolution suggestion in­spires a lunch meeting where one team member from each of the three countries makes a short pre­sentation of their corporate and national culture. The participants discuss the strengths their cultural diversity offers and personal preferences regarding well-defined versus loosely defined tasks.

The subproject managers also discuss resolu­tion techniques for cultural distribution at a risk management meeting for the IP at large. They dis­cuss which resolution techniques to initiate across subprojects. They agree to mitigate risks primarily at this level by “developing liaisons between sites” (see Table 2). Each subproject with more than 10 team members will have liaisons at least at one ScandicBank IT division site, while subprojects with more than 25 team members will have liai­sons at multiple sites. The subproject managers also discuss task dis­tribution at a later risk management meeting. They agree to mitigate risks primarily through the “stan­dardize and train in methods across sites” technique (see Table 2). Several subproject managers argue that team members outside the ScandicBank IT di­vision lack knowledge of the development method, hindering effective task distribution among sites. The managers agree to organize training at the In­dian site and the acquisition’s IT department.

Implementing Risk Mitigation Plans

In risk management, it’s essential to reach conclu­sions that lead to actions. The final step of our pro­cess is therefore to develop implementation plans for each prioritized risk area (see Figure 3). These plans lay out activities to bring each risk area under control. The plans address five basic elements of risk mitigation[39]: the objectives (why) are identified through the risk assessment; the deliverables and milestones (what and when) suggest when the team should take action; the responsibilities (who and where) describe which individuals are respon­sible for a given action and where they are to carry it out within the distributed organization; the ap­proach (how) consists of the identified resolution techniques; and the resources (how much) esti­mate the costs associated with addressing the risk area. The project manager should then integrate the mitigation plans into the project’s overall risk management plan.

Figure 3. Implementing risk mitigation plans by addressing the five elements of risk mitigation. The rightmost rectangles elaborate the question to consider for each element along with an explanation of how it relates to the process.

In accordance with Figure 1, distributed proj­ects should repeat the risk management process throughout the project life cycle as risk profiles change[40],[41],[42]. Distributed teams should therefore decide how often to revisit the risk management process and make sure that each activation is properly documented and reviewed in subsequent activations.

In the IP, the risk management participants de­tail the five elements of risk mitigation by the end of the joint risk management meetings. For ex­ample, in the subproject improving capabilities for managing cultural differences, the team imple­ments the plan. The objective is to address cultural distribution because several team members ex­pressed insecurity regarding how to contribute to the new distributed organization. The deliverables and milestones in relation to cultural distribution risks are the cultural presentation meetings sched­uled at specific dates. Concerning responsibilities, the participants make notes on who should make cultural background presentations in each case. Adding to the approach, the participants make notes on what specific topics interest them. Finally, the participants estimate that the initiative repre­sents a monthly two-hour resource load for each team member.

Two months later, when the risk management participants revisit the cultural distribution risk area, risk exposures have dropped from high to medium. Hence, the initiatives have reduced cul­turally related misunderstandings and eased col­laborations among team members.

The risk management meeting for the overall IP also addresses the five elements to implement more off-site training in ScandicBank’s develop­ment method. The objective is to address task distribution because participants complain about task equivocality, particularly in regard to unclear testing and documentation responsibilities across sites. The deliverable is an extension of Scandic­Bank’s method training program to be designed in three days and delivered in two weeks. A partici­pant from development support and a subproject manager agree to take responsibility for the train­ing initiative. In discussing the approach, several subproject managers request extended testing and documentation training. The participating manag­ers estimate that these activities represent sizable resources, primarily covered by company-wide hu­man resource efforts and thus not part of the IP budget. The participants estimate that the time in­vested by team members will give significant pro­ductivity payoffs for the remainder of the project.

When the risk management participants revisit the task distribution risk area two months later, risk exposure assessments are lower. The partici­pants still perceive task equivocality as challeng­ing. Therefore, in addition to the training initiative, the IP manager increases collocation of team mem­bers. While expensive, this additional initiative, which can be seen as an extreme adaptation of “develop liaisons between sites,” proves successful in alleviating not only task distribution risks but also cultural distribution risks.

Generic processes leave room for experi­mentation and suggestions for modifica­tions[43]. In tailoring the process for manag­ing distributed-team risks to match the preferences of your project or organization, you should there­fore consider these guidelines:

• Keep it simple. Managing distributed teams has many challenges. It’s important to estab­lish a frequency of risk management that’s appropriate for the organization and project. Participants shouldn’t see the process as an unrewarding administrative burden. In some cases, the increased awareness resulting from risk management is more valuable than the re­sulting plans and initiatives.
• Balance participation. Distributed teams vary in size and complexity. In some cases, you only want to involve a few participants from each site. In other cases, you might find it useful to involve all team members. Regardless of the number of participants, establishing an open and safe communication climate is vital for ef­ficient risk management.
• Adapt taxonomies. We’ve designed our pro­cess for a variety of preferences. Some elements of the architecture might not fit your project or organization. For example, you might want to include additional resolution techniques - a specific consultant, a particular course, or available technologies - when developing risk mitigation plans.
• Integrate plans. Managing distributed-team risks is only one aspect of risk management. Moreover, risk management is only one of many key disciplines in project management. For each project, you need to integrate the process into project management at large. Ap­propriate software systems can be a significant help in such integrations.
• Attract capabilities. Practicing the process will clarify the specific capabilities needed to effectively manage distributed teams. As you move forward through the project life cycle, or as you engage in new distributed teams, you should attract complementary capabilities to proactively reduce the probability and impact of distributed-team risks.

Talented managers make projects work re­gardless of collocation or distribution. Our risk management process can help managers to sys­tematically assess and control the risks they face in specific distributed projects. By utilizing the extensive literature on distributed teams[44] and es­tablished practices for developing software[45], we hope the process can help managers avoid the failures and repeat the successes of past distrib­uted teams.

About the Authors 

John Stouby Persson is a postdoctoral student in Aalborg University’s Department of Computer Science. His research interests include information systems development, IT project management, and virtual organizations. Persson received his master’s degree in informatics from Aalborg University. He’s a member of the Association for Information Systems. Contact him at john@cs.aau.dk.

Lars Mathiassen is a Georgia Research Alliance Eminent Scholar and professor in Georgia State University’s Department of Computer Information Systems and cofounder of its Center for Process Innovation. His research interests include information systems and software engineering, with an emphasis on process innovation. Mathiassen has a PhD in informatics from Oslo University and a Dr. Techn. in software engineering from Aalborg University. He coauthored Computers in Context (Blackwell, 1993), Object Oriented Analysis & Design (Marko Publishing, 2000), and Improving Software Organizations (Addison-Wesley, 2002). He’s a member of the IEEE, the ACM, and the Association for Information Systems. Contact him at lmathiassen@ceprin.edu.

This article first appeared in IEEE Software magazine. IEEE Software's mission is to build the community of leading and future software practitioners. The magazine delivers reliable, useful, leading-edge software development information to keep engineers and managers abreast of rapid technology change.

[1] J.D. Herbsleb and D. Moitra, “Global Software De­velopment,” IEEE Software, vol. 18, no. 2, 2001, pp. 16–20.

[2] S. Sakthivel, “Managing Risks in Offshore Systems Development,” Comm. ACM, vol. 50, no. 4, 2007, pp. 69–75.

[3] S. Sakthivel, “Managing Risks in Offshore Systems Development,” Comm. ACM, vol. 50, no. 4, 2007, pp. 69–75.

[4] C.B. Gibson and J.L. Gibbs, “Unpacking the Concept of Virtuality: The Effects of Geographic Dispersion, Electronic Dependence, Dynamic Structure, and Na­tional Diversity on Team Innovation,” Administrative Science Quarterly, vol. 51, no. 3, 2006, pp. 451–495.

[5] D.C. Gumm, “Distribution Dimensions in Software Development Projects: A Taxonomy,” IEEE Software, vol. 23, no. 5, 2006, pp. 45–51.

[6] J.S. Persson et al., “Managing Risks in Distributed Soft­ware Projects: An Integrative Framework,” IEEE Trans. Eng. Management, vol. 56, no. 3, 2009, pp. 508–532.

[7] CMMI Product Team, CMMI for Development, v. 1.2, tech. report CMU/SEI-2006-TR-008, Carnegie Mellon Software Eng. Inst., 2006.

[8] B.W. Boehm, “Software Risk Management—Principles and Practices,” IEEE Software, vol. 8, no. 1, 1991, pp. 32–41.

[9] M.K. Kulpa and K.A. Johnson, Interpreting the CMMI: A Process Improvement Approach, CRC Press, 2003.

[10] J.S. Persson et al., “Managing Risks in Distributed Soft­ware Projects: An Integrative Framework,” IEEE Trans. Eng. Management, vol. 56, no. 3, 2009, pp. 508–532.

[11] J.S. Persson et al., “Managing Risks in Distributed Soft­ware Projects: An Integrative Framework,” IEEE Trans. Eng. Management, vol. 56, no. 3, 2009, pp. 508–532.

[12] B.W. Boehm, “Software Risk Management—Principles and Practices,” IEEE Software, vol. 8, no. 1, 1991, pp. 32–41.

[13] CMMI Product Team, CMMI for Development, v. 1.2, tech. report CMU/SEI-2006-TR-008, Carnegie Mellon Software Eng. Inst., 2006.

[14] J.M. Bhat, M. Gupta, and S.N. Murthy, “Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing,” IEEE Software, vol. 23, no. 5, 2006, pp. 38–44.

[15] S. Sakthivel, “Virtual Workgroups in Offshore Systems Development,” Information and Software Technology, vol. 47, no. 5, 2005, pp. 305–318.

[16] J.S. Persson et al., “Managing Risks in Distributed Soft­ware Projects: An Integrative Framework,” IEEE Trans. Eng. Management, vol. 56, no. 3, 2009, pp. 508–532.

[17] A. Powell, G. Piccoli, and B. Ives, “Virtual Teams: A Review of Current Literature and Directions for Future Research,” The Data Base for Advances in Information Systems, vol. 35, no. 1, 2004, pp. 6–36.

[18] M.K. Kulpa and K.A. Johnson, Interpreting the CMMI: A Process Improvement Approach, CRC Press, 2003.

[19] J.M. Bhat, M. Gupta, and S.N. Murthy, “Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing,” IEEE Software, vol. 23, no. 5, 2006, pp. 38–44.

[20] D. Damian, “Stakeholders in Global Requirements Engineering: Lessons Learned from Practice,” IEEE Software, vol. 24, no. 2, 2007, pp. 21–27.

[21] CMMI Product Team, CMMI for Development, v. 1.2, tech. report CMU/SEI-2006-TR-008, Carnegie Mellon Software Eng. Inst., 2006.

[22] J.M. Bhat, M. Gupta, and S.N. Murthy, “Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing,” IEEE Software, vol. 23, no. 5, 2006, pp. 38–44.

[23] S. Sakthivel, “Virtual Workgroups in Offshore Systems Development,” Information and Software Technology, vol. 47, no. 5, 2005, pp. 305–318.

[24] J.S. Persson et al., “Managing Risks in Distributed Soft­ware Projects: An Integrative Framework,” IEEE Trans. Eng. Management, vol. 56, no. 3, 2009, pp. 508–532.

[25] S. Sakthivel, “Managing Risks in Offshore Systems Development,” Comm. ACM, vol. 50, no. 4, 2007, pp. 69–75.

[26] C.B. Gibson and J.L. Gibbs, “Unpacking the Concept of Virtuality: The Effects of Geographic Dispersion, Electronic Dependence, Dynamic Structure, and Na­tional Diversity on Team Innovation,” Administrative Science Quarterly, vol. 51, no. 3, 2006, pp. 451–495.

[27] D.C. Gumm, “Distribution Dimensions in Software Development Projects: A Taxonomy,” IEEE Software, vol. 23, no. 5, 2006, pp. 45–51.

[28] A. Powell, G. Piccoli, and B. Ives, “Virtual Teams: A Review of Current Literature and Directions for Future Research,” The Data Base for Advances in Information Systems, vol. 35, no. 1, 2004, pp. 6–36.

[29] F.W. McFarlan, “Portfolio Approach to Information Systems,” Harvard Business Rev., vol. 59, no. 5, 1981, pp. 142–150.

[30] J.H. Iversen, L. Mathiassen, and P.A. Nielsen, “Manag­ing Risk in Software Process Improvement: An Action Research Approach,” MIS Quarterly, vol. 28, no. 3, 2004, pp. 395–433.

[31] CMMI Product Team, CMMI for Development, v. 1.2, tech. report CMU/SEI-2006-TR-008, Carnegie Mellon Software Eng. Inst., 2006.

[32] J.S. Persson et al., “Managing Risks in Distributed Soft­ware Projects: An Integrative Framework,” IEEE Trans. Eng. Management, vol. 56, no. 3, 2009, pp. 508–532.

[33] B.W. Boehm, “Software Risk Management—Principles and Practices,” IEEE Software, vol. 8, no. 1, 1991, pp. 32–41.

[34] B.W. Boehm, “Software Risk Management—Principles and Practices,” IEEE Software, vol. 8, no. 1, 1991, pp. 32–41.

[35] J.S. Persson et al., “Managing Risks in Distributed Soft­ware Projects: An Integrative Framework,” IEEE Trans. Eng. Management, vol. 56, no. 3, 2009, pp. 508–532.

[36] C.B. Gibson and J.L. Gibbs, “Unpacking the Concept of Virtuality: The Effects of Geographic Dispersion, Electronic Dependence, Dynamic Structure, and Na­tional Diversity on Team Innovation,” Administrative Science Quarterly, vol. 51, no. 3, 2006, pp. 451–495.

[37] E.T. Hall, Beyond Culture, Anchor Press, 1977.

[38] J.S. Persson et al., “Managing Risks in Distributed Soft­ware Projects: An Integrative Framework,” IEEE Trans. Eng. Management, vol. 56, no. 3, 2009, pp. 508–532.

[39] B.W. Boehm, “Software Risk Management—Principles and Practices,” IEEE Software, vol. 8, no. 1, 1991, pp. 32–41.

[40] CMMI Product Team, CMMI for Development, v. 1.2, tech. report CMU/SEI-2006-TR-008, Carnegie Mellon Software Eng. Inst., 2006.

[41] B.W. Boehm, “Software Risk Management—Principles and Practices,” IEEE Software, vol. 8, no. 1, 1991, pp. 32–41.

[42] M.K. Kulpa and K.A. Johnson, Interpreting the CMMI: A Process Improvement Approach, CRC Press, 2003.

[43] M.K. Kulpa and K.A. Johnson, Interpreting the CMMI: A Process Improvement Approach, CRC Press, 2003.

[44] J.S. Persson et al., “Managing Risks in Distributed Soft­ware Projects: An Integrative Framework,” IEEE Trans. Eng. Management, vol. 56, no. 3, 2009, pp. 508–532.

[45] CMMI Product Team, CMMI for Development, v. 1.2, tech. report CMU/SEI-2006-TR-008, Carnegie Mellon Software Eng. Inst., 2006.