A Process Framework for Global Software Engineering Teams

Our reference: INFSOF 5221

P-authorquery-v11

AUTHOR QUERY FORM Journal: INFSOF

Please e-mail or fax your responses and any corrections to: E-mail: [email protected]

Article Number: 5221

Fax: +31 2048 52799

Dear Author, Please check your proof carefully and mark all corrections at the appropriate place in the proof (e.g., by using on-screen annotation in the PDF file) or compile them in a separate list. Note: if you opt to annotate the file with software other than Adobe Reader then please also highlight the appropriate place in the PDF file. To ensure fast publication of your paper please return your corrections within 48 hours. For correction or revision of any artwork, please consult http://www.elsevier.com/artworkinstructions. Any queries or remarks that have arisen during the processing of your manuscript are listed below and highlighted by flags in the proof. Click on the ‘Q’ link to go to the location in the proof. Location in article

Q1

Query / Remark: click on the Q link to go Please insert your reply or correction at the corresponding line in the proof

Please confirm that given names and surnames have been identified correctly.

Please check this box if you have no corrections to make to the PDF file

Thank you for your assistance.

INFSOF 5221

No. of Pages 18, Model 5G

25 May 2012 Information and Software Technology xxx (2012) xxx–xxx 1

Contents lists available at SciVerse ScienceDirect

Information and Software Technology journal homepage: www.elsevier.com/locate/infsof

2

A Process Framework for Global Software Engineering Teams

3 Q1

Ita Richardson a, Valentine Casey b, Fergal McCaffery b, John Burton c, Sarah Beecham a,⇑

4 5 6

8 7 1 3 0 2 11 12 13 14 15 16 17 18 19 20 21 22

a

Lero, The Irish Software Engineering Research Centre, University of Limerick, Ireland Department of Computing and Mathematics, Dundalk Institute of Technology, Dundalk, Ireland c Vitalograph Ireland Ltd., Gort Rd Business Park, Ennis, Co., Clare, Ireland b

a r t i c l e

i n f o

Article history: Received 2 November 2011 Received in revised form 6 May 2012 Accepted 9 May 2012 Available online xxxx Keywords: Global Software Engineering Global Teams Global Teaming Process Area Project Management Software Process

a b s t r a c t Context: Global Software Engineering (GSE) continues to experience substantial growth and is fundamentally different to collocated development. As a result, software managers have a pressing need for support in how to successfully manage teams in a global environment. Unfortunately, de facto process frameworks such as the Capability Maturity Model Integration (CMMIÒ) do not explicitly cater for the complex and changing needs of global software management. Objective: To develop a Global Teaming (GT) process area to address specific problems relating to temporal, cultural, geographic and linguistic distance which will meet the complex and changing needs of global software management. Method: We carried out three in-depth case studies of GSE within industry from 1999 to 2007. To supplement these studies we conducted three literature reviews. This allowed us to identify factors which are important to GSE. Based on a gap analysis between these GSE factors and the CMMIÒ, we developed the GT process area. Finally, the literature and our empirical data were used to identify threats to software projects if these processes are not implemented. Results: Our new GT process area brings together practices drawn from the GSE literature and our previous empirical work, including many socio-technical factors important to global software development. The GT process area presented in this paper encompasses recommended practices that can be used independently or with existing models. We found that if managers are not proactive in implementing new GT practices they are putting their projects under threat of failure. We therefore include a list of threats that if ignored could have an adverse effect on an organization’s competitive advantage, employee satisfaction, timescales, and software quality. Conclusion: The GT process area and associated threats presented in this paper provides both a guide and motivation for software managers to better understand how to manage technical talent across the globe. Ó 2012 Published by Elsevier B.V.

24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

48 49

1. Introduction

50

In today’s global economy, increasing numbers of software engineers are expected to operate in a distributed environment [1]. In this environment, geographical distance introduces physical separation between team members and management [2], temporal distance hinders and limits opportunities for direct contact and cooperation [3], and cultural distance negatively impacts on the level of understanding and appreciation of the activities and efforts of remote colleagues and teams [4,5]. The lack of a common native language, or linguistic distance, creates further barriers to communication [1,6,7]. These distances culminate in global distance, which is commonly experienced in Global Software

51 52 53 54 55 56 57 58 59 60

Engineering (GSE)1 environments. This results in GSE having complexities over and above those experienced in local, collocated, software development [1,8–10]. Our previous research recognized the importance of explicitly defined processes for GSE [11], and we argue that, given the substantial growth and associated complexities of GSE, it is important that process models are developed to support GSE. Therefore, we have developed a specific process area, Global Teaming (GT). GT establishes goals and sub-practices specific to GSE, thus presenting a process view of Global Software Engineering for use by project managers. Taking the basic structure of the Capability Maturity Model Integration (CMMIÒ) [12], we augment it with new factors found to be important in setting up global software development teams [8–10,13,14]. The Global Teaming process area aims to support GSE implementation.

⇑ Corresponding author. E-mail addresses: [email protected] (I. Richardson), [email protected] (V. Casey), [email protected] (F. McCaffery), [email protected] (J. Burton), [email protected] (S. Beecham).

1 A variety of terms exist: Distributed Software Development (DSD), Global Software Development (GSD), or Global Software Engineering (GSE). We will use the term GSE in this paper.

0950-5849/$ - see front matter Ó 2012 Published by Elsevier B.V. http://dx.doi.org/10.1016/j.infsof.2012.05.002

Please cite this article in press as: I. Richardson et al., A Process Framework for Global Software Engineering Teams, Inform. Softw. Technol. (2012), http:// dx.doi.org/10.1016/j.infsof.2012.05.002

61 62 63 64 65 66 67 68 69 70 71 72 73 74

INFSOF 5221


25 May 2012 2

I. Richardson et al. / Information and Software Technology xxx (2012) xxx–xxx

CMMI Specific Goals (SGs), Specific Practices (SPs) and Sub-practices

Guidelines

Gap Analysis (section 5)

GSE practices

GSE Factors Derived from Literature and Case studies (section 3)

Merged processes

Unique GSE Processes

CMMI Components

GSE threats

GSE Goals, practices and recommendations

CMMI Structure

SGs, SPs and sub-practices

rationale Global Teaming Model (section 6)

Threats to project if GSE recommendations ignored (section 4)

Fig. 1. Methodology used to develop the Global Teaming Model and related Threats.

108

When carrying out our study, we also identified threats to the software project if GT processes are not implemented. We view threats broadly in terms of known and unforeseen factors that are likely to lead to project failure. In the same way as Bannerman [15], we portray threats in a broader context of vulnerability than is currently associated with risk management. Threats can be viewed as factors that prevent an organization from capitalising on the opportunities offered by successful GSE. Risk is closely associated to threat, as risk is basically the cost (or impact) of a threat and the probability of this threat happening [16]. We extend our previous work [17] by highlighting threats to successful GSD if organizations ignore the need to adapt their current processes to fit their new circumstances. The GT model detailed in this paper builds on Richardson et al. [17] to present a holistic view of the problems, solutions and threats to GSE. The underlying premise of the original GT model provided a springboard for our other related work such as barriers and solutions to GSD (which we worked on in parallel to this publication) [18], and has been adapted to reflect GSE practices specific to architectural knowledge management [19]. The previous presentation of the model was in the form of written lists or practices. In this study we explain how the practices were developed, and pull all practices together in one graphical model that should be easier to follow. We are also in the process of developing a decision support system based on practices detailed in the GT Model [20] . This paper is organized as follows. In Section 2 we provide a brief background to Global Software Engineering (GSE), Global Teams and process support. In Section 3 we report how we collected data on GSE factors through empirical studies and literature reviews; Potential threats faced if the GT processes are not implemented in practice are covered in Section 4. Section 5 presents our gap analysis that underpins the development of the Global Teaming (GT) Process area presented in Section 6. Section 7 concludes the paper. Fig. 1 shows the relationship between Sections 3–6.

109

2. Global Software Engineering

110

The growth of GSE in recent years means that many software engineers are required to collaborate over geographical, temporal,

75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107

111

cultural and linguistic distance, collectively termed ‘global distance’ [1,2,7,21,22]. The tremendous take-up of GSE has gone hand-in-hand with technical communication advances such as the Internet, increased use of e-mail and instant messaging, and inexpensive international telecommunication [23]. In addition, the availability of highly skilled software engineers in low cost locations such as Eastern Europe, Latin America and the Far East [24], coupled with the desire to cut costs and take advantage of establishing operations close to emerging markets, have all contributed to more and more organizations selecting this strategy. In some cases, application development and maintenance have been outsourced to remote third party organizations. In others, organizations have set up subsidiaries in low cost economies and off-shored part or all of their software development to these locations [6,25].

112

2.1. Global Teams

127

The global team is described as the core building block of the global organization [26–28]. A traditional team is defined as a social group of individuals who are collocated and interdependent in their tasks. The group undertakes and coordinates their activities to achieve common goals and share responsibility for outcomes [29]. Global teams have the same goals and objectives as traditional teams and interact through interdependent tasks, but operate across time, geographical location and organizational boundaries linked by communication technologies [30]. They often operate in a multicultural and multilingual environment which may cross organizational boundaries [31]. Communication between global team members is normally electronic and asynchronous with limited opportunities for synchronous contact [30]. The team may function on a permanent or temporary basis contingent on the demands of the business environment in which it is operating. The team’s overall objective is to function as a single team, with the same goals as if they were collocated. The implementation of a global team strategy can simply be a cost-based decision. For example costs can be reduced by combining the technical skills and experience of staff located in a highcost centre with engineers in a low-cost location. If the goal is a

128


113 114 115 116 117 118 119 120 121 122 123 124 125 126

129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148

INFSOF 5221


25 May 2012 3

I. Richardson et al. / Information and Software Technology xxx (2012) xxx–xxx Table 1 Studies used to investigate important factors in GSE. Characteristics

Study 1

Study 2

Study 3

Type of Organization

Small to Medium Sized Enterprise (SME) based in Ireland Financial and Telecommunication SW Local (offsite) Ireland (Dublin)

US Multinational and SME based in Ireland. Bespoke financial software Offshore/near-shore USA development and maintenance

Ireland (150 miles from Dublin)

Ireland

Leverage staff at both locations; capitalize on cost advantage offered

Leverage domain expertise of US staff with technical and cost advantage of Irish staff

Irish division of US Multinational operating in Ireland >20 years Software testing Offshore US Ireland Ireland Malaysia Leverage technical ability of Irish staff with competitive salary levels of Malaysian test engineers

Application area Global Team Distance Outsourcing from Outsourcing destination Reason for GSE

169

short-term strategy, then GSE may be used simply as a knowledge transfer exercise. If, on the other hand, making use of GSE benefits is a long-term objective, sustained support will be required for team members at all locations. The reason for choosing a particular country to offshore to can also be based on their local knowledge or proximity to the customer base [32]. ‘‘Globally distributed projects involve two or more teams working together from different geographical locations to accomplish common project goals’’ [33]. While the term ‘distributed team’ simply states the geographical location of the team members in the same organization, the important difference between a ‘global team’ and a ‘distributed team’ depends on the interdependence of tasks. All teams working across geographic boundaries are considered ‘distributed’. However, it is possible to have a team which is geographically distributed, but where the work has been partitioned in such a manner that there is no interdependence of tasks between team members. In these circumstances this team is distributed, but not global [34]. In this study, we are proposing a global teaming process for ‘global teams’ where there is clear interdependence of tasks between team members at all locations.

