Risk Mitigation Advice for Global Software Development from Systematic Literature Reviews

Risk Mitigation Advice for Gloal Software Development from Systematic Literature Reviews J. Verner, O. P. Brereton, B. Kitcenam, M. Turner, M. K. Niazi TR-2012-02 ISSN 1353-7776. Feruary 2012 Scool of Computing and Matematics Keele University Keele, Staffordsire, ST5 5BG UK

Risk Mitigation Advice for Gloal Software Development from Systematic Literature Reviews J. M. Verner, O. P. Brereton, B. A. Kitcenam, M. Turner, Keele University, Staffordsire ST5 5BG, United Kingdom Context: Gloal software development (GSD) projects are often large-scale and, as tey tend to e complex, ave an increased risk of failure. Ojective: We wis to identify wat risk mitigation advice is provided to organizations in order to increase te likeliood of GSD project success. Metod: We extend an earlier tertiary systematic review (SLR) in GSD to extract data from te SLR studies identified in order to discover: 1) wat advice is provided to practitioners to increase te cances of project success, 2) wat is te strengt of te advice, and 3) to wom is te advice addressed. Results: We found 428 advice items tat we categorized under four major eadings: outsourcing rationale, software development, uman resources, and project management. Most of te suggestions were related to agile metods (16%) and communication and collaoration (13%). Conclusions: Te majority of our SLRs focussed on mapping te researc rater tan providing guidance to industry. Suggestions are mainly for vendor project managers and vendor practitioners. Tere is low empirical support for most of te advice provided. 1 INTRODUCTION Te aim of tis researc is to identify practitioner advice, and te crediility of tat advice, from te GSD SLRs we identified in previous researc [17]. A toroug understanding of wat works in successful GSD projects can elp decrease GSD risk and tus increase te likeliood of a successful project outcome. By project success we mean tat te client of a development project elieves tat te project as met teir expectations. Te software development paradigm is canging wit te increasing use of GSD; a numer of different GSD usiness models ave een identified [e.g. 2, 9]. GSD can e used to descrie one or more of te following situations: organizations tat ave sifted all or part of teir software development offsore to lower cost destinations, or to destinations were te required skills are more readily availale, or organizations tat ave distriuted teir software development activities across multiple sites wic are in different countries, e.g., IBM, Bosc, and Siemens [3]. Software may e developed gloally y an organization to use itself, or to sell, or to incorporate into a device tat te company sells (in-sourcing), e.g., Siemens. A client company may outsource software development to a vendor wo ten develops te required software for te company. Te vendor may e located in te same country (outsourcing) or in a different country (GSD). GSD projects M. Niazi Keele University, United Kingdom and KFUPM, Saudi Araia are often large-scale, and gloal development leads to significantly increased complexity; GSD complexity leads to increased risk. Suggestions ave een made tat a 50% failure rate for GSD projects is not uncommon [14]. Offsore projects tend to e unsuccessful, ecause pysical time, cultural, organizational, and stakeolder distances negatively influence communication and knowledge excange etween onsore and offsore project team memers [9]. Wen a software project is developed in multiple countries, te vendor project manager must address additional execution risks, including tose related to project distriution, time zone differences, communication, coordination and control, project contextual issues, and infrastructure [4, 10, 12]. To deal wit te increased risk te client must monitor te development closely [1, 16]. Our previous researc [17] identified 24 GSD SLR studies descried in 37 papers; we now extend tat researc y using tem to discover: RQ1 Wat advice do te GSD SLR studies provide to practitioners RQ2 Wat is te strengt of tat advice RQ3 Wo is te intended recipient of te advice In te next section we riefly descrie our researc metodology; in Section III we present our results. Section IV provides a discussion of te limitations of our researc, wile Section V presents a discussion and conclusions. II RESEARCH METHODOLOGY A SLR of any kind is a metod of identifying, evaluating and interpreting all availale researc relevant to a particular researc question or topic area or penomenon of interest [13]. Te aim is to syntesize existing evidence in a fair, rigorous, and open manner. After specifying researc questions a review protocol is developed; tis includes definitions of: (1) te searc process, (2) inclusion and exclusion criteria, (3) te selection process, (4) te data extraction process, and (5) data syntesis. 1. Searc Process Te searc process employed is descried in detail in [17]; tus we will provide only an outline ere. Our searc, wic identified SLRs addressing GSD, was road, comining automated and manual searces. We identified peer-reviewed articles pulised (or availale on-line) up to