170

2.2. Process support in GSE

171

The idea of increasing productivity and quality through improved individual processes originated in manufacturing and the work of Shewhart [35] in the 1930s. Shewhart’s continuous view of process improvement was later adopted by Deming who applied his ‘‘Plan Do Check Act’’ cycle and statistical controls in both Japan and the USA in the 1980s [36]. Humphrey [37] adapted these ideas to software development and defines software process as ‘‘the set of tools, methods and practices we use to produce a software product’’. Paulk et al. [38] expand this definition to ‘‘a set of activities, methods, practices and transformations that people use to develop and maintain software and the associated products’’. Organizations improve their software processes to improve the quality of their product. While some argue that implementing planned processes decrease the efficiency of the software development process [39–41] there is counter evidence that implementing planned processes can increase productivity and efficiency [42–46]. Although there are valid reasons for not implementing planned process models, we argue that there are efficiencies to be gained in doing so, and, in particular, there are markets which require planned processes to be in place. For example, a recommended practice in Rottman and Lacity [47] is that when off-shoring work, the GSE organization should become CMMIÒ certified as ‘‘the best way to extract value from the supplier’s CMM/CMMI processes’’. Furthermore, domains such as the medical device industry must comply with the guidelines and standards of the medical device regulatory bodies (e.g. Food and

149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168

172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196

Drugs Administration in USA) and require evidence that defined processes have been adopted. While the CMMIÒ for Development (CMMI-DEV) [12] process model can operate successfully in local environments, it does not explicitly address the impact of GSE factors [48], especially relating to the socio-technical complexities [1,9,10]. This is supported by Prikladnicki et al. [49] who state that many GSE studies mention the need for Distributed Software Development (DSD) process models with specific DSD practices. The work of Ramasubbu et al. [50] also established that key processes for GSE are not specifically addressed in existing process models. Although there is an increasing trend towards adapting and customising the CMMIÒ to different domains [51], there is a lack of guidance as to how to conduct such specializations in a systematic way [51]. We therefore need to explore whether the CMMIÒ structure would support the specialization of processes important to GSD. These findings lead us to ask two linked research questions:

197

Research Question 1: ‘‘What are the threats faced by global software project teams if they do not implement GSE processes correctly?’’ and Research Question 2: ‘‘Can our Global Teaming research be integrated in the CMMIÒ model?’’

215

These questions build directly on our previous work. In 1999, we were asked by industry to help identify why their GSE teams were not working as effectively and efficiently as they expected. In our initial interviews with those managing GSE teams (see Table 1), we established that GSE was being mainly implemented due to cost-cutting requirements, and that such implementations were unsatisfactory from a software engineering perspective [52,53]. As a result of this initial investigation, we commenced three longitudinal studies which combined industrial empirical studies with literature reviews. The results of these studies have been widely published over the years, e.g. [5,9,54,55]. However, in this paper we bring all the findings together as one integrated model of Global Teaming practices to meet the growing needs of development teams operating in a global environment. Although an initial version of Global Teaming was published in [17], the version presented in this paper has been re-structured and improved based on feedback from industry and further analysis of the literature. Also, the threats identified in Section 4 provide a new dimension to our study.

220

3. Identification of GSE Factors

240

This section presents our empirical studies and literature reviews that established factors which should be taken into account when implementing GSE.

241


198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214

216 217 218 219

221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239

242 243

INFSOF 5221


25 May 2012 4


244

3.1. Empirical studies

245

We conducted three contrasting empirical studies from 1999 to 2007 (summarized in Table 1). The first case involved local global teams, i.e. geographically distributed within the same country and organization [54]. In the second study, the organization employed offshore/near-shore2 global teams (involving geographical and temporal distance across continents) [56,57]. The third study examined off-shore global teams (involving geographical, linguistic, cultural and temporal distance where global team work for the same organization) [48,54,55]. We used an action research approach [58] and a grounded theory approach [59] for data gathering and data analysis. Action research was carried out through the direct intervention of a researcher who in this case was operating as part of the team in a management position. These structured approaches allowed us to leverage research opportunities and maintain a level of objectivity, resulting in the identification of factors and threats for GSE. The team involved in this research is composed of people with prior relevant industrial experience including one certified CMM assessor. All authors have been involved in GSE research for many years. A key outcome from our three independent empirical studies was the commonality of our findings. These were reinforced by the use of an inductive research methodology where efforts were taken to ensure our previous findings did not influence our subsequent studies. When common factors were identified these were extensively explored for alternative explanations and to gain a greater insight into the problems encountered. In this way our GSE factors were identified and analysed. (Section 3.3 explains these factors in detail).

246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272

management, communication, cooperation, motivation, culture, fear, team work, management and organizational theory. The third independent study took place over a 5 year period from 2002 to 2007. A further literature review was undertaken, building on the previous two literature reviews. These were consolidated and extensively expanded with 1500 additional publications identified and evaluated. Of these 300 were considered of particular relevance. This literature allowed the identification and augmentation of specific themes and they were then sorted in chronological order. To identify these publications extensive use was made of manual and online database systems. These included the IEEEXplore digital library, the ACM digital library, Science Direct, Springer online, CiteSeer, Emerald and Wiley Interscience. The keywords outlined in the first and second studies were re-evaluated and expanded and these were utilized to search these systems. Numerous conferences and workshop proceedings were also reviewed. As well as those already mentioned, these included the IEEE International Conference on Global Software Engineering, the International Workshop on Global Software Development, the European Software Process Improvement Conference and the International Workshop on Distributed Software Development. What emerged from this analysis was a comprehensive and relevant literature review which was used extensively to support the third case study. Our literature review identified many GSE related factors, which helped to identify practices included in our GT Model. However, while many of the practices in the GT Model will remain relevant and useful to organizations engaged in GSE over time, as GSE is a growth area, and the corresponding published research is also expanding, it could be that some of our recommendations will change in the future.

303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333

273

3.2. GSE Literature Review

3.3. GSE Factors Identified

334

274

An extensive literature review was undertaken for each of the three independent studies. The first study was undertaken in 1999 and extensive use was made of the University of Limerick’s library and catalogue. The initial focus was on identifying books, journals and conference proceedings which dealt with the topics of managing software projects, information systems development, distributed software development, global software development, global software teams and computer supported cooperative work. These topics were also utilized as keywords to search manual and online database systems such as the IEEEXplore digital library and the ACM digital library. When relevant publications were identified they were reviewed and sorted into themes and chronological order. In this way key themes and their development were identified. The analysis of the literature also allowed potential gaps in research to be recognized and explored. The references in each publication were also used as a source of discovering additional material. Relevant journals identified included Communications of the ACM, IEEE Software, the Information Systems Journal, and IEEE Transactions on Engineering Management. Relevant conferences which emerged included the Hawaii International Conference on System Sciences, the International Conference on Information Systems, and the European Conference on Computer Supported Cooperative Work, and the International Conference on Software Engineering. The second independent study took place in 2001 and a similar structured approach was implemented. The literature review from the first study was extended and updated to meet the specific requirements of this study. In particular, the search topics and keywords were extended to include specific aspects of project

Findings from our empirical case study research and literature reviews led to the identification of several GSE factors. In this section we list some of these key factors. Effective software project management in a single location is a complex endeavour [60]. There is the need to be an arbitrator between diverse stakeholders with different expectations and agendas, to manage the operation of the team effectively within the constraints of available resources, both financial and technological, and to manage the available personnel and technical capabilities. Therefore, successful software project management is a difficult undertaking which can only be achieved through the effective planning, organizing, staffing, leading, controlling, coordinating and day-to-day management of the project. Software project management becomes even more complex in a globally distributed environment [61,62]. In addition to the effective organization and management of collocated teams and projects, there are additional factors which emanate directly from the operation of geographically distributed global teams and their related projects. As stated by Paré and Dubé, ‘‘The complex, usually uncertain, and highly interdependent nature of project tasks, together with geographical, temporal, structural and cultural gaps fundamental to distributed teams, make management of virtual projects a relatively complex undertaking’’ [62]. As shown in Fig. 2, global distance, which includes geographical, temporal, cultural and linguistic distance, introduces barriers and complexity into the GSE team environment. Effective coordination, visibility, communication and cooperation between locations are essential in a GSE team [2,63], but these are negatively impacted by global distance. Improving coordination, visibility, communication and cooperation can help to reduce the barriers and complexities. Such improvements must be accomplished under the financial and technical constraints of the project and with team

335

275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302

2

The US and Irish based sites are considered linguistically and culturally close or ‘near-shore’ [56,57].


336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366

INFSOF 5221


25 May 2012 5


Fig. 2. Global Software Engineering Team Environment [55].

367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407

members from geographically dispersed groups. Ultimately, this is not an easy task, and our research has demonstrated that many other factors come into play during the implementation of global projects [9,48,54,55,57,64]. The full list of 25 factors identified in our case studies and literature reviews are listed in Table 2. We expand on some of these factors in this section, and provide full descriptions of all 25 factors in the Appendix. While some of the non-technical factors noted in Table 2 have been recognized previously (e.g. communication, risk management), additional social factors, such as fear and its negative impact on trust emerged from our research [9,54], and are now more widely recognized as important to GSE [53]. Project Management challenges include promoting socializing processes to support globally distributed collaboration [33]. Research by Smite and Borzovs [65,66] shows that, in practice, the variety of collaboration models can be substantial – they identified 19 different models looking only at four life-cycle processes. For example, development may be undertaken in one country’s group, with systems analysis, design and testing undertaken in another country. Alternatively some processes may be ‘shared’ – for example design and coding could be performed at both locations. Therefore, in practice, organizations are shown to distribute responsibilities across remote sites. Smite and Borzovs [66] define these as either ‘joint collaboration’, requiring investments in team building, or ‘independent collaboration’, requiring investments in knowledge management and transfer. Each model requires a level of socialization to succeed, and recommendations include face-toface meetings to enable teams to share norms, attitudes and behaviours [33]. GSE is not without its inherent business related risks [61,67]. This has particular relevance when organizational boundaries are crossed. For example, aspects of a software application may provide competitive advantage to the organization that is having it developed [61]. In this case, they may not wish to grant an outside organization access to such information, even when temporarily partnered with them. To prevent this, a global team strategy can be employed to allow the partitioning of development across sites. The activities that need to remain confidential are undertaken by the organization’s own global team members, whereas related activities are undertaken by external remote team colleagues. There are many effective ways to partition tasks, where

most would fit into three main classes: modularization, phasebased and integrated. Component based distribution of tasks offers flexibility in terms of task ownership, inter-site communication, collaboration and knowledge sharing [68]. An important outcome to emerge from our studies was the compounding impact of the GSE factors listed in Table 2. For example, fear emerged as a serious problem in each of the studies. In case study one, the direct impact of fear was a breakdown in communication, cooperation, knowledge transfer, motivation and trust. In addition, each of these factors compounded each other. The lack of communication was a barrier to the development of cooperation and therefore inhibited knowledge transfer. This had a negative impact on the motivation of the offsite team members and resulted in the lack of trust between locations, fostering the development of a ‘‘them and us culture’’ and adding to the level of fear, which further hindered communication and cooperation. The ultimate outcome was the total failure of the project and the dropping of the offsite strategy. In case study two, as a result of their fear of losing jobs, email was used as a weapon by local team members to attack their remote colleagues. Any problems that were caused by the remote team members were highlighted to senior management. Once this practice had been established the remote team members reciprocated in a similar manner. Cultural differences came to the fore and team relationships and trust broke down. Rather than cooperating, team members actively sought to undermine and obstruct each other. This further inhibited communication and cooperation. It also polarized cultural differences which added to the level of fear and mistrust experienced by team members in both locations. This outcome was all the more surprising given that the team members had successfully worked together when they were collocated in the US for over a year. In the third case study, many negative issues associated with GSE came into play. Fear inhibited communication between the off shoring location and the remote site. Extensive communication tools were provided, but they were not utilized and contact was limited to email. Cultural differences were misunderstood and helped to reinforce mistrust and fear. Remote colleagues were slow to communicate, using distance strategically to minimize information flow, which further hindered the development of cooperation. Very little knowledge transfer took place. Limited face-to-face contact led to cultural misunderstandings also resulting in additional fear and mistrust. The result was that the projects failed. While fear was an important factor to emerge from our studies; it is only one of the 25 GSE factors identified. We observed in case study two, that once these factors were recognized, they can be successfully addressed. For example, fear was tackled along with the additional contributing factors through the provision of team building, communication and cultural training, which resulted in a successful project. It is also important to highlight the compounding impact of the GSE factors we identified were experienced at different levels within the organizations researched. In each case study senior management had unrealistic expectations of what could be achieved, as the true cost of implementing their respective GSE strategies were not determined or the implications understood. This resulted in unrealistic expectations, which placed undue pressure on the project

Table 2 Global Software Engineering Factors. Communication

Skills Management

Language

Tools

Fear

Communication Tools Temporal Issues Effective Partitioning Project Management

Knowledge Transfer Define Roles and Responsibilities Team Selection Risk Management

Motivation Technical Support Coordination Cooperation

Culture Teamness Visibility Information Management

Trust True Cost Reporting Requirement Process Management


408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464

INFSOF 5221


25 May 2012 6 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513


managers to deliver unachievable financial and productivity results. This pressure was passed down to team leaders and team members. This was exemplified in the third case study where the remote team members due to their cultural background agreed to undertake large amounts of additional work. This resulted initially in remote team members working extensive levels of unpaid overtime. When that level of work was no longer sustainable they left the organization. It was only after a prolonged period of time, when the sustained high attrition rate was investigated that this emerged as a key reason for the extent of the problem. Given their cultural background, the overworked remote team members would rather leave the company then communicate their inability to meet unrealistic expectations. The loss of these experienced engineers had a direct negative impact on productivity, knowledge transfer and the motivation of the team members at the remote location. As a result projects which were already behind were hindered further and revised deadlines were missed and further cost overruns incurred. Each of the 25 GSE factors identified had a negative and compounding impact on the projects researched. Without the ability to effectively communicate and the correct use of tools to facilitate it, teams could not be successfully established, limited knowledge transfer took place and without corrective action projects could not be productively undertaken and managed. Temporal issues negatively impacted on communication, coordination, control and visibility. It also inhibited the development of relationships, trust, cooperation and teamness along with other factors. The lack of understanding of cultural difference compounded all of these factors and each factor had its own compounding impact. As case study 2 highlighted it was only when the negative GSE factors and their compounding impact were recognized and addressed that effective project management could be undertaken. In this case it resulted in a multimillion dollar project, which was failing being successfully turned around and delivered. As each of our studies showed, without effective technical support, team selection, clear definition of roles and responsibilities, skills management, process management, risk management, reporting and information management the success of GSE projects can be seriously impaired. Specific knowledge of each of these factors in the GSE setting is essential and their compounding impact needs to be understood and addressed. In summary, implementing GSE is not an easy task, and many software teams continue to experience difficulties when they are required to work as a global rather than a local team. Having identified a comprehensive list of relevant factors from both direct experience with industry and the literature we are in a position to develop the GT process area (in Section 6) but first we present a rationale for developing the GT process area through a discussion of the threats which exist if GSE is not implemented correctly (Section 4).

514

4. Establishing Potential Threats

515

This section on potential threats relates to risks associated with GSE and answers our first research question, ‘‘What are the threats faced by global software project teams if they do not implement GSE processes correctly?’’ This provides a rationale for the development of the GT model presented in Section 6. The threats identified draw on the analysis of our empirical work and the literature reviews (Section 3). While we cannot guarantee that implementing GT processes will reduce or eliminate the increased risks associated with GSE, we point out that if nothing is done to address problem areas (identified as such in the literature and in the empirical evidence), the project remains under threat of failure. It is important that

516 517 518 519 520 521 522 523 524 525 526

global project managers understand that ignoring GSE issues could threaten the success of GSE projects.

527

4.1. Identification of Threats

529

As illustrated in Fig. 1, potential threats were identified through an analysis of the literature and our empirical work [9,48,69], where we looked at the problems organizations were facing in GSE (e.g. [17]) prior to looking for solutions. The new practices in the Global Teaming model therefore grew from recognizing the problems that organizations face. By including the threats, organizations are in a better position to assess the associated risk and may be more motivated to implement the new practice.

530

4.2. Potential Threats

538

For consistency, we discuss potential threats to GSE under the headings that directly relate to the GT process area specific practices (presented in Section 6).

539

4.2.1. Threats to Successful Global Task Management In the software industry, a team structure should facilitate the successful management, coordination and operation of team members so that they produce the required software artefacts [61]. Managers need to consider the size of their global team as team size can directly impact the operation [70], as can the number of members situated at specific geographical locations. Team members may feel that if larger groups of developers are located in one or more remote geographical sites all the work may be centralized in these locations. This can threaten productivity due to feelings of alienation and fear for the future of their jobs, particularly for team members based at the location from which the work has been outsourced [71]. Additionally, management at one location may have responsibility for both their local and remote locations [71]. A structure shown to reduce this problem is the dual reporting to management where each location can report directly to a manager based at their site, who in turn can report to the remote manager [61]. This will reduce the threat that a manager may give undue priority to their own divisional or organizational needs rather than the requirements of the full global team and the specific project on which they are working [61]. Task allocation can vary widely. Research by Smite [65] shows that the variety of collaboration models can be substantial. Thus, GSE can lead to increased risks [61,67] especially when organizational boundaries are crossed. For example, some aspects of a software application if outsourced could compromise the organization’s competitive advantage [61], This is because the remote teams or organization that is outsourced to (the vendor) must be trusted with the intellectual property (IP) of the organization who owns the code. Knowledge sharing and code sharing requires that all parties understand and keep to their contractual agreements relating to IP, while maintaining the overall business objectives. To mitigate each of these threats, the subpractices ‘‘Determine team and organizational structure between locations’’ and ‘‘Determine the approach to task allocation between locations’’ have been included within Specific Practice 1.1, Global Task Management.

542

4.2.2. Threats to Successful Knowledge and Skills Management Cost advantages of GSE can be leveraged by integrating lower cost labour with higher cost communications. Employing a team or team members in another country allows access to a wider customer base and associated local knowledge. An example of this benefit is where the local team understands the fiscal policy within their home country. However, if the reason for undertaking GSE is

579


528

531 532 533 534 535 536 537

540 541

543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578

580 581 582 583 584 585

INFSOF 5221


25 May 2012 I. Richardson et al. / Information and Software Technology xxx (2012) xxx–xxx 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650

not fully realized then there is a threat that the potential competitive advantage will be lost. Socio-cultural factors can affect global teams and increase risks [72,73]. For example, some cultures do not promote individual responsibility and accountability and some cultures accept most suggestions without much discussion [61]. In these situations, individual team members are often required to communicate and work with people who they do not know and whose cultures they may not understand [74]. They are expected to use communication tools such as instant messaging, audio conferencing and video conferencing, many of which are synchronous. Teams may be required to work across time zones, where synchronous communication could impose on personal time. A common practice is for those at an outsourcing/offshoring location to schedule all conference calls to suit their local teams’ core times. We have seen that a poor understanding of the socio-cultural requirements of the sub-teams can result in misunderstandings, thus threatening the positive effect that GSE should have for the business [13,14]. Permanently inconveniencing remote staff will add to their level of dissatisfaction. This also increases the probability that overworked, trained and competent staff will seek positions elsewhere and leave the organization [8]. In the collocated setting the culture of the team can remain below everyday consciousness and only becomes obvious when contrasted with different cultural norms, values and assumptions in GSE teams. A further threat to GSE is that management may not recognize that, to succeed, there must be effective knowledge transfer and training provided for GSE teams [14]. A lack of domain specific knowledge and experience could undermine the developers despite having the appropriate academic background to undertake their respective roles and responsibilities. Furthermore, a lack of domain knowledge transfer can result in those who understand the domain becoming overwhelmed by requests from remote sites, and can cause a breakdown in communication. An example of the importance of recognising domain expertise is shown in a case study of coordination implications of software architecture in a global software development project carried out by Avritzer et al. [75]. In Avritzer et al.’s case study, Siemens found that there was a danger of central domain experts becoming overwhelmed by requests from remote sites. However, they overcame this communication bottleneck by structuring global software development projects to take advantage of domain expertise located in remote sites. By doing so, they created a more scalable environment, where making use of the specific expertise in remote sites relieved the central site experts who could then focus on the distribution of important tasks to remote sites. While often seen as a recovery strategy or a team initialization strategy, training practices successfully implemented in a collocated situation may not be successful in a global environment. The most effective method for the provision of global team training is onsite and face-to-face training [61,76]. This ensures that the training needs of the team members can be directly assessed and provision made to address individual requirements. Given these threats, we include the subpractices within Specific Practice 1.2, Knowledge and Skills Management: ‘‘Identify business competencies required by global team members in each location’’, ‘‘Identify the cultural requirements of each local sub-team’’, ‘‘Identify Communication Skills for GSE’’ and ‘‘Establish relevant criteria for Training’’. 4.2.3. Threats to Successful Global Project Management Global project managers are required to do the tasks of the local project manager, but must also plan, facilitate, implement and monitor global communication, coordination and related activities with effective policies and procedures. Project Managers will often be based remotely from their team members and may not have the

7

opportunity to see the contribution of each team member firsthand. The project manager may not have a good grasp of each member’s skills, knowledge and how they contribute to the project. The threat here is that competent people in the distributed location may agree to undertake unrealistic amounts of work [77]. This can be attributed to their respect for more senior people and their reluctance to say ‘no’ (for cultural reasons) to requests from a superior [2,78]. This can have serious implications for the individuals and ultimately the projects involved and is only sustainable in the short term given the level of effort required [43]. Effective partitioning and allocation of work across the GSE team must be addressed. This can be achieved by implementing one or more different approaches for task allocation [2]. Partitioning can be component based [68] or lifecycle based [65]. There is a threat that opportunities for making the best use of a global team could be lost if the most appropriate partitioning of tasks is not investigated, recognized, planned and implemented. Project managers must recognize and understand the cultural needs of the global software team. Culture may differ according to the following areas: organizational, geographical, national, religion, gender and power distance [79]. Attitudes can be further reinforced by religious belief and by the legal system. For example, some men may have problems reporting to women team leaders or managers, e.g. on religious grounds, a male project manager from the Far East would not work with a female project manager from Ireland [9]. Some organizations consider that their corporate socializing process is adequate to address the cultural issues which arise when managing a GSE team. However, where there are major differences between corporate and national cultural norms, this socialization is generally not sufficient [55]. A lack of respect for cultural differences can negatively impact communication and trust and will adversely affect the project. Teamwork is a cooperative activity and the project manager must establish an effective cooperation procedure within the global team to reduce threats to the project. Effective coordination ensures that adequate planning is carried out and the required resources are provided to undertake GSE [1,55]. Global distance negatively impacts the level of cooperation and coordination [1,6] between global team colleagues. The project manager needs to be aware of how the project is progressing. In the global team, there is rarely the opportunity for informal updates. In some cultures where often the objective is to avoid conflict at all costs, to disagree may be considered impolite [61]. Organizational hierarchy can take priority and may be adhered to strictly. In some Far Eastern cultures requests and instructions are accepted without question if they come from a senior figure [80]. Without implementing formal reporting structures, there is a risk that the remote team may not report correctly, due to cultural differences and misunderstandings. The related threat here is that global team members may accept tasks which they are poorly equipped to perform. However, implementing formal reporting structures can have some negative effects. For example, implementing rigid formal reporting structures can threaten the free flow of ideas and interactions between management and team members [48]. Risk management should be incorporated into all well planned software projects. Globally distributed global team projects carry additional exposure to risks which are associated with managing a culturally diverse global team [61]. Managing a global team has an additional risk if there is a lack of information among local team members concerning the culture of remote staff as identified by some Far Eastern cultures’ revering of hierarchy [2,61]. This manifests itself in a number of ways, often resulting in them not expressing a negative opinion and constantly agreeing to undertake additional work. Without an appropriate risk management strategy organizations may encounter problems with require-