Octoer 2011. Seven searc engines and indexing systems plus manual searces of two conference proceedings were used; in addition iliograpies of all selected papers were scanned for additional papers (snowalling). 2. Inclusion/Exclusion criteria Articles were included if tey: Reported SLRs or meta-analyses in GSD Were pulised in, or sumitted to, a conference or journal or were tecnical reports or ook capters Were written in Englis Articles were excluded if tey were: Masters and PD studies not pulised in refereed conferences or journals Informal literature surveys (no defined searc questions, no searc process, no defined data extraction or data analysis process) Papers discussing te process of performing SLRs, or meta-analyses SLRs relating to topics suc as evaluating installed systems and applications, IT services, software applications and IT operations SLRs dealing wit open source software development SLRs related to teacing and education. 3. Paper Selection Our searc resulted in te identification of 24 studies reported in 37 papers. Wen we compared te papers we selected wit tose found in previous tertiary SLR studies tat included GSD researc [6, 11, 12] we found tat we ad not missed any appropriate papers. We reference te studies included in our researc and listed in Tale 1 wit a study numer, e.g., [S12]. If tere is more tan one paper reporting te same study we follow (te study numer) wit a letter referring to te particular paper, e.g., [S12]. For tis extension to our study, te first autor read all papers relating to te 24 studies and excluded tose tat did not provide any advice to practitioners. Eigt studies [S2, S3, S4, S9, S12, S14, S20, S24] were excluded, leaving 16 studies and 28 papers for furter investigation. Te excluded papers all ad a researc focus, e.g., wo is doing te researc, mapping te researc, gaps in te researc, etc. 5. Data extraction Te following details ad previously een extracted from te studies identified: paper title, autor names, affiliations, pulication venues, main GSD topic, and te numer of primary studies included in te SLR [17]. A data extraction form specifically related to advice for practitioners was provided to eac of te researcers. Details extracted included paper id, main advice category (ased on Tale 5 in [17] namely outsourcing vendor selection, arcitecture, development process, project management, requirements engineering, configuration management, collaoration, culture, communication, collaoration and control), advice su-category, specific details of te advice, and strengt of te advice, i.e., te SLRs and te numer of primary papers tat provide support for te advice. If an appropriate advice category or su-category was not availale te researcers were asked to define extra categories as required. Te first autor extracted advice from eac of te studies. To ceck er data extraction te oter four autors eac derived advice from all papers relating to two studies. Tis gave us eigt studies were we could compare te first autor s data wit tat extracted y te oter autors (tus giving a xx% data extraction ceck). Any advice relating to tools and metods, and supported only y te developers of te tool or metod, was excluded. 6. Data syntesis To answer our researc questions we sorted te advice first on general advice category ten on su-category. We next used tematic analysis [15] to organize te advice into appropriate temes and su-temes. After some reorganization of topics and su-topics te following temes were identified: 1. GSD outsourcing rationale, including ig level strategy and detailed strategy. 2. software development, including requirements engineering, arcitecture, software development metods, and configuration management. 3. uman resources including culture and social integration, training, communication, and collaoration. 4. project management including planning, risk management, coordination, and control. III RESULTS In tis section, wic is organized y te temes and sutemes identified in te researc, we report te results related to our researc questions. Tale 1 lists te GSD studies included in tis researc. As noted earlier, we excluded eigt studies from te earlier researc as tey did not supply any advice to practitioners altoug we ave retained te initial study numering. Tus we ave 16 studies reported in 28 papers. Primary studies included in our SLR studies ranged from 12 [S6] to 122 [S13] (See Tale 1); only one study, [S1], did not make clear ow many primary studies were included in teir SLR. Overall we identified a total of 428 items of advice. Tematic analysis was difficult as many items of advice overlapped two or more temes, e.g., Te SCM manager and project manager sould properly plan aselines and document tem in te SCMP can e considered planning advice as well as advice on configuration management. Tus, we classified advice items were we felt tey est fitted ut oter researcers may ave classified te advice differently. We discuss te temes identified in more detail elow, and order te advice for eac su-teme y te numer of supporting SLR studies and te numer of primary studies providing support if tis is availale.