651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716

INFSOF 5221


25 May 2012 8 717 718 719 720

721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761

762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779


ments, feature volatility, unrealistic schedules, budgetary overruns and personnel associated problems [14] as well as cultural misunderstandings [2,61]. A lack of risk awareness can threaten the success of the project as a whole [17]. 4.2.4. Threats to Successful Operating Procedures For successful GSE, an effective and defined conflict management strategy should be implemented [2,61]. Some types of conflict are open and easy to recognize. Trust is more difficult to establish due to lack of socialization [53]. Fear of jobs being outsourced to remote locations can create conflict. Conflict and a lack of trust can create a ‘them and us’ culture which can lead to uncooperative and obstructive behaviour [81]. Effective communication is key to the successful operation of global teams [2,61]. Good communication facilitates dissemination of relevant information. The communication process is hampered by global distance. Loss of face-to-face contact and the need to rely on asynchronous tools can negatively impact on communication levels [1]. This then impacts on the amount of information that is transmitted between global team members. Global teams require information about basic issues such as local time and public holidays, e.g. knowledge of a team member’s appearance, personality and preferences; whilst such details may be taken for granted in a collocated environment, they are not always clear when dealing with remote colleagues. Project managers should be aware that, if communication is made too difficult, there is a threat that important information relevant to other global team members may not be shared until it is too late to recover project difficulties. A lack of knowing when and how to communicate with team members can adversely impact the project schedule. Poor communication will lead to inefficiencies, de-motivated team members, conflict and blame [53]. A poor communication interface could delay projects on a day to day basis, e.g. members of teams may not know how and when they will receive inputs to, distribute outputs from and complete work products. Some employees may not be comfortable participating in meetings held via audio or video, particularly if they have not had the opportunity to meet their global colleagues face-to-face. Project managers may need to change how they conduct shared meetings. When hosting a meeting, many GSE companies circulate minutes to all attendees, articulating what was agreed at the meeting. Although this is an extra overhead, it pays to keep track of agreed work. Important contributions may be missed if team members do not have the confidence to voice concerns or ideas. If meetings are not minuted and circulated it may be impossible to track agreed actions. 4.2.5. Threats to Successful Collaboration between locations Poor collaboration between locations will threaten the project as global team members do not readily consider themselves to be part of a single global team. Therefore, effort should be made to ensure that the team work together, not only on the development of the software project, but also, as developers of the processes used within the team. Goals and objectives should be agreed and understood by all the team members, regardless of location. Team members can then focus on meeting these goals. Resulting successes should be measured by the team’s accomplishment [14]. To actively foster this approach, the global team must be seen as an entity in its own right and, regardless of the location, performance should be judged and rewarded accordingly. Success should never be measured by the achievements of members at one geographical location. There is a threat that a lack of shared goals and objectives may result in poor team motivation, poor productivity and a ‘them and us’ culture [82].

A reward in one culture may not be appropriate or may even insult someone from another culture. The idea that ‘money talks’ in every culture is too simplistic [83]. Cultures place different values on different types of rewards such as money, status and group achievement [84]. As well as cultural diversity, the economic situation and income tax laws at each location need to be considered when determining the form of reward provided. If inappropriate, an intended reward may be ineffective or give offence and alienate and de-motivate a team member [55]. Work product ownership boundaries can be defined through the effective partitioning and allocation of work across GSE teams. It is likely that different stages of product development will occur at different sites [66,68], e.g. requirements changes distributed to specific locations rather than to all sites may result in unsuccessful product interfacing [9]. Good software practice recognizes that process ownership and development are best placed with those who are closest to the process [85]. A collocated process from the parent site cannot be simply exported and implemented in the distributed site [86,87]. Although common process goals should be established across locations, the input of team members at all locations should be sought, encouraged, and valued. The process should address specific challenges associated with GSE. This will ensure relevant structures and procedures from all sites are taken into account to achieve agreed goals. A lack of input from distributed team members threatens the alienation of those team members whose needs are not met by the process and whose suggestions for improvement are ignored [2,48,61]. Effective coordination within a distributed software project requires planning and agreeing achievable milestones. In GSE, effective monitoring will help oversee ongoing progress with reference to costs, time, productivity, quality, and risk. Provision of contingencies to address potential risks should be considered and procedures established to coordinate their implementation when and if required. Effective use of synchronous and asynchronous communication tools is essential to GSE communication. Therefore, it is important that within the commitments made, team members explicitly include communication plans. If this does not happen, and work is not monitored, there is a threat that the work could adversely affect costs, schedule, productivity and quality. The inclusion of sub-practices ‘‘Identify common goals, objectives and rewards for the global team’’, ‘‘Collaboratively establish and maintain work product ownership boundaries’’, ‘‘Collaboratively establish and maintain interfaces and processes’’, and ‘‘Collaboratively develop, communicate and distribute work plans’’ will support the mitigation of threats due to a lack of collaboration between locations.

780

5. Development of Global Teaming Process Area

827

5.1. Gap Analysis: CMMIÒ GSE factors

828

To understand how GSE is supported within the CMMIÒ for Development process model Version 1.3 [12] we performed a gap analysis. In our analysis of all process areas, we matched the GSE factors identified in our previous research (Table 2), to the statements in the CMMIÒ model documentation. This is similar to the analysis carried out by Paulk [88,89], who mapped ‘‘sentence to sub-practice’’ when comparing ISO:9000 with CMM. Our gap analysis was carried out systematically. First, we identified synonyms for each GSE factor. Second, we searched the CMMIÒ model for each GSE factor and relevant synonyms to identify whether the factor was explicitly considered within either a process area or a process area component, e.g. specific practices and work products. Third, we established three GSE factor categories:

829


781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826

830 831 832 833 834 835 836 837 838 839 840 841

INFSOF 5221


25 May 2012 I. Richardson et al. / Information and Software Technology xxx (2012) xxx–xxx 842 843 844 845 846 847 848 849 850

(a) GSE factors for which there are explicit process areas in the CMMIÒ. (b) GSE factors for which there are implicit processes defined. (CMMIÒ recognizes that the factor is required for software engineering, but fails to specify the process in global or distributed terms). (c) GSE factors which are not mentioned in the CMMIÒ. (d) Finally, each of these three categories was catered for differently as described in the following sub-sections.

851 852 853 854 855 856 857 858 859 860 861

5.1.1. GSE factors explicitly identified in CMMIÒ When carrying out the gap analysis, we identified 3 GSE factors which are explicitly mentioned in the CMMIÒ (see Table 3). In examining all CMMIÒ Process Areas, Specific Goals, Specific practices and sub-practices we found no Process Area which took the complexity of the GSE factors into account. However, some will support these factors. For example, we identified that the Integrated Project Management Process Area is included in the CMMIÒ process model, and this clearly identifies relevant project management specific practices. However, specific GSE project

Table 3 Global Software Engineering Factors and Gap Analysis Results. GSE Factor Summary of results from gap analysis Category (a): Explicit in CMMI Process Management Explicit Process Areas: Organizational Process Definition, Organizational Process Focus, Organizational Performance Management, Organizational Process Performance Project Management Explicit Process Areas: Project Planning, Project Monitoring and Control, Integrated Project Management Risk Management Explicit Process Area: Risk Management Category (b): Implicit in CMMI Cooperation Establishment and maintenance of teams in Integrated Project Management, sub-practices contribute to cooperation: not specific to GSE Coordination In Integrated Project Management: not specific to GSE Define Roles and In Product Integration, Project Planning: not specific Responsibilities to GSE Effective Partitioning In Requirements Development, Technical Solution, Product Integration: not specific to GSE Reporting In Measurement and Analysis, Quantitative Project Requirement Management, Integrated Project Management: not specific to GSE Skills Management In Project Planning, Integrated Project Management: not specific to GSE Teamness Establishment and maintenance of teams in Integrated Project Management, sub-practices contribute to teamness: not specific to GSE Team Selection In Project Planning: not specific to GSE Tools Tools discussed in Integrated Project Management: not specific to GSE Visibility In Integrated Project Management, Project Monitoring and Control: not specific to GSE Category (c): Not included in CMMI Communication No discussion relating to GSE Communication Communication No discussion relating to GSE Communication Tools Tools Culture Organizational rather than GSE culture included in Organizational Performance Management Fear Keyword not found Information Keyword not found Management Knowledge Transfer Keyword not found Language No discussion relating to Language issues in GSE Motivation Keyword not found Technical Support Keyword not found Temporal Issues Keyword not found True Cost Cost relating to GSE not included Trust Keyword not found

9

management organizational issues are not dealt with in the CMMIÒ, but we have added them in Specific Practice 1.3 in the GT model: ‘‘Global Project Management’’. Within this practice, we only note practices that relate to Project Management in a global situation, such as allocating a ‘bridge’ person [90] to substitute for the project manager at the remote site. What we have included in the model are over and above the Integrated Project Management sub-practices aimed at collocated teams, already present in the CMMIÒ. Risk management is a further example of a GSE factor that is explicitly mentioned in the CMMIÒ. Within the CMMIÒ model documentation, risk management is mentioned many times, to ensure that the user is directed to the Risk Management process area whenever there is a risk associated with a given process. The drawback we identified is that there is no mention of the specific risks associated with carrying out GSE. In fact, in the CMMIÒ’s list of ’’typical internal and external risk sources’’, the global environment, or any similar phrase, is not included. For this reason, we added the Identification of a Risk Management strategy as a practice within Specific Practice 1.3: Global Project Management.

862

5.1.2. GSE factors implicitly identified in CMMIÒ The second category comprises practices mentioned in the CMMIÒ that, according to our gap analysis, do not adequately address specific GSE factors. As seen in Table 3, we identified 10 such GSE factors. This observation led us to include a more detailed and tailored version of the given practice in the Global Teaming Model. An example of a specific practice in the CMMIÒ that lacks a GSE context is skills management (synonyms: competency management, knowledge management). According to the CMMIÒ, skills management must be effective for efficient software development. However, the CMMIÒ guideline does not recognize that project managers may be located remotely from their team members and they may not recognize these remote employees’ skills. In our model, this is dealt with under Specific Practice 1.2 Knowledge and Skills Management, where, for example, there is a sub-practice: ‘‘Identify business competencies required by team members at each location’’.

882

5.1.3. GSE factors not included in CMMIÒ The third category of 12 GSE factors we identified (see Table 3) are those not mentioned in the CMMIÒ. For example, there is no mention of temporal issues (synonyms: time zones, time difference) in the CMMIÒ model, and this resulted in our explicitly identifying software development across global distance, where, for example, in Specific Practice 2.1: Operating procedures, we note the need to ‘‘Implement strategy for conducting meetings between locations’’.

899

6. Global Teaming Model Structure

908

Having completed the literature review, case studies, threat analysis and gap analysis, we were in a position to develop the GT model. As shown in Fig. 1, we developed the GT model to reflect the current CMMIÒ structure to include Specific Goals, Specific Practices and Sub-practices. We adapt and customize this structure as the CMMIÒ is internationally recognized and used extensively by industry in their Software Process Improvement activities. Given that there is little guidance as to how to specialize the CMMIÒ to specific domains, we answer our RQ1 ‘‘Can our Global Teaming research be integrated in the CMMIÒ model?’’ by actually fitting the GT practices to the structure (shown in this section), and then validating the model (Section 6.1). The GT Model presents practices not currently found in the CMMIÒ by either adding new practices, or augmenting existing practices (see Fig. 1). Although based on

909


863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881

883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898

900 901 902 903 904 905 906 907

910 911 912 913 914 915 916 917 918 919 920 921 922

INFSOF 5221


25 May 2012 10


Fig. 3. Global Teaming Process Area showing Goals, Specific Practices and Sub-Practices.

949

the CMMIÒ, the Global Teaming process area has been developed as a stand-alone set of guidelines that can be used in isolation, with the CMMIÒ, or with other process models. We present the thesis that software project teams involved in GSE need to be cognizant of the Specific Goals, Specific Practices and the Sub-practices for GSE that we shown in Fig. 3 and in Tables 4 and 5. The GT process area should be used as a supplement to the organization’s current process, whether this is CMMIÒ or another process model, where GSE is being implemented within project teams. As we have demonstrated, the CMMIÒ as it stands is not sufficient as a process model for GSE. Therefore, it is necessary to develop a process model which supplements the CMMIÒ to fit the global environment. Fig. 3 illustrates that the Global Teaming process area has two Specific Goals (SGs): ‘‘Define Global Project Management’’ and ‘‘Define Management Between Locations’’. Each SG has Specific Practices (SPs) and sub-practices. SG1 represents practices required at project initiation (all specific practices are listed in Table 4); whereas SG2 classifies practices required when the project is operational (all specific practices are listed in Table 5). SG1 recognizes that global project management, while including tasks that would be expected within collocated project management, must also encompass extra tasks that exist because of the global software engineering team. SG2 focuses on global project management between locations. This is done through two specific practices. The first ensures that operating procedures are set up correctly. The second focuses on collaboration between locations.

950

6.1. GT Model Validation

951

In order to answer our second research question, ‘‘Can our Global Teaming research be integrated in the CMMIÒ model’’ we presented

923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948

952

the GT model practices as listed in Tables 4 and 5, to groups of experts to gain some informal feedback on the model. This informal evaluation took place in two organizations that develop software in a globally distributed environment. Ten senior managers and project managers were given a presentation and paper copy of the model. The experts voiced support for each of the listed practices, and some reflected that they would have benefitted from knowing about these practices prior to moving from a collocated development to a global development process. The experts found the guidelines immediately accessible and easy to follow. They were quickly able to identify areas they needed to consider in their next projects, such as Specific Goal 2, Operating Procedures; 2.2.1: Define how conflicts and differences of opinion between locations are addressed and resolved: recommendation: ‘‘Set up a strategy to handle, monitor and anticipate where conflict between remote locations may occur. The strategy should include how conflict will be resolved and how a person responsible for that resolution is selected’’. In order to gain more formal feedback as to how the model could be improved we are currently conducting an in depth validation of the GT processes based on a Decision Support System (DSS) we are developing. In ICGSE 2010 we piloted a subset of the model’s recommendations with experts in the field. While the response was mixed (especially as we did not pilot all the processes), the general feeling was that the GT Model filled a very important gap. Current work is continuing in developing an automated version of the GT Model, with a complete set of recommendations to support project managers in their GSD decisions [20]. Our future evaluation plans include implementing the model in an organization at the start of a GSE project and monitoring the project’s progress to the end of the project. This evaluation will help to ensure that key practice areas in the GT Model do indeed


953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984

INFSOF 5221


25 May 2012 I. Richardson et al. / Information and Software Technology xxx (2012) xxx–xxx

11

Table 4 Guidelines for Specific Goal 1 Define Global Project Management. SPECIFIC GOAL 1 SG1: Define Global Project Management SP1.1: Global Task Management Goal: distribute tasks so that GSE advantages are leveraged and negative factors inherent to its operation are minimized 1 ‘‘Determine team and organizational structure between locations’’ Create roles, relationships and rules to facilitate coordination and control over geographical, temporal and cultural distance Structure global team and monitor operation to minimize fear and alienation in teams Be aware of problems with unbalanced team sizes; e.g. smaller teams may be threatened and fear job loss Team structure should cater for possibility of dual reporting to management at more than one location, e.g. team structure could be cross divisional or multiorganizational and management remote Ensure that supervision, support and information needs of all team members are met regardless of location Organizational structure should be documented and available to all team to allow a clear understanding of everyone’s roles and responsibilities within the project 2 ‘‘Determine the approach to task allocation between locations’’ Identify and document reason for working with global team Base task allocation on the organizational requirement, e.g. if proximity to market is reason development team is located in a particular country, then customerrelated tasks should be allocated to that team Retain tasks that require frequent communication between groups within collocated teams Where GSE teams are subdivided into work modules (e.g. different parts of the life-cycle), management must allocate tasks based on core competencies of each sub-team, and clearly define which stages are carried out at which location Confidential software development activities that provide competitive advantage should be developed within organization Related non-confidential development activities can be undertaken by external remote team colleagues SP 1.2 Knowledge and Skills Management Goal: Identify business competencies and skills of team so that the advantages of GSE are leveraged and the negative factors which are inherent to its operation are minimized 1 ‘‘Identify business competencies required by global team members in each location’’ Document and define customer base and functions relative to the application being developed Provide training to ensure that global team has required understanding of the customer base and the business functions to take full advantage of the proximity of the team to the customer base 2

‘‘Identify the cultural requirements of each local sub-team’’ Cultural diversity: Each team member should be trained to understand the culture of the global team. Face-to-face meetings are recommended when and where possible, ideally at the start of the project and/or when a new member joins. Having individuals visit locations for extended periods can also be a successful strategy and should be fully leveraged at every possible opportunity

3

‘‘Identify Communication Skills for GSE’’ In order to develop the right practice, a new communication protocol needs to be set up. Policies should be put in place to support these new requirements to the satisfaction of all global team members. For example in synchronous communication, ensure that link up times are shared between core team working hours in each location

4

‘‘Establish relevant criteria for training teams’’ Effective knowledge transfer: Carry out evaluation of training needs to include cultural and linguistic issues. Undertake training onsite and face-to-face so team members can be directly assessed and training provision tailored to their specific requirements

SP 1.3 Global Project Management Goal: To plan, facilitate, implement and monitor global communication and coordination of related activities with effective policies and procedures 1 ‘‘Identify GSE project management tasks’’ Define ability and potential productivity of team: Global project manager should allocate tasks and timescales that are realistic. Where possible, the project manager should be actively involved in the recruitment and selection of team members. Failing this, they should gather all information relating to the technical and professional experience of potential and existing team members. When teams are in place and project details reported project managers should understand and document how individuals contribute to that project along with their skills and knowledge 2

‘‘Assign tasks to appropriate team members’’ Assign according to one or more of three different approaches; Modularization; Phase-based approach; and Integrated approach Modularization: partition work into modules which have a well defined functional whole Phase-based approach: Use when phases of the development cycle are relatively independent. Ensure that the team members developing a specific phase have a good understanding of what is required at each specific stage Integrated approach: Set up a protocol to allow handover from one geographic location to another to ensure a successful follow the sun development

3

‘‘Ensure Awareness of cultural profiles’’ National cultural differences should be identified and communicated to the management and team members. Cultural training can be communicated in following way Provide training to give all team members an opportunity to learn and understand about each other’s culture Address national, religious and relevant ethnic issues, all team members should understand acceptable and unacceptable forms of behaviour Training should be tailored to team member’s specific needs and location Project managers should ensure that cultural profiles for teams are established. E.g. Management and staff should show respect for gender-related cultural values of all colleagues. All employees’ legal rights must be upheld

4

‘‘Establish cooperation and coordination procedures between locations’’ Ensure that a suitable infrastructure, process and management procedures are in place to help establish cooperation and coordination between locations. Achievable milestones should be planned and agreed. Projects should be monitored with reference to costs, time, productivity, quality and risk

5

‘‘Establish reporting procedures between locations’’ Regular formal reporting will help the project manager to remain aware of how project is progressing. Procedure should include and encourage team members to report whether or not they can take on that task in the given time and report any problems before it is too late

6

‘‘Establish a Risk Management Strategy’’ All potential risks should be identified and addressed to include: risks in misunderstanding cultural differences, misunderstanding requirements, feature volatility, schedules, budgets, personnel. In addition, risk associated with outsourcing activities to politically unstable locations needs to be identified


INFSOF 5221


25 May 2012 12


Table 5 Guidelines for Specific Goal 2 Define Management Between Locations. Global Teaming Guidelines SPECIFIC GOAL 2 SG2: Define Management Between Locations SP 2.2 Operating Procedures Goal: Set up operating procedures for effective collaboration between locations 1 ‘‘Define how conflicts and differences of opinion between locations are addressed and resolved’’ Set up a strategy to handle, monitor and anticipate where conflict between remote locations may occur. The strategy should include how conflict will be resolved and how a person responsible for that resolution is selected When defining the global strategy for dealing with conflict, different types of conflict have to be taken into account, for example conflict due to fear as well as cultural differences 2

‘‘Implement a communication strategy for the team’’ Plan, facilitate, encourage and monitor communication between teams Provide training on how best to communicate with remote colleagues, including the effective operation of communication tools and procedures Consider linguistic and cultural implications inherent when communicating remotely

3

‘‘Establish communication interface points between the team members’’ Strategies need to be put in place which encourages both formal and informal reporting Ensure that relevant team members are made aware of how and when they will receive inputs to products, needs to distribute outputs from and when complete work products are required Ensure teams are aware of potential constraints such as legal restrictions and holidays in countries within which they are developing the product Ensure that Information about each team member is easily accessible by colleagues. Information of an individual’s role within the team and their specific areas of responsibility should be combined with a photograph, their first name, surname, friendly name (if appropriate) and their preferred form of address Intranets and wikis can be invaluable for this form of communication

4

‘‘Implement strategy for conducting meetings between locations’’ Identify appropriate global meeting technology is used Try to ensure all participants are comfortable with global meeting and are given opportunity to agree or disagree with points raised, and offer new ideas Circulate agenda prior to meeting, and clearly minute actions agreed a meeting Ensure that no delay occurs between the meeting and the circulation of minutes as people may be waiting for the minutes before implementing the actions