Study No of Primary Studies S1 unknown 1.5 a S5 Tale 1: GSD SLR Studies and papers reporting tose studies Quality Paper Reference 70 3 a S6 12 1.5 S7 24 3 S8 20 3 S10 77 2 a S11 60 2.5 a c 69 78 c S13 122 2.5 a S15 36 2 S16 26 2 S17 86 1.5 S18 S19 a 72 3 30 3 a c Ågerfalk P. J., B., Holmström H., Lings B., Lundell B., Concúir E.Ó., (2005) "A Framework for Considering Opportunities and Treats in Distriuted Software Development" Proceedings of te International Worksop on Distriuted Software Development, Austrian Computer Society, p.p 47-61. Lings B., Lundell B., Agerfalk P., and Fitzgerald B., (2006) "Ten strategies for successful distriuted development", Te Transfer and Diffusion of Information Tecnology for Organizational Resilience, Springer, pp. 119-137. da Silva F. Q. B., Prikladnicki R., França A. C. C., Monteiro C. V. F., Costa C., Roca R., (2011) "Researc and Practice of Distriuted Software Development Project Management: A Systematic Mapping Study" sumitted to Information and Software Tecnology. da Silva F.Q.B., Prikladnicki R., França A., Monteiro, Costa C., Roca R.,(2011) "An evidence-ased model of distriuted software development project management: results from a systematic mapping study", Journal of Software Maintenance and Evolution: Researc and Practice (on line). da Silva F.Q.B., Costa C., França A.C.C., Prikladnicki R., (2010) "Callenges and solutions in Distriuted Software Development Project Management: A systematic literature review" Proceedings of te 5t International Conference on Gloal Software Engineering, (ICGSE), pp. 87-96. Eling, T., Audy, J.L.N., Prikladnicki, R., (2009) "A systematic literature review of requirements engineering in distriuted software development environments" ICEIS 2009,Proceedings of te 11t International Conference on Enterprise Information Systems,, ISAS, pp. 363-366. Fauzi S. S. M., Bannerman P. L., and Staples M., (2010) "Software Configuration Management in Gloal Software Development; A Systematic map" APSEC '10 Proceedings of 2010 APSEC, pp.404-413 Hossain E., Ali Baar M., Paik H.-Y., (2009) "Using scrum in gloal software development: A systematic literature review" Proceedings - 2009 4t IEEE International Conference on Gloal Software Engineering, ICGSE, pp. 175-184. Jalali, S., Wolin, C. (2011) "Gloal software engineering and agile practices: a systematic review" Journal of Software Maintenance and Evolution: Researc and Practice (on line). Jalali, S., Wolin, C., (2010) "Agile practices in gloal software engineering - A systematic map" Proceedings of te 5t International Conference on Gloal Software Engineering, ICGSE 2010, pp. 45-54. Jiménez M., Piattini M., and Vizcaino A., (2010) "A Systematic Review of Distriuted Software Development: Prolems and Solutions" capter in Handook of Researc on Software Engineering, IGI Gloal and Productivity Tecnologies: Implications of Gloalization, pp 209-225 Jimenez M., Piattini M., (2009) "Prolems and solutions in Distriuted Software Development: A Systematic Review" Second International Conference on Software engineering approaces for offsore and outsourcing development, LNIBIP Vol. 16, pp107-125. Jiménez M., Piattini M., and Vizcaino A., (2009) "Callenges and improvements in distriuted software development: A systematic review" Advances in Software Engineering. Kan, S.U., Niazi, M., Amad, R., (2011) "Factors influencing clients in te selection of offsore software outsourcing vendors: An exploratory study using a systematic literature review" Journal of Systems and Software, 84 (4), pp. 686-699. Kan, S.U., Niazi, M., Amad, R., (2009) " Critical success factors for offsore software development outsourcing vendors: a systematic literature review" Proceedings - 2009 4t IEEE International Conference on Gloal Software Engineering, ICGSE, pp. 207-216. López, A., Nicolás, J., Toval, A., (2009) "Risks and safeguards for te requirements engineering process in gloal software development" Proceedings - 2009 4t IEEE International Conference on Gloal Software Engineering, ICGSE, pp. 394-399. Noll J., Beecam S., Ricardson I., (2010) "Gloal software development and collaoration: arriers and solutions" August, ACM Inroads, Volume 1 Issue 3 Nurdiani I., Jaangwe R., Smite D., Damian D., (2011) "Risk Identification and Risk Mitigation Instruments for Gloal Software Engineering: A systematic review and survey results" PARIS worksop ICGSE. Persson J S., Matiassen L., (2011) "A process for managing risks in Distriuted teams" IEEE Software 27, 1. Jan- Fe., pp 20-29. Persson J.S., Matiassen L., Boeg J., Madsen T. S., Steinson F., (2009) "Managing Risks in Distriuted Software Projects An Integrative framework", IEEE TEM Vol 56 Iss 3 August, pp 508-532. Prikladnicki R., Audy, J.L.N., (2010) "Process Models in te practice of distriuted software development: A systematic review of te literature", Information and Software Tecnology Vol 52 No 8, August, pp779-791. Prikladnicki, R., Audy, J.L.N., Sull, F., (2010) "Patterns in effective distriuted software development" IEEE Software, 27 (2), pp. 12-15. Prikladnicki R., Damien D., and Audy J. L. N., (2008) "Patterns of evolution in te practice of distriuted software development: quantitative results from a systematic review" Evaluation and Assessment in Software Engineering (EASE), Bari, Italy, pp. 1 10.