SP 2.2. Collaboration between locations Goal: Develop a motivated and focused team who share a common purpose and objectives 1 Identify common goals, objectives and rewards for the global team Global Project manager sets project goals and objectives Goals at project level are common to all locations Project goals and objectives communicated, understood and agreed across all team members regardless of location The global team is viewed as an entity in its own right, regardless of the location of its team members and its performance should be judged and rewarded accordingly Acknowledging team success may require tailoring rewards to the needs of different cultures Project Managers need to understand the cultural motivation of the different team members and identify and apply appropriate rewards in each situation when and where relevant Consideration should be given to cultural issues, economic situation and income tax laws when planning rewards

985 986 987 988 989 990 991 992 993 994 995

2

Collaboratively establish and maintain work product ownership boundaries Define product ownership boundaries through partitioning of work across GSE teams Each location should understand their role within the life cycle of the product Each location should understand how their modifications to the product unit can affect the other locations

3

Collaboratively establish and maintain interfaces and processes Define common process goals across all locations Define process ownership – placing ownership with those closest to process where possible Seek and encourage input from team members at all locations Let team members know their input to process development and ownership is valued Processes should address specific challenges associated with GSE Processes should take into account the relevant structures and procedures from all sites

4

Collaboratively develop, communicate and distribute work plans Achievable milestones should be planned and agreed Within the commitments made, team members must explicitly include communication plans to include use synchronous and asynchronous communication tools Contingency plans should be in place to address potential risks Establish procedures to coordinate implementation of contingencies when and if required

cover all the areas that can cause the project to fail, or cause additional problems. We plan to use the following strategy: initially introduce the model (goals and practices) to quality managers or project managers, and then roll out a training programme as to how to implement each practice. We will later revisit the organization after an agreed period of time to assess progress or the extent of implementation and observed changes. Evaluating the model in this way, has created a basis for the next phase of development, plus we have the support of several multinational and Small to Medium sized Enterprises (SMEs) GSD organizations who would like to be involved in future evaluations,

to ensure that the model continues to be based on both empirical and research evidence of good practices.

996

7. Conclusion

998

Many organizations have discovered to their cost that implementing a GSE strategy is a complex and difficult task [6,14,56]. Extensive research in this area has identified that this is due to a number of factors which include the nature and impact of geographical, temporal, cultural and linguistic distance [56,91]. In addition, whether undertaken in a collocated or geographically dis-

999


997

1000 1001 1002 1003 1004

INFSOF 5221


25 May 2012 I. Richardson et al. / Information and Software Technology xxx (2012) xxx–xxx 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070

tributed environment, team-based software development is not simply a technical activity. It also has important human, social and cultural implications which need to be specifically addressed. While the technical aspects of software development cannot be underestimated, neither can the importance of establishing and facilitating the effective operation of these teams. While we have structured the GT process area to be similar to the CMMIÒ model, it can either be used with other CMMIÒ process areas or as a stand-alone process which organizations can implement when establishing global software teams. It therefore has a similar relationship to other CMMIÒ extensions that have been developed to complement the CMMIÒ Development process model such as +SAFE [92] and RMCM [93]. Our research supplements the CMMIÒ for Development model with one additional process area for GT. The GT model adheres to the same assumptions, structure and terminology as the CMMIÒ. This is particularly important in relation to GT as CMMIÒ certification is often a common attribute of global software development organizations. In this paper, we focused on two research questions. In the first instance we asked: What are the threats faced by global software organizations if they do not implement GSE processes correctly? An analysis of the literature and our empirical studies, found that ignorance of associated risks can lead to a loss of competitive advantage, practitioner de-motivation and poor quality software. In summary, failing to implement GSE processes correctly means that organizations are putting themselves at risk of project failure. We also found that organizations lack support in how to implement a GSE strategy, which provided a rationale for our second research question that looks at how to present a set of practices for GSE teams. Our second research question queried whether the CMMIÒ software process improvement structure could be used as a basis for developing a process area to support team management in a global software engineering environment. Having carried out the gap analysis between the CMMIÒ and the GSE factors identified in our previous research, we established that there were three categories of factors within the CMMIÒ, two of which require more explicit definitions to apply to GSE processes. Using this information as a basis, we were able to use the CMMIÒ structure as a basis for the development of the GT process area. This process area can be used as a CMMIÒ supplement, but can also be used in conjunction with other processes which a global software project team may choose to implement. We have embarked on further research in conjunction with a Financial Services company to establish how well this process area can work within a regulated environment. The Global Teaming process area presented in this study focuses on the importance of establishing and managing effective software teams in the globally distributed setting. Much of the research on GSE has focused on understanding why there are difficulties with implementing GSE within organizations. While this provides a needed understanding of GSE, it is also important that we, the GSE researchers, present industry with solutions to their GSE difficulties. The Global Teaming process presented in this paper is a step in this direction. Through its development we provide specific goals, specific practices, sub-practices and guidelines which can be used by industry implementing a GSE strategy. We also explain the potential threats to GSE if these practices are not considered. When implementing software process improvement there is a requirement for tangible results to be achieved in a reasonable time frame. This is particularly important to sustain the level of effort required for improvement to take place. Practitioners should therefore find the practical guidelines provided by the GT process area particularly helpful as they address key aspects of GSE and discuss threats if particular practices are not implemented. We are at the initial stages of developing the Global Teaming model. This GT model has a foundation in Software Process

13

Improvement and the model’s future development will include a formally validated set of GSE practices based on a longitudinal study. We have made a start in this direction, by applying the Global Teaming high level practices to specific implementable practices relating to architectural knowledge management in a global setting [19]. Our current and future work involves working with our industrial partners to validate the Global Teaming model, and early results indicate that all the model’s practices are relevant to a global software organization. We recommend that organizations implementing structured processes in a globally distributed environment should also implement the Global Teaming process area.

1071

Acknowledgements

1083

The research presented in this paper has been supported, in part, by Science Foundation Ireland (SFI) through the GSD for SMEs cluster project, Grant No. 03/IN3/1408C and the Science Foundation Ireland CSET Grant Nos. 03/CE2/I303.1 and 10/CE/I1855, Lero – the Irish Software Engineering Research Centre, by the SFI Stokes Lectureship Programme, Grant No. 07/SK/I1299 and the SFI Principal Investigator Programme, Grant No. 08/IN.1/I2030.

1084

Appendix A. Grouping and Summaries of the 25 GSE Factors

1091

The 25 GSE factors identified in our empirical study can be grouped under four broad headings of Distance, Infrastructure, Management and Human Factors as follows:

1092

A.1. Distance

1095

A.1.1. Communication Effective communication is a key factor for the successful operation of global teams. Good communication in the global team setting does not just occur; it has to be planned, facilitated and monitored. Training on how to communicate with remote colleagues also needs to be provided to team members and managers at all locations.

1096

A.1.2. Language English is the lingua franca of the software industry the implications of dealing with remote colleagues whose first language is not English needs to be considered and addressed. Measures should be taken to determine the language competency of staff who are not fluent English speakers. If there is a requirement for English language classes they should be provided. Where linguistic difficulties are encountered all parties need to be encouraged to request clarification and steps put in place to address and if possible prevent such issues arising again.

1103

A.1.3. Culture An important issue which has to be recognized and addressed to successfully manage geographically distributed team based software projects is the cultural diversity of global team members. If the full implications of cultural diversity are not properly understood and measures taken to address them it can have serious negative repercussions on the operation of global teams.

1113

A.1.4. Temporal Issues The full implications of temporal distance on the operation of global teams needs to be considered and steps taken to leverage its advantages and minimize its potential for negative impact. The necessity for the reliance on asynchronous communication tools requires due consideration. Where possible the overlap in working hours between sites should be maximized and measures

1120


1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082

1085 1086 1087 1088 1089 1090

1093 1094

1097 1098 1099 1100 1101 1102

1104 1105 1106 1107 1108 1109 1110 1111 1112

1114 1115 1116 1117 1118 1119

1121 1122 1123 1124 1125 1126

INFSOF 5221


25 May 2012 14


1129

taken to ensure that this time is fully leveraged. The full implications of the implementation of an integrated follow the sun strategy has to be considered and specifically addressed.

1130

A.2. Human Factors

1131

A.2.1. Fear The impact fear has on the operation of global teams is considerable and should not be underestimated. This can manifest itself in numerous ways including the desire to prevent or limit communication with remote colleagues. In some instances the objective can be to directly hinder the work of these remote colleagues. Our research has highlighted the severity and persistence of these types of problems which did not decrease with time. The implications fear has on the operation of global teams should never be under estimated. It needs to be recognized, understood and specific measures put in place to address and prevent its potential for negative impact.

1127 1128

1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173

A.2.2. Motivation A key factor in the successful operation of global teams is motivation. Geographical and temporal distance negatively impact on the motivation of global team members. This is due to the problems which arise when developing working relationships in an asynchronous environment. It is equally difficult to be motivated to cooperate and support remote colleagues who are often perceived as about to take the jobs of those at the location where the work is being outsourced/offshored from. These issues all negatively impact on the level of motivation of team members. A.2.3. Trust A related factor in the successful operation of software testing teams is the establishment of trust. In a global environment it can be difficult to develop and maintain trust between remote team members. Numerous factors come into play, which include the lack of opportunities for the development of personal relationships between remote team members. These can be compounded by cultural, linguistic, motivation and fear related issues. A.2.4. Cooperation Teamwork is a cooperative activity and without cooperation teams cannot operate effectively. Like so many other factors which are essential for global teams, distance negatively impacts on the level of cooperation that takes place between remote team colleagues. The reality is that team members must be motivated to establish effective cooperation with their remote colleagues. Like so many other factors outlined in this list of 25 GSE factors, numerous issues directly mitigate against the establishment of cooperation in the global team environment. In these circumstances from the project management perspective cooperation between team locations has to be developed, established and effectively managed.

1174

A.3. Management

1175

A.3.1. True Cost It is imperative that the true cost of global team operation be determined and outlined to all the relevant parties. A key factor in the selection of a global team strategy is to leverage the potential benefits of labour arbitrage between geographical locations. The reality is that the cost difference in salary levels between sites is not in fact the true cost. There are additional factors which include operational, management, training, travel and productivity costs which need to be factored in. This ensures that unrealistic returns are not anticipated and sustained management support is provided for the implementation of a global team strategy.

1176 1177 1178 1179 1180 1181 1182 1183 1184 1185

A.3.2. Project Management To implement a successful global team strategy, all the factors that impact on the operation of collocated software projects come into play and need to be addressed by effective project management. There are also additional global team factors which require specific attention. In these circumstances it is clear that a collocated project management approach is not adequate and the development of a global team project management strategy is required.

1186

A.3.3. Risk Management The implementation of a global team software development strategy to undertake organizational mission critical activities is a risky endeavour. There are micro- and macro-risk elements which need to be carefully assessed and addressed. Micro-risks can often be correctly determined and alternative strategies put in place to mitigate their potential impact. Macro-risks on the other hand may not even be considered. These include political risk and the implications of an inadequate understanding of the culture of staff at other locations and the negative impact of implementing inappropriate strategies which can result.

1195

A.3.4. Defined Roles and Responsibilities It is important that roles and responsibilities for all team members should be clearly defined, articulated and effectively disseminated. This should be supported by a clearly defined common vocabulary that is understood by all team members. This vocabulary needs to cover areas such as activities, tools, the process, milestones deliverables and artefacts.

1206

A.3.5. Team Selection The selection of global team members needs to be based on the technical requirements of the project. The Project Manager requires direct access to information regarding potential team members’ academic, technical skills and experience. When relevant, ‘linguistic capability’ needs to be determined and given due consideration. When all team members have been recruited, their training requirements (regardless of location) need to be evaluated and addressed.

1213

A.3.6. Effective Partitioning The effective partitioning of tasks across team members and sites is a very important aspect of an efficient global team operation. In these circumstances three strategies may be considered to effectively partition work. They are modularized, phased or an integrated approach. Each has their own distinct advantages and disadvantages, but their selection is often dependant on the nature of the work being undertaken or and the physical location of tools or specific skill sets.

1222

A.3.7. Skills Management To facilitate effective global team operation the technical capability and skill level of all global team members needs to be made available to the Project Manager. This information should be presented in a format that can be understood, easily maintained and efficiently accessed. There is also the requirement for an effective mechanism and procedure for all team members to be able to access and identify relevant technical and subject matter experts.

1231

A.3.8. Knowledge Transfer Effective knowledge transfer is a key activity when establishing and operating a global team. Adequate training measures and methods need to be implemented to ensure this activity is sufficiently supported and carried out. A procedure to evaluate the effectiveness of knowledge transfer activities should be put in

1239


1187 1188 1189 1190 1191 1192 1193 1194

1196 1197 1198 1199 1200 1201 1202 1203 1204 1205

1207 1208 1209 1210 1211 1212

1214 1215 1216 1217 1218 1219 1220 1221

1223 1224 1225 1226 1227 1228 1229 1230

1232 1233 1234 1235 1236 1237 1238

1240 1241 1242 1243 1244

INFSOF 5221


25 May 2012 I. Richardson et al. / Information and Software Technology xxx (2012) xxx–xxx 1245 1246

1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257

1258 1259 1260 1261 1262 1263 1264 1265 1266 1267

1268 1269 1270 1271 1272 1273 1274 1275

1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286

place. Based on the results achieved the provision of further training and support should be made available, if and when required.

vided to all team members. Shared ownership of the process should be fostered between team members across locations.

1303

A.3.9. Coordination Distance directly negatively impacts on the effective coordination of global teams. Specific measures are required to address the issues this raises. Effective coordination ensures that adequate planning and the required resources are provided to undertake the necessary tasks. This includes ensuring that suitable infrastructure and processes are in place to carry out the work. Successful coordination also requires that achievable milestones are planned and agreed. There is the need for effective monitoring to be put in place to oversee ongoing progress with reference to costs, time, productivity, risk and quality.

A.4.2. Tools Where possible the selection of standard development and problem reporting tools should take place across locations. This insures the validity of the development process and the compatibility and interoperability of artefacts produced. The provision of and use of effective Configuration Management (CM) tools and a well-documented CM procedure is also essential for efficient team operation in the global environment.

1305

A.4.3. Technical Support The issue of technical support requires particular consideration in the global team environment. When tools are distributed across a number of geographical locations the issues of who and how technical support will be provided needs to be considered. Specifically the geographical locations covered by warranties and service agreements should be identified and addressed to ensure that all team member locations are adequately covered.

1313

A.4.4. Communication Tools An adequate selection of synchronous and asynchronous communication tools should be provided to allow effective communication to take place between team members regardless of location. An important aspect of the provision of such tools is to ensure staff are motivated and trained to leverage their capabilities.

1321

References

1327

[1] J.D. Herbsleb, Global Software Engineering: The Future of Socio-technical Coordination in Future of Software Engineering (FOSE’07) 2007, Minneapolis, MN, USA IEEE, 2007. [2] E. Carmel, Global Software Teams, Collaboration Across Borders and Time Zones, Prentice Hall, Saddle River, NJ, 1999. [3] P.J. Ågerfalk, B. Fitzgeral, Flexible and distributed software processes: old petunias in new bowls?, Communications of the ACM 49 (10) (2006) 26–34 [4] A.F. Rutkowski, D.R. Vogel, M. Van Genuchten, T.M.A. Bemelmans, M. Favier, Ecollaboration: the reality of virtuality, IEEE Transactions on Professional Communication 45 (4) (2002) 219–230. [5] V. Casey, Leveraging or Exploiting Cultural Difference? in: 4th IEEE International Conference on Global Software Engineering (ICGSE) 2009, Limerick, Ireland, 2009. [6] E. Carmel, P. Tjia, Offshoring Information Technology: Sourcing and Outsourcing to a Global Workforce 2005, Cambridge University Press, Cambridge, UK, 2005. [7] S. Krishna, S. Sahay, G. Walsham, Managing cross-cultural issues in global software outsourcing, Communications of the ACM 47 (4) (2004) 62–66. [8] E. Carmel, R. Agarwal, Tactical approaches for alleviating distance in global software development, IEEE Software 1 (2) (2001) 22–29. [9] V. Casey, in: I. Richardson, M. O’hAodha (Eds.), Software Testing and Global Industry: Future Paradigms, Cambridge Scholars Publishing, Newcastle, UK, 2009, p. 220. [10] D.E. Damian, D. Zowghi, An insight into the interplay between culture, conflict and distance in globally distributed requirements negotiations, in: Proceedings of the 36th International Conference on Systems Sciences (HICSS’03), Hawaii, 2003. [11] S. Beecham, T. Hall, A. Rainer, Defining a requirements process improvement model, Software Quality Journal 13 (3) (2005) 247–279. [12] CMMI Product Team, CMMI for Development, Version 1.3, Technical Report CMU/SEI-2010-TR-033, Software Engineering Institute, Carnegie Mellon University: Pittsburgh, Pennsylvania ,2010. [13] C. Ebert, P. De Neve, Surviving global software development, IEEE Software 18 (2) (2001) 62–69. [14] J.D. Herbsleb, D. Moitra, Global software development, IEEE Software 18 (2) (2001) 16–20. [15] P.L. Bannerman, Toward an integrated framework of software project threats, in: 19th Australian Conference on Software Engineering, ASWEC ’08, 2008. [16] K. Buyens, B. De Win, W. Joosen, Empirical and statistical analysis of risk analysis-driven techniques for threat management, in: The Second International Conference on Availability, Reliability and Security, ARES’07, 2007. [17] I. Richardson, V. Casey, J. Burton, F. McCaffery, Global software engineering: a software process approach, in: A. Finkelstein, A. van der Hoek, J. Grundy, I. Mistrík, J. Whitehead (Eds.), Collaborative Software Engineering, SpringerVerlag/Computer Science Editorial, 2010, pp. 35–56.

1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374

A.3.10. Visibility Due to the loss of informal contact and temporal and geographical distance visibility is directly hampered by the operation of global teams. There are two aspects to visibility. The first is that roles and responsibilities need to be clearly articulated and understood by all the relevant parties. As outlined when discussing the defined roles and responsibilities factor this is best supported by the use of a common vocabulary. The second aspect is to ensure there is adequate visibility into the process to monitor team effort and performance and to determine project status. A.3.11. Reporting Requirement Given the requirements of the global team environment and the impact it has on visibility there is a need for the establishment of an effective reporting schedule. Adequately detailed and timely reports are required to provide effective visibility into the process. There is also the need (where relevant) for these reports, or summaries to be communicated to all team members at regular intervals to outline the progress of the project. A.3.12. Information Management A key component in successful global team operation is the dissemination of relevant information between team members. As with the other factors outlined in this section information dissemination is negatively impacted by distance. The loss of face-to-face contact and the need to rely on asynchronous communication all impact on the level and quality of information that is available and transmitted between sites. There is the specific requirement for the availability of relevant information regarding team members, remote locations i.e. public holidays, project procedures, activities and project status.

1295

A.3.13. Teamness Within the global team context there is a clear need for the development of a one team approach. Teamness is based on team member relationships that facilitate the development of mutual respect and trust. This leads to the development of a cohesive motivated team that sees itself as a single unit regardless of its members’ location. This is achieved through the establishment and maintenance of a shared common vision, goals, and objectives. Teamness has to be fostered, developed and effectively managed.

1296

A.4. Infrastructure

1297

A.4.1. Process Management A process which directly addresses the specific requirements of the global team environment needs to be developed and implemented. Such a process needs to be documented and stored in a format that can be accessed from all the relevant team locations. Adequate training on the operation of the process should be pro-

1287 1288 1289 1290 1291 1292 1293 1294

1298 1299 1300 1301 1302

15


1304

1306 1307 1308 1309 1310 1311 1312

1314 1315 1316 1317 1318 1319 1320

1322 1323 1324 1325 1326

INFSOF 5221


25 May 2012 16 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459


[18] J. Noll, S. Beecham, I. Richardson, Global software development and collaboration: barriers and solutions, ACM SIGCSE Bulletin – Special Section on Global Intercultural Collaboration (2010) (September). [19] S. Beecham, J. Noll, I. Richardson, N. Ali, Crafting a global teaming model for architectural knowledge, in: IEEE International Conference for Global Software Engineering (ICGSE 2010), Princeton, USA, 2010. [20] S. Beecham, J. Noll, I. Richardson, D. Dhungana, A decision support system for global software development, in: Methods and Tools for Project/Architecture/ Risk Management in Globally Distributed Software Development Projects PARIS Workshop, Co-located with IEEE International Conference on Global Software Engineering (ICGSE ‘11), Helsinki, Finland, 2011. [21] H. Holmstrom, E.Ó. Conchúir, P.J. Ågerfalk, B. Fitzgerald, Global software development challenges: a case study on temporal, geographical and sociocultural distance, in: IEEE International Conference on Global, Software Engineering (ICGSE’06), 2006. [22] R. Prikladnicki, J.L.N. Audy, R. Evaristo, Global software development in practice, lessons learned, Software Process Improvement and Practice 8 (4) (2003) 267–279. [23] J.A. O’Brien, Management Information Systems – Managing Information Technology in the Business Enterprise, sixth ed., Mc Graw Hill, Irwin, 2002. [24] G. Crow, B. Muthuswamy, International outsourcing in the information technology industry: trends and implications, Communications of the International Information Management Association 3 (1) (2003). [25] S.S. Toaff, Don’t play with ‘‘mouths of fire’’ and other lessons of global software development, Cutter IT Journal 15 (11) (2005) 23–28. [26] W.H. Davidow, M.S. Malone, The Virtual Corporation, Edward Brulingame Books/Harper Business, New York, 1992. [27] S.L. Jarvenpaa, B. Ives, The global network organization of the future: information management opportunities and challenges, Journal of Management Science and Information Systems 10 (4) (1994) 25–57. [28] S. Mohrman, Albers, in: C.L. Cooper, D.M. Rousseau (Eds.), The Context for Geographically Dispersed Teams and Networks, 6, John Wiley & Sons, Chichester, 1999, pp. 63–80. [29] A. Powell, G. Piccoli, B. Ives, Virtual teams: a review of current literature and direction for future research, The DATA BASE for Advances in Information Systems 35 (1) (2004) 6–36. [30] J. Lipnack, J. Stamp, Virtual Teams: Reaching Across Space, Time and Originating with Technology, John Wiley & Sons, 1997. [31] G. DeSanctis, N. Staudenmayer, S.S. Wong, in: C.L. Cooper, D.M. Rousseau (Eds.), Interdependence in Virtual Organizations, 6, John Wiley & Sons, Chichester, 1999, pp. 81–104. [32] J. Kotlarsky, I. Oshri, Country attractiveness for offshorting and offshore outsourcing: additional considerations, Journal of Information Technology 23 (2008) 228–231. [33] I. Oshri, J. Kotlarsky, L.P. Willcocks, Global software development: ‘‘exploring socialization and face-to-face meetings in distributed strategic projects’’, Journal of Strategic Information Systems 16 (2007) 25–49. [34] V. Casey, I. Richardson, Virtual teams section, in: P.A. Laplante (Ed.), Encyclopaedia of Software Engineering, CRC Press – Francis Taylor Group, New York, 2010. [35] W. Shewhart, Economic Control of Quality of Manufactured Product, Van Nostrand Company, New York, 1931. [36] W.E. Deming, Out of Crisis, Cambridge University Press, 1982. [37] W.S. Humphrey, Managing the Software Process, Addison-Wesley, Reading, MA, USA, 1989. [38] M.C. Paulk, B. Curtis, M.B. Chrissis, C.V. Weber, The Capability Maturity Model for Software, SEI-93-TR-24, S.E. Institute, 1993. [39] N. Fenton, R. Whitty, Y. Iizuka (Eds.), Software Quality Assurance and Measurement – A Worldwide Perspective, International Thomson Computer Press, UK, 1995. [40] C. Jones, Patterns of Software Systems Failure and Success, International Thompson Computer Press, Boston, USA, 1996. [41] J.P. Kolind, D.G. Wastell, The SEI’s capability maturity model: a critical survey of adoption experiences in a cross-section of typical UK companies, in: T. McMaster, E. Mumford, E.B. Swanson, B. Warboys, D. Wastell (Eds.), IFIP TC8 WG8.6 International Working Conference on Diffusion, Adoption and Implementation of Information Technology, Ambleside, Cumbria, UK, 1997, pp. 305–319. [42] B. Bergman, B. Klefsjo, Quality from Customer Needs to Customer Satisfaction, Studentlitteratur, Sweden, 1994. [43] J.G. Brodman, D.L. Johnson, A software process improvement approach tailored for small organisations and small projects, in: 19th International Conference on Software Engineering, Boston, Massachusetts, USA, 1997. [44] D. Galin, M. Avrahami, Are CMMI program investments beneficial?, IEEE Software (2006) 81–87 [45] W.S. Humphrey, Three dimensions of process improvement. Part I: process maturity. CROSSTALK, The Journal of Defense, Software Engineering (1998). [46] L.B. Strader, M.A. Beim, J.A. Rodgers, The motivation and development of the space shuttle onboard software (OBS) project, Software Process Improvement and Practice 1 (2) (1995) 107–113. [47] J.W. Rottman, M.C. Lacity, Proven practices for effectively offshoring IT work, MIT Sloan Management Review (2006) 56–63. [48] V. Casey, I. Richardson, A structured approach to global software development, in: European Systems and Software Process Improvement and Innovation (EuroSPI), Dublin, Ireland, 2008.