S21 59 2.5 a c S22 42 2 S23 83 2.5 Šmite, D., Wolin, C., Gorscek, T., Feldt, R. (2010) "Empirical evidence in gloal software engineering: A systematic review" Empirical Software Engineering, 15 (1), pp. 91-118. Šmite, D., Wolin, C., (2011) A wisper of evidence in gloal software engineering IEEE Software, 28 (4), pp. 15-18 Šmite D., Wolin C., Gorscek T., Feldt R., (2008) "Reporting Empirical Researc in Gloal Software Engineering: a classification sceme" International Conference on Software Engineering (ICGSE) Steinmacer I., Caves A.P., Gerosa, M.A., (2010) "Awareness support in gloal software development: A systematic review ased on te 3C collaoration model" 16t International Worksop on Groupware (CRIWG), Lecture Notes in Computer Science (including suseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), LNCS, pp. 185-201. Treude C., Storey M-A., Weer J., (2009) " Empirical studies on collaoration in software development A systematic Literature Review" Review Literature And Arts Of Te Americas and Tecnical Report DCS-331-IR, Department of Computer Science, University of Victoria, Decemer. We list up to ten items of advice for eac su-teme. An () indicates tat te SLR wic furnised te advice did not specify te numer of primary studies ut te autors considered tat te item ad a ig level of support. A () denotes tat te SLR did not specify te degree of support for te advice item. 3.1 Outsourcing rationale Advice is provided on two levels, a ig level strategy, and a detailed strategy. Seven studies [S1, S5, S13, S15, S16, S17, S19] contriute 30 outsourcing rationale items of advice. All recommendations are for senior management in te client organization altoug as [S13] note, successful senior vendor management must e aware of teir clients selection criteria. 3.1.1 Hig GSD Strategy Five studies consider ig level client GSD strategy [S1, S5, S16, S17, S19] toug only eigt items of advice were identified. In most cases te strengt of te advice is not well supported; te est supported as 2 SLRs wit a maximum of eigt primary studies. Two SLR studies agree on tree items: 1) considering intellectual property issues, and 2) on GSD project selection criteria. Tale 2 lists recommendations related to ig level GSD strategy. 3.1.2 Detailed GSD Strategy Advice items were provided from y two SLR studies [S13, S15]. Most recommendations were related to vendor selection. Because of te larger numer of primary studies cited y [S13] tere is muc more support for tis suteme, ranging from 89 to 39 primary studies. Tale 3 lists details of te advice extracted. 3.2 Software Development Tere are a numer of software development lifecycle pases and some are addressed in our studies. Most of te software development advice we found relates to 1) requirements engineering, 2) software development metods, 3) arcitecture, and 4) software configuration management. Many suggestions, relating to te development process, are for vendor practitioners; most for te vendor project manager, toug some advice is appropriate for project leads, tecnical leads, quality assurance managers and software developers. However, it sould not e forgotten tat te client project manager must continuously monitor wat is appening during te development process. Of course during requirements engineering ot client and vendor need to e involved. A numer of suggestions were made in our SLRs regarding experimental requirements engineering tools and tecniques tat ad only te support of te researcers wo were responsile for te primary study, accordingly tey were excluded. Tale 2: Hig GSD Strategy Advice level 3 Consider intellectual property wit effective policies for confidentiality, copyrigt protection, and intellectual property. GSD projects sould e undertaken only wen potential enefits outweig risks. Consider te appropriateness of te approac at te outset. Not all projects are well suited to an offsore model: te complexity of te project, including coordination, requirements, process, organizational issues, and risks, must e considered and addressed at te outset, and may outweig te potential enefits. Stale projects wit well-understood ojectives and mature teams are te est candidates Document te reasons for selecting one strategy over anoter Decide on te tasks to e performed y distriuted teams Te peculiarities of GSD ave to e recognised and planned for early in te project life-cycle, as delays reduce te aility to react to adverse events Develop a strategy selection process tat igligts te DSD-related decisions tat ave to e made Have a clear distriution rationale. Only consider DD for well structured, well understood and stale projects, decomposale into discrete tasks. Tis addresses primarily prolems associated wit temporal distance y reducing te need for communication, wic in turn simplifies coordination and control. [S19] 8 [S1] [S19] 8 [S19] 8 [S19] 8 [S1]

Tale 3: Detailed GSD Strategy Advice Advice Study Suppo rt Use GSD wen you can acieve cost savings [S13] 89 Take into account te developers skills [S13] 82 Consider te vendor s infrastructure [S13] 73 Consider te vendor s product and service quality [S13] 69 Ensure tere is efficient outsourcing relationsips [S13] 59 management Select a vendor wit a good track record of successful [S13] 53 projects Select a vendor wit efficient project management [S13] 47 Select a vendor wit effective contract management [S13] 45 Select a vendor wit SPI certification [S13] 41 Select a vendor wit knowledge of te client s language and culture [S13] 39 3.2.1 Requirements engineering Most of te recommendations deal wit communicating requirements, and metods for modelling requirements, so tat developers may more easily understand tem. Four studies [S6, S11, S15, S17] furnis 25 items of advice. Tere is not a great deal of support for any of te items wit none supported y more tan one SLR and tree primary studies. Most suggestions are for te vendor project manager and developers, wit some for te client project manager. Tere are overlaps wit arcitecture, communication and project management, in te advice provided. Tale 4 gives advice details. Tale 4: Requirements Engineering Advice Define a person responsile for requirements [S6] 3 specification and prioritization Apply personal domain knowledge [S6] 3 Provide for te use of direct communication cannels [S6] 3 etween te developers Requirements sould e clearly defined and modelled [S11] 1 in order to make tem easily understood, and dependencies among modules sould e identified in te arcitecture To overcome geograpical distance perform joint requirements analysis RE process must e precisely defined and [S15] documented A common requirements notation sould e cosen, [S15] followed, and understood y every work group. A tool wic facilitates requirements elicitation process in a GSD environment sall e used. [S15] 3.2.2 Software Development Metods Seven studies [S5, S8, S10, S11, S16, S19, S23] (%), provide recommendations related to te software development process. A major focus is on te use of agile metods in GSD wit 87% of te advice relating to tis metodology. 3.2.2.1 Agile development Five studies [S5, S8, S10, S19, S23], 31% of our studies, furnis 64 items of advice related to agile metods. Most recommendations are related to 1) specific agile metods (25%), e.g., retrospective, acklog, sort iterations etc., and 2) communication in te vendor environment (23%). Tere is some agreement on te recommendations y te different studies particularly regarding tools required for agile practice support. Advice temes (and te numer of items of advice) include metods (16), communication (15), coordination (4), control (3), cultural distance (3), process (3), and tools (3). Almost all te suggestions (97%) are intended for te vendor project manager, vendor project leads and programmers. Tale 5 gives details of te advice. Tale 5: Agile Development Advice Advice Study Suppo rt Proactive resource management elps ensure tat a Scrum team as te necessary tools and skills to support teir Scrum practices in distriuted settings. Along wit communication tools, Scrum teams use a numer of collaorative tools including Wikis, Blogs, social ook marking, expertise finders, witeoards, electronic work space, desktop and application saring, poto carts, knowledge ases, experience dataases, lesson learned repositories, wile using Scrum practices. Use continuous integration [S8] [S23] [S10] [S8] [S10 18 12 Institute stand up meetings [S8] [S10] 16 18 Use pair programming [S8] 14 Use retrospectives [S10] 11 6 To increase te project memers domain [S19] 10 knowledge and reduce cultural distance, a Scrum team gaters and performs a few initial sprints at one site efore distriuted development starts. [S10] 13 Te memers of a distriuted Scrum team are gatered quarterly or annually for few days. During tis gatering, a Scrum team can perform scrum planning, review meetings, retrospectives, sprints and various socializing activities, wic can elp to reduce cultural distance Communication can e enanced troug working ours; working from ome, working long ours, adjusting working ours etc. Some Scrum teams use strategies to avoid te need for increased overlap time. To make te meetings sort and effective, team memers post teir tree daily Scrum questions or develop a acklog (feature list) efore attending te distriuted meetings Use scrum of scrums [S19] [S10] 20 2 10 4 [S8] 10 [S8] 6 [S10] Use test driven development [S8] 9 3.2.2.2 Oter Development Metods Five SLR studies [S5, S8, S11, S15], S16] furnis advice related to oter development metods and all recommendations are meant for te vendor project manager.

Te most supported advice relates to using te same processes across all sites. Tale 6 provides details of te suggestions. Tale 6: Oter Development Metods Advice Advice Study Sup port Leve l To use and maintain common software processes among sites [S10] 5 Delay can e mitigated y processes tat include 2 frequent iterations and delivery of code increments Participants sould receive training on process 4 elements Document and follow general software engineering 3 est practices for projects, suc as project management structure, requirements engineering, project life cycle, etc. Apply MDD approaces to automate development [S11] 2 tasks Negative effects can e mitigated troug te [S8] deployment of structured software engineering processes Institute incremental integration and frequent [S11] 1 deliveries y following informing and monitoring practices Te maturity of te process ecomes a key success [S11] factor Use automated code inspections and te [S11] application of coding standards 3.2.3 Arcitecture Five studies [S1, S5, S11, S16, S17] give arcitectural advice; in all we were ale to identify a total of nine items. Recommendations include 1) leverage modularity, 2) develop a stale arcitecture, and 3) knowledge management. Tere are some overlaps wit geograpic distriution and communication. Support for te suggestions is fairly low and all te advice is intended for te vendor project manager. Tale 7 provides details of te recommendations. 3.2 4 Configuration management Five studies [S1, S5, S7, S11, S17] furnis configuration management (SCM) advice toug unfortunately te autors do not tell us muc of te time ow muc evidence supports teir recommendations. Oter studies suc as provide more general suggestions. Tirteen advice items, including using a SCM system are provided toug most ave little support. Te configuration management recommendations ave some overlap wit communication and project management. Te advice is meant for te vendor project manager, vendor configuration manager and developers. Tale 8 presents details of te suggestions. 3.3 Human resources We divided te recommendations into tree su-temes: culture and social integration, training, and communication and collaoration. Tale 7: Arcitecture Advice Advice Study Sup port Leve l Divide te work into well defined modules and carry 7 out progressive integration Distriute tasks ased on arcitectural decoupling and low dependencies across remote locations Te system arcitecture sould mirror te structure [S1] of te organisation wic uilt it, so for te software development work, plan te arcitecture of te system around te distriuted structure of te team. Tis will reduce te need for intensive collaoration, and allow optimum utilisation of local skills Leverage modularity. Te system arcitecture [S1] sould e designed to reflect te geograpical (and competence) structure of te project. In tis way local expertise can e utilised efficiently, tus reducing potential coordination and control prolems Documentation must always e updated and [S11] structured to prevent assumptions and amiguity, terefore facilitating te maintainaility of te software developed Software arcitecture evaluation usually involves a large numer of stakeolders wo need face-to-face evaluation meetings, and adequate collaorative tools are terefore needed [S11] Tale 8: Configuration Management Advice Deploy and use a configuration management system. [S11] 4 All team memers involved in GSD sould agree on a [S7] 3 common configuration management process. Implement cross workspace analysis of ongoing [S7] 2 canges and wit notification to oter workspaces wen indirect conflicts are found. Before development starts, essential SCM concepts [S7] 1 sould e explained, to elp to estalis and clarify te main concepts of SCM for eac developer. Te SCM manager and project manager sould [S23] 1 properly plan aselines and document tem in te SCMP. Well-defined tasks (specifying certain tasks or roles for certain parts in te development) can e used to increase SCM awareness among team memers. [S7] 3.3.1 Culture and social integration Five studies provide 42 items of advice related to culture and social integration [S1, S5, S15, S17, S18]. All five SLRs agreed on using cultural mediation and tree SLRs on developing liaisons etween sites, and using cultural facilitators. Support for te recommendations is fairly low and te advice is mainly for te vendor project manager. Items overlap wit communication and collaoration. Tale 9 lists details of te suggestions.