[49] R. Prikladnicki, J.L.N. Audy, F. Shull, Patterns in effective distributed software development, IEEE Software (2010) 12–15. [50] N. Ramasubbu, M.S. Krishnan, P. Kompalli, Leveraging global resources: a process maturity framework for managing distributed development, IEEE Software 22 (3) (2005) 80–86. [51] C.G.v. Wangenheim, J.C.R. Hauck, C.F. Salviano, A.v. Wangenheim, Systematic literature review of software process capability/maturity models, in: Proceedings of International Conference on Software Process. Improvement and Capability dEtermination (SPICE), Pisa, Italy, May 2010. [52] V. Casey, Virtual software team project management, Journal of the Brazilian Computer Society, Special Issue on Global Software Development 16 (2) (2010) 83–96. [53] N.B. Moe, D. Smite, Understanding a lack of trust in global software teams: a multiple-case study, Software Process Improvement and Practice 13 (3) (2008) 217–231. [54] V. Casey, I. Richardson, The impact of fear on the operation of virtual teams, in: International Conference on Global Software Engineering, ICGSE 2008, IEEE, Bangalore, India, 2008. [55] V. Casey, I. Richardson, Uncovering the reality within virtual software teams, in: First International Workshop on Global Software Development for the Practitioner, ICSE 2006, China ACM Press, Shanghai, 2006. [56] V. Casey, I. Richardson, A practical application of the IDEAL model, Software Process Improvement and Practice 9 (3) (2004) 123–132. [57] V. Casey, I. Richardson, Virtual software teams: overcoming the obstacles, in: 3rd World Congress for Software Quality, Munich, Germany, 2005. [58] R.K. Yin, Case Study Research/Design and Methods, 5, Sage Publications, Thousand Oaks, CA, USA, 1994. [59] A. Strauss, J. Corbin, Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory, Sage Publications, Thousand Oaks, CA, USA, Second 1998. [60] B.W. Boehm, R. Ross, Theory-W software project management principles and examples, IEEE Transactions on Engineering Management 15 (7) (1989) 902–916. [61] D.W. Karolak, Global Software Development: Managing Virtual Teams and Environments, IEEE Computer Society Press, Los Alamitos, CA, USA, 1999. [62] G. Paré, L. Dubé, Virtual teams: an exploratory study of key challenges and strategies, in: 20th International Conference on Information Systems, Association for Information Systems: Charlotte, North Carolina, USA, 1999. [63] K.E. Nidiffer, D. Dolan, Evolving distributed project management, IEEE Software 22 (5) (2005) 63–72. [64] V. Casey, A Study of the Factors and Issues which Facilitate and Obstruct the Operation of Globally Distributed Virtual Software Testing Teams, PhD Thesis, Lero, University of Limerick, 2007. [65] D. Smite, Global Software Engineering Improvement, PhD Thesis, Riga Information Technology Institute, University of Latvia, 2007. [66] D. Smite, J. Borzovs, New forms of work in the light of globalization in software development’’ in: M. Pankowska (Ed.), Infonomics for Distributed Business and Decision-making Environments: Creating Information System Ecology, in IGI Global. 2009 ISBN: 978-1-60566-890-1 (Chapter XVI). [67] M. Bass, J.D. Herbsleb, C. Lescher, A coordination risk analysis method for multi-site projects: experience report, in: Fourth IEEE International Conference on Global Software Engineering, Limerick, Ireland, 2009. [68] J. Kotlarsky, I. Oshri, J. von Hillegersberg, Globally distributed componentbased software development: an exploratory study of knowledge management and work division, Journal of Information Technology 22 (2007) 161–173. [69] V. Casey, I. Richardson, Practical experience of virtual team software development, in: European Software Process Improvement (Euro SPI), Trondheim, Norway, 2004. [70] E. Bradner, G. Mark, T.D. Hertel, Effects of team size on participation, awareness, and technology choice in geographically distributed teams, in: Proceedings of the 36th Annual Hawaii International Conference on System Sciences, Hawaii, 2003. [71] V. Casey, I. Richardson, Project management within virtual software teams, in: International Conference on Global Software Engineering, ICGSE 2006, IEEE, Florianopolis, Brazil, 2006. [72] N. Nurmi, P. Bosch-Sijtsema, A. Sivunen, R. Fruchter, Who shouts louder?: exerting power across distance and culture, in: Proceedings of the 2009 International Workshop on Intercultural Collaboration, ACM, Palo Alto, California, USA, 2009. [73] J.S. Persson, L. Mathiassen, J. Boeg, T.S. Madsen, F. Steinson, Managing risks in distributed software projects: an integrative framework, IEEE Transactions on Engineering Management 56 (3) (2009) 508–532. [74] K. Jablokow, M. Myers, Managing cognitive and cultural diversity in global IT teams, in: 5th IEEE International Conference on Global Software Engineering (ICGSE), 2010. [75] A. Avritzer, D. Paulish, Y. Cai, K. Sethi, Coordination implications of software architecture in a global software development project, Journal of Systems and Software 83 (10) (2010) 1881–1895. [76] A. Mockus, J.D. Herbsleb, Challenges of global software development, in: Proceedings, Seventh International Software Metrics Symposium, London, UK, 2001. [77] V. Casey, I. Richardson, Uncovering the reality with virtual software teams, in: International Conference on Global Software Engineering, ICGSE06, IEEE Computer Society, Florianopolis, Brazil, 2006.


1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544

INFSOF 5221


25 May 2012 I. Richardson et al. / Information and Software Technology xxx (2012) xxx–xxx 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569

[78] G. Hofstede, Culture’s Consequences: Comparing Values, Behaviours, Institutions and Organizations Across Nations, Sage Publications, Thousand Oaks, USA, 2001. [79] V. Casey, S. Deshpande, and I. Richardson, ‘‘Outsourcing Software Development The Remote Project Manager’s Perspective’’ in Second Information Systems Workshop on Global Sourcing, Services, Knowledge and Innovation. 2008: Val d’Isére, France. [80] V. Casey, Imparting the importance of culture to global software development, ACM Inroads, Special Issue on Global Intercultural Collaboration 1 (3) (2010) 51–57. [81] V. Casey, Developing trust in virtual software development teams, Journal of Theoretical and Applied Electronic Commerce Research, Special Issue on Trust and Trust Management 5 (2) (2010) 41–58. [82] V. Casey, in: J. Rost, R. Glass (Eds.), Dispatches from the Virtual Software Team Trenches in The Dark Side of Software Engineering, IEEE Computer Society Press, 2011. [83] S.C. Schneider, J.L. Barsoux, Managing Across Cultures, second ed., Financial Times, Prentice Hall, Harlow, 2002. [84] S. Beecham, N. Baddoo, T. Hall, H. Robinson, H. Sharp, Motivation in software engineering: a systematic literature review, Information and Software Technology (IST) 50 (9–10) (2008) 860–878 (Elsevier). [85] B. Fitzgerald, T. O’Kane, A longitudinal study of software process improvement, IEEE Software 16 (3) (1999) 37–45. [86] N. Ali, S. Beecham, I. Mistrik, Architectural knowledge management in global software development: a review, in: KNOWledge engINeering in Global

[87] [88] [89] [90]

[91]

[92]

[93]

17

Software Development (KNOWing), Workshop Collocated with IEEE International Conference on Global Software Engineering (ICGSE’10), Princeton, USA, 2010. D.J. Paulish, Methods and tools for collaboration in GSE environments, in: Internatioanl Conference on Global Software Engineering, ICGSE’06, 2006. M.C. Paulk, A comparison of ISO 9001 and the capability maturity model for software, in: Technical Report, CMU/SEI-94-TR-12, ESC-TR-94-1, July 1994. M.C. Paulk, How IS0 9001 compares with the CMM, IEEE Software (1995) 74–83. S. Deshpande, I. Richardson, V. Casey, S. Beecham, Culture in global software development – a weakness or strength? in: IEEE International Conferences on Global Software Engineering (ICGSE 2010), Princeton, USA, 2010. B. Curtis, Software process improvement: best practices and lesson learned, in: 22nd International Conference on Software Engineering, ICSE, IEEE, Limerick, Ireland, 2000. Software Engineering Institute, ‘‘+SAFE, V1.2: A Safety Extension to CMMIDEV, V1.2, in TECHNICAL NOTE CMU/SEI-2007-TN-006’’, Defence Materiel Organisation, Australian Department of Defence, Software Engineering Institute, , March 2007 (accessed April 2010). J. Burton, I. Richardson, F. McCaffery, M. O’hAodha, Risk Management Capability Model for Medical Device Software, Cambridge Scholars Publishers, 2009.


1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593