Tale 9: Culture and Social Integration Advice Use cultural mediation; it is wort spending resources on reducing socio-cultural distance y means of facilitating face-to-face meetings. Have at least some people at eac node wo ave met people at peer [S1] 4 nodes in person. Tis also reduces te perceived [S15] 1 geograpical distance, if not te pysical. Maintain team involvement and coesion 3 Human facilitators are important in getting te most out of video communication tecnology [S1] [S15] 3 Create teams wit complementary skills and cultures 3 Develop liaisons etween sites [S18] [S1] Develop a special terminology dictionary, use a common communication language, rotate teams across development sites and use team uilding exercises during visits Have cultural amassadors at te primary site (on-site or controlling site) Clarify all understandings is mainly a way to [S1] minimise potential misunderstandings and communication reakdowns wic can result from non-overlapping socio-cultural ackgrounds. Documenting suc tings as project goals and individual partner commitments elps to remove communication prolems oterwise caused troug differing interpretations of informal agreements Promote umour and openness [S18] Adopt a sared reward system [S18] 3.3.1 Training Five SLRs [S1, S5, S16, S17, S18] supply a few advice items for training; te recommendations overlap wit some related to collaoration and development metods. Tale 10 furnises details of te training items. Tale 10: Training Advice Provision of and training in collaoration and coordination Tools [S18] [S11] 10 1 Assess practices and capailities of individuals on DSD [S19] 5 teams; understanding weter team memers ave a sufficient understanding of software development practices for deployment in a gloal perspective Use mentors to integrate new memers [S18] Improve language skills [S18] Empasize early teamuilding activities Participants sould receive training on process elements. 4 3.3.2 Communication and collaoration It is very difficult to differentiate etween recommendations related to communication and collaoration so we consider te two togeter; te second igest numer of advice items (57), is related to tis su-teme. Eigt SLR studies [S1, S5, S11, S15, S16, S17, S22, S23], supply communication and collaoration advice. Tere is some agreement on several recommendations. Tale 11 gives details of te communication and collaoration items. Tale 11: Communication and Collaoration Advice Multiple communication modes including support to face-to-face syncronous communication 8 5 Trust can eiter strengten or undermine 6 collaoration among gloal teams Promote informal interactions Provide as muc of te "in person" communication experience as possile over distance, y adapting processes and organizational structure to address delays stemming from temporal distance To promote visits and excanges among sites [S23] [S15] [S23] [S11] 6 5 Set up meetings at times reasonale for most teams Create of communication protocols 6 Code repositories are a ric source of information for [S22] 6 awareness generation At te start of any project agree and communicate [S1] project goals and targets, and ensure tat commitments are genuinely understood. Estalisment of an efficient communication mecanism etween te memers of te organization, allowing a developer to discover te status and canges made witin eac project [S11] 2 3.4 Project management We divided te recommendations into tree su-temes: planning, risk management and control. We now discuss te advice provided to eac su-teme in turn. 3.4.1 Planning Five studies give planning recommendations [S1, S5, S11, S15, S18]. Tere were 14 advice items all meant for te vendor project manager. Tale 12 lists details of te planning items. 3.7.3 Coordination Six SLR studies [S5, S11, S16, S17, S21, S23] provide advice related to coordination altoug tis su-category is closely tied to control as well as communication and collaoration. Tere is not a great deal of support for te recommendations. Temporary collocation during critical pases [S17, S21] is te items wit te most support. Tale 13 lists te coordination items. 3.7.2 Risk management We identified tree items of advice from [S5, S11] tat we specifically classified as risk management altoug all te recommendations discussed ere relate to risk management. One item was descried an experimental tool and anoter as

an experimental metod. Te only oter item supported y ot SLRs was to perform constant risk management. Te recommendation is meant for te vendor project manager altoug te client project manager sould also eed it. Tale 12: Planning Advice Advice Study Suppo rt Perform detailed planning 5 Plan and scedule distriuted tasks, taking into [S11] 2 account costs and dependencies etween projects, and te application of corrective measures and notifications Ensure infrastructure compatiility among geograpic locations [S15] 3 1 Divide te work into well defined modules and carry out progressive integration Deploy knowledge transfer mecanisms Set up meetings at times reasonale for most teams [s1] Divide tasks systematically etween sites [S18] Reduce coupling etween sites [S18] Secure office space for local teams [S11] 3.7.4 Control Eigt studies address GSD control [S1, S5, S11, S16, S17, S18, S22, S23]. Forty six items of advice were identified. Most recommendations relate to 1) socio-cultural distance (20%) and ence overlaps wit culture and social integration, and 2) geograpic distance (57%) wic as overlaps wit communication and coordination. Muc of te advice is for te vendor project manager. s of support are low or not defined. Tale 14 lists te most supported items. IV LIMITATIONS We may ave missed some studies and ence underestimated te extent of SLRs in GSD. However, as noted earlier, we cecked our papers against tose found in earlier work. No autors identified any papers descriing SLRs in GSD tat we did not find. We may also ave missed some advice items toug to ensure tat te data extracted was complete we compared a sample of te first autor s data extraction wit tat from te oter autors. Categorisation of te advice into temes was difficult ecause muc of te advice provided overlapped two or more temes. Different researcers would no dout come up wit different temes and sutemes. Many of te SLR papers ad titles tat included terms suc as map, review or profile. Te aim of most of our SLR studies was not to provide advice to industry, ut rater to present a summary of te literature, altoug some studies did make suggestions, almost as a y-product. However, tis does not invalidate te advice it simply made it more difficult to find. Tale 13: Coordination Advice Ensure work syncronization among sites and define 2 syncronization points among teams Deploy knowledge transfer mecanisms 5 Minimize numer distriuted development sites Temporary collocation during critical pases [S21] Responsiilities for eac site sould e cosen to reduce coordination requirements so tey can act wit a ig degree of autonomy Te development process must e adapted to [S11] provide team memers wit a etter awareness of te project status. It must terefore e automated to provide notifications of actions and decisions to te roles involved Well performed cooperation and coordination [S23] etween te development team and te operations team is crucial for successful deployment and operations of a new or extensively revised software system Multisite communication and coordination require [S11] more people to participate wic causes delays. Canges in multiple distriuted sites involve a large numer of people. More progress reports, project reviews, conference calls, and regular meetings to take corrective action are terefore needed to minimize task dependencies wit oter locations Create a project structure tat includes tasks & artefact dependencies Maintain and sare a project artefacts repository Tale 14: Control Advice Ensure visiility of work in progress [S11] 4 1 Have clearly defined roles and responsiilities [S18] 3 Secure IT infrastructure to ensure compatiility among geograpic locations 3 Maintain common quality standards among sites 2 Escalate prolems immediately 2 Tere is a need for a tecnical lead to serve as a 2 representative or deputy of te project manager at eac site Maintain team involvement and coesion 3 Use knowledge management systems 2 Work syncronization among sites: to define 2 syncronization points among teams Estalis communication guidelines 6 Use code annotation to present canges eing concurrently made y oter developers in a sared artefact. [S22] 2 We could not of course, sum te support identified y te different papers as te primary studies referred to y our SLRs, overlapped in many cases; ence we would ave een counting te same evidence twice. In addition many of

te SLR studies did not give details of te numer of primary studies tat supported te advice provided; tis made it difficult to e sure aout te degree of support for most advice items. Autors wo used an to indicate a ig level of advice did not specify wat te meant in terms of primary study support. V DISCUSSION AND CONCLUSIONS Tree of te studies we identified [S1, S13, S15] specifically extracted advice for industry from teir primary studies; tis certainly made data extraction from tose studies muc easier. Only [S13] was consistently clear aout te strengt of evidence for teir advice. Te majority of suggestions ad low levels of primary study support. Many SLR studies did not make clear to wom te recommendations were intended. Wile muc of te advice is oviously meant for te vendor project manager and vendor practitioners, most autors did not specify te recipient. Overall, te client is pretty muc ignored except for items relating to outsourcing rationale. Smite et al [S21a], note tat most of te empirical findings... for GSD studies are ased on intraorganizational industrial collaoration etween two geograpically distriuted sites. Tere is a clear lack of studies aout inter-organizational collaoration. Most GSD SLR studies do not make clear wat kind of usiness model is teir focus. Smite et al [S21a] also comment tat te numer of studies wit mixed, not descried, or unclear contexts is relatively ig. Is te focus a client in one country wit a vendor in anoter (inter-organizational), or is it a company wit susidiaries, eac wit software development capaility, in multiple countries (intraorganizational) Te primary studies from wic te SLRs extracted teir data may ave sometimes made tis clear, ut it is not at all ovious in our SLRs. It appears to us, tat different advice will e required wen different usiness models are used. If a client in country A, outsources to a single vendor in Country B wit a single site, te vendor company may need to employ a cultural liaison officer. However, after requirements ave een specified, risks related to control, coordination, and communication and culture etc., will e muc lower. Te vendor project manager will not ave to manage developers of multiple cultures at different sites. Higer level communication etween te client and vendor project managers will of course e required. We elieve tat more researc, related to te actual usiness models used for GSD, is necessary. We need to know more aout ow te usiness model used impacts te development itself. Significant researc and advice is related agile metods ut ow muc agile development is actually used in a GSD client-vendor situation is unclear. In conclusion, most of te SLRs we investigated produced a summary of te literature and mappings for researcers. Altoug some studies give advice for industry, many studies did not. In some cases industry recommendations were almost a y-product. As most of te studies did not include muc in te way of evidence, from teir primary studies to support te advice provided, we elieve tat more researc in tis area is required. Most recommendations were meant for vendor practitioners wit only a small percentage of items wit a client focus. We intend to continue researc in tis area and wis to identify risk and risk mitigation practices as tey relate to te GSD usiness models employed; we are particularly concerned wit te client perspective, We are also interested in investigating actual variations of te clientvendor usiness model and to identify te strengt of evidence supporting any risk mitigation practices. ACKNOWLEDGEMENT Verner s work is supported y te European Union Sevent Researc Framework. Se is a Marie Curie Fellow at Keele University. REFERENCES [1] Adulla L. M., Verner J.M., (2009) Outsourced Strategic IT Systems Development Risk IEEE RCIS, Fes, Morocco, April, pp. 309-320. [2] Beulen E., van Fenema P., Currie W., (2005) From Application Outsourcing to Infrastructure Management: Extending te Offsore Outsourcing Service Portfolio European Management Journal Vol. 23, No. 2, pp. 133-144. [3] Bondi A. B., Ross J. P., (2009) Experience wit Training a Remotely Located Performance Test Team in a Quasi-agile Gloal Environment, ICGSE, pp. 254-261. [4] Casey V. (2009) Leveraging or Exploiting Cultural Differences, ICGSE, Limerick, Ireland, pp.8-17. [5] Cruzes D. S., Dyå T, (2011), Researc syntesis in software engineering: A tertiary study, Information and Software Tecnology 53, no. 5: 440-455. [6] da Silva F. Q. B., Santos A. L. M, Soares S., Franca A. C. C., Monteiro C. V. F., and Maciel F. F., (2011) Six Years of systematic literature reviews in software engineering: An updated tertiary study, Information and Software Tecnology, availale online April 2011. [7] da Silva F. Q. B., Santos A. L. M, Soares S., Franca A. C. C., Monteiro C. V. F., (2010) A critical appraisal of systematic reviews in software engineering from te perspective of te researc questions asked in te reviews ACM-IEEE International Symposium on Empirical Software Engineering and Measurement. [8] da Silva FQB, Prikladnicki R., Franca ACC., Costa C., Roca R (2011) Researc and practice of distriuted software development project management: A systematic mapping study sumitted to Information and Software Tecnology. [9] Fariek M., van den Brand M., Brinkkemper S., Harmsen, F., Helms, R. (2008) Reasons for Success and Failure in Offsore Software Development Projects, European Conference on Information

Systems, Ireland, pp. 446-457. [10] Kan N., Fitzgerald G., (2004) Dimensions of Offsore Outsourcing Business Models Journal of Information Tecnology Case and Application, Vol 6, No 3 pp 35-50. [11] Kitcenam B., Pretorius R., Budgen D., Brereton O. P., Turner M., Niazi M., Linkman S., (2010) Systematic literature reviews in software engineering - A tertiary study, Information and Software Tecnology, Vol. 52, no. 8, pp. 792-805. [12] Kitcenam B., Brereton O. P., Budgen D., Turner M., Bailey J., Linkman S., (2009) Systematic Literature reviews in software engineering a systematic literature review, Information and Software Tecnology, 51(1), pp 7-15. [13] Kitcenam B., Carters S. (2007) Guidelines for performing Systematic Literature Reviews in Software Engineering, Keele University and Duram University Joint Report, EBSE 2007-001. [14] McCue A., (2005) Outsourcing flops lamed on tunnel vision, Silicon.com, Pulised on ZDNet News, June 22. [15] Tematic analysis ttp://wps.pearsoned.co.uk/ema_uk _e_owitt_resmetpsy_2/77/19811/5071812.cw/index. tml, retrieved 8/12/2011 [16] Verner J. M., and Adulla L. M., Exploratory Case Study Researc : Outsourced Project Failure, accepted y Information and Software Tecnology, Novemer 2011. [17] Verner J. M., Brereton O. P., Kitcenam B. A., Turner M., Niazi M., Systematic Literature Reviews in Gloal Software Development: A Tertiary Study sumitted to EASE 2012.