ABSTRACT

Context

Software companies are increasingly adopting a global software development (GSD) process as a means of producing lower cost software in shorter development times. However, these projects are not always successful and a number of issues commonly arise that can impact the deliverables of the project and its cost effectiveness. One of the factors that are regularly cited as being responsible for the failure of distributed software projects is lack of coordination across the teams involved. If the tasks and deliverables are not effectively coordinated across the multiple site teams, then insufficient information is exchanged and the project is at risk of failure.

Results

This thesis identifies lack of coordination as being a potential cause of failure in GSD projects. The first part of the paper contains a detailed literature review, which identifies 21 risks associated with coordination activity on GSD projects. The second part of the paper contains an analysis of structured interviews with people who work on GSD projects and considers how these risks have been successfully managed in real life situations. During the stage of the thesis, a further risk is identified. Finally the risks and methods of managing them are mapped and a set of recommendations for managing risks associated with coordination on GSD projects is provided.

Conclusion

It is determined that effective management of risks can improve collaboration across GSD projects and the research also establishes that the number of teams and groups involved in a project does impact the effectiveness of the collaboration that takes place across the teams and people who are involved in that project.

Keywords: Coordination, Global Software Development, risks associated with Global Software Development, risk mitigation in global software development, coordinating teams during Global Software Development.

INTRODUCTION 4

2.1 Background 41..1 Research Motivation: 5

2.1 Aims and objectives 5

2.1 Research Questions 5

2.1 Expected outcomes 6

2.1 Research Methodology 61..1 First phase 61..2 Second phase 81..3 Third phase 9

2.1 Thesis outline 9

2. LITERATURE REVIEW ON COORDINATION IN GSD 11

2.1 Major challenges in GSD 112.1.2 Geographical Distance 11

2.2 Coordination 112.2.1 Importance of coordination in GSD 12

2.3 Coordination mechanisms 12

2.4 Thesis Related Concepts 132.4.1 Risk 13

2.5 Related Work 14

2.6 List of coordination risks, it’s causes and effects 15

3 CASE STUDIES OVERVIEW 21

3.1 Participants 213.1.1 Organization 1: TCS Company, Netherlands 213.1.2 Organization 2: Mermaid Technology, Denmark 213.1.3 Organization 3: Sequel System, USA 223.1.4 Organization 4: Quantum Aviation Company, UK 233.1.5 Organization 5: Teradata Company 233.1.6 Organization 6: Infomist Company, Pakistan. 243.1.7 Organization 7: Acrologics Pvt.Ltd USA, Germany, Pakistan 25

3.2 Summary 26

4 RESULTS 27

4.1 Results of grounded theory 27

4.2 Risk 28

4.3 Finding of risks in all case studies project 28

4.4 Recommendations 29

5 DISCUSSION 35

6 VALIDITY THREATS 38

6.1 Internal Validity 386.1.1 Qualitative Validity Threats 38

6.2 External Validity 39

7 EPILOGUE 40

7.1 Conclusion 40

7.2 Answers to the Research Questions 40

7.3 Future Work 41

8 REFERENCES: 42

INTERVIEW QUESTIONS 46

1. Chapter One This chapter explains the background, aim & objectives, research questions, research methodology and thesis outline.

1.1. IntroductionIn the era of globalization, outsourcing is often considered to be a better way of

effectively operating on the global market. Tight budgets, shortage in resources, expenses and time considerations has motivated many enterprises to start looking for partners outside their operational zone [16]. The main aim of any software organization is to produce a software product with lower costs, higher profit and better quality. They also need to develop products that will work universally across different countries; thus supporting Globalization objectives [16][1]. For example, the development cost of a software product in India is 6 times cheaper than those developed in Europe and America. Global Software Development (GSD) is the kind of area where people with different nationalities and cultures can work together through the exchange of the information on the software project over a physical distance to produce the software product with their innovative ideas on the common task [16] [2] [3].

GSD is defined as the plan of action in which the software development is performed under various boundaries, such as temporal, political, organizational and cultural [16] [2] [3]. GSD is also referred to as Global Software Engineering (GSE). However, for the purposes of this paper, the term GSD will be used throughout.According to Holmstrom et al, in their study of the major challenges in GSD, issues are generally caused by three factors [3]:

Temporal Distance Geographical Distance Socio-Cultural DistanceTemporal distances relate to differences in time and these distances often increase the

frustration involved in completing a project, cause discontinuity in the project tasks and can cause people to lose track. In addition to this, delay in response results due to limited overlap with colleagues can make individuals feel like they are not fully involved in the project or of significance to the project tasks [3.]

On the other hand geographical distances need computer-mediated processes that can cause a lack of closeness lack of transparency of tasks and a feeling of isolation. This situation creates hurdles for direct supervision and control [3].

Socio-cultural distances often lead to miscommunication and the way different people under the influence of different cultures react to different situations. Communication is important in any development process and communication issues will lead to coordination and collaboration issues [6][3]. In considering methods of overcoming the challenges caused by distance on GSD projects, many researchers refer to the 3 Cs; Coordination, Communication and Collaboration. They speculate that, if managed correctly, these three areas can help to overcome the main factors for failure of the distributed software projects [4] [5] [6] [7]. This research work is concerned with the area of coordination. Coordination between distributed teams causes overhead. Coordination is defined as the exchange of the information between software engineers or organizational units needed to complete their tasks in the global software projects [4] [6].

Coordination is considered to be a crucial part of GSD [11][12][13][14][15]. The ability to coordinate the project teams in globally distributed projects is very important [4]. Project members at different sites spend much of their time seeking information that is necessary to complete their tasks [4].

Barstow [11] mentioned that an individual software engineer spends more time exchanging information than any other activity. Without proper coordination, the project will not be completed on time, resulting in an increase in the overall cost of project.

Informal and ad-hoc interaction plays major role in facilitating effective coordination [4]. Ad-hoc communication is always necessary in the distributed projects and is often needed to deal with any unanticipated issues or problems that may break down the existing coordination mechanisms [8]. Coordination is needed for the organizations especially to work on common goals at different places in GSD projects [4][8]

One of the major issues in GSD is to recognize the coordination risks among distributed team members in GSD projects. Through doing this project managers can potentially prevent their occurnence. This thesis work aims to identify such risks and provide a set of recommendations to tackle the coordination risks in GSD projects. An exploratory study was considered to conduct the semi-structured interviews and survey in few software organizations to gather the data and information on coordination risks in GSD projects [31]. The grounded theory was applied to the data analysis in order to generate a list of recommendations from the literature industrial study and collected data from participant software organizations [52]. The outcome of this thesis work is a set of recommendations for project managers in software organizations that work on GSD projects. 

1.1.1. Research Motivation:Coordination plays a vital role in the software development life cycle for success or

failure of the software project [11][15]. Many researchers describe problems, solutions, methods and technology tools related to coordination in GSD [4][1] [35]. However, the research available in this area remains limited and there is little research work pertaining to practices or proper strategies for project managers to alleviate the coordination risks in GSD projects [4][42][1]. This research work provides a set of recommendations together with instant tactics for quick reference to project managers to mitigate the coordination risks in GSD projects.

1.2.Aims and objectivesThe aim of this research is to provide a set of recommendations that can help to overcome the coordination risks in GSD projects. To achieve the thesis aims, the following objectives are required to be fulfilled:

To identify the coordination risks in GSD projects and their causes and effects.

To identify the best practices reported in the current research literature to alleviate the risks.

To acquire coordination-related practices in organizations involved in GSE.

To identify the factors that may affect the coordination when the number of sites is increased.

Organizations that have GSD projects can benefit from this research in overcoming the problems related to coordination between project teams and project members at different sites.

1.3.Research QuestionsTo achieve the aim of this research the following research questions are posed:

RQ1. What are the risks in coordinating GSD projects and their causes and effects?

RQ2. What are the best practices reported in the current research literature to alleviate the risks?

RQ3. Which practices are currently applied in industry to overcome coordination risks in GSD projects?

RQ4. Are there any methods, or combinations of recommendations that can help to avoid the risks associated with GSD projects or mitigate the effects of issues as and when they occur?

RQ5: How an increase in the number of sites involved in GSD projects affect the coordination?

1.4.Expected outcomesThe expected outcomes of this research will be related to coordination risk between

distributed teams.

List of coordination risks in GSD projects.

List of causes and effects that are reported in the literature and faced in industry in relation to coordination risks in GSD projects.

List of best practices pertaining to GSD projects as reported in research literature.

List of practices that managers can apply to overcome the risks associated with the coordination of GSD projects.

List of factors that limit the potentially detrimental effects of GSD team coordination impact on productivity throughout the whole development process.

List of recommendations that can help to avoid the risks associated with multi site project coordination and methods of mitigating them in the effect that they do occur.

An insight into the impact increases in the number of sites involved in multi site project will have on the success of the coordination.

1.5.Research Methodology The research work described in this paper is based on a qualitative approach to build the

theory [19]. Research was conducted through three phases and it was anticipated that each phase would contribute towards answering the research questions. This research study is exploratory in nature [17].

1.5.1. First phase: Literature reviewIn this phase, a literature review was performed to answer first two research questions.

Search terms, search questions and search criteria were applied to search relevant articles and research papers on the topic area.

The databases used for literature review were as follows:

IEEE

ACM

Springer Link

Inspec + Compendex

Elsevier

ISI Web

The research questions were used to generate a set of search terms that were based on key words associated with the thesis objectives. These include words such as coordination, GSD projects, effects, risks, recommendations and causes. The keywords were further analyzed to identify alternative and synonyms that may be used in the database. For example, an alternative search term for the word “recommendations” may be “solutions”.

The search terms were categorized into six different combinations and further keywords were generated. For example, one main keyword is “Coordination”. To make sure that no article was missing, the word “coordination” as verb, noun and adverb as an alternative of the keyword were also used. The search terms categories and combinations are provided in table 1 and search questions table 2.

Name of category Search termsC1 Risks OR Effects OR Impact OR Problems OR

Causes OR Issues OR Threats OR Challenges C2 Solutions OR Practices OR

Recommendations OR Good Practices OR Lesson learned OR Experiences OR Success Stories OR Standard OR Mitigate OR Alleviate

C3 “GSD projects” OR “Global Software Development” OR “Global Software Engineering” OR “Distributed Software Development” OR “Distributed Software Engineering” OR “Global Software Projects”

C4 Industrial OR Case study C5 Offshore insourcing OR Offshore outsourcing

OR Nearshoring OR National off shoring OR On shoring outsourcing OR Onshore development OR Offshore development

C6 Supplier OR Customer OR Mediator OR Client OR Central

Table 1: search terms and combinations

Main Key word MKW: “coordination OR coordinate OR coordinating OR coordinated”

Search questions1. MKW AND “GSD projects”2. MKW AND C33. MKW AND C1 OR C24. MKW AND C1 OR C35. MKW AND C1 OR C46. MKW AND C1 OR C57. MKW AND C1 OR C68. MKW AND C2 OR C39. MKW AND C2 OR C410. MKW AND C2 OR C511. MKW AND C2 OR C612. MKW AND C3 OR C413. MKW AND C3 OR C514. MKW AND C3 OR C615. MKW AND C4 OR C516. MKW AND C4 OR C617. MKW 1AND C5 OR C618. C1 AND C319. C4 AND C320. C1 OR C2 AND C321. C1 OR C2 OR C4 AND C3

Table 2: search questions

The search inclusion and exclusion criteria are detailed in Table 3.

Inclusion Include articles which support following criteria

1. Title matches study area2. Abstract matches study area3. Conclusion matches study area4. Full text article should be available in the database5. The article must be relate to coordination and GSD topic6. The article should be peer reviewed 7. The article must include an industrial study 8. Only English language articles are to be used 9. Include articles from 2000

Exclusion 1. Exclude the repeated articles (duplicate).2. Any articles which do not fulfill the detailed inclusion criteria.

Table 3: search criteria

Search questions and criteria were verified with a librarian and with senior researchers.

Results of literature review: 31 relevant articles were identified. 15 articles were utilized to produce a list of coordination risks. A full discussion of coordination risks and their causes and effects is detailed in section 2.6.

1.5.2. Second phase: Exploratory StudyWhen conducting an empirical study there are three types of interviews that can be used to collected data from software organizations; structured, unstructured and semi-structured interviews [23]. This research utilized semi-structured interviews to gather relevant data from participants and these were conducted through the use of open-ended questions about the study area. The coordination risks in GSD projects were explored and practices to mitigate these risks were identified through the use of semi-structured interviews. Semi-structured interviews suited the study area and were useful in identifying coordination risks and practices in GSD projects from interviewees.

The interviews were of use when existing literature was insufficient or information on the topic was lacking [31]. Semi-structured interviews were conducted with project managers from 7 different software organizations. These ensured the researchers access to different perspectives including different domains, geographical differences, cultural and temporal differences. 22 semi-structured interviews were conducted with 10 project managers, 1 consultant and 1 software developer to gather more data and information relevant to the research area of this study [31].

1.5.3. Third phaseThis phase involved the analysis of the data that had been collected from literature

review and semi-structured interviews. The result of this analysis provided recommendations to overcome coordination risks in GSD projects and combination of recommendation to mitigate each risk. Furthermore, the collected data from participant software organizations were also used to analyze the ways in which an increase in the number of sites affected the coordination.

1.6.Grounded Theory This research work is based on the grounded theory (GT). GT was developed by

Glaser and Strauss [52] and involves the analysis of collected data without a preconceived hypothesis [52], the idea of which is to ensure that research is conducted in an open-minded manner. The GT approach involves analyzing the collected data and attempting to identify a number of codes that are then used to create categories for analysis [52]. The main objective of grounded theory is to produce results that are drawn from the collected data and provide points for guidance and a means of enhancing understanding to action in an exact research study area [51]. GT is used in exploratory study as a means of conducting a deep investigation into the phenomenon without any prior knowledge [33].

1.6.1.1.1. Data sources During the research various sources were used. These included journal articles &

research papers, a book for the literature review and 10 project managers, 1 consultant and 1 software developer for interviews. The outputs of all sources were used to generate data to

which the researchers applied grounded theory for analytical purposes. The researchers used NVivo 8 tool for data storage and management.

1.6.1.1.2. Data analysisApplying open coding, axial coding and selective coding techniques followed the

principles of grounded theory. This is also known as theoretical sampling [39][23]. The results of the grounded theory together with further details of these techniques are provided in section 4.1.

1.7.Thesis outlineFollowing this introductory chapter, this thesis work is divided into following chapters:

Chapter Number

Chapter Name Description

2 Literature Review on Coordination Risks in GSD

GSD, challenges in GSD, coordination, Related Work and Literature Review.

3 Case Studies Overview Participant software organizations and project details.

4 Results Findings from literature & case studies, list of recommendations

5 Discussion Data analysis from literature & case studies and Set of recommendation each risk.

6 Validity Threats Threats of this study and we explain about the overcome of these threats in this chapter.

7 Epilogue Provides conclusion, answer to research questions and future work.

Table 4: Thesis outline

Figure 1: Research Methodology overview

1.1. Literature Review on Coordination in GSDMany software organizations strategically target globalized businesses and this has led to

increased requirements for GSD. Within GSD projects stakeholders from different national & organizational culture backgrounds and time zone differences are involved in software development and tasks at various stages of the software development life cycle. Project teams may be geographically, temporally and socio-culturally separated and coordination between team members at different sites will need to occur through the use of effective communication tools [21][3]. This represents a significant challenge, as outlined in section 2.1 and such challenges can lead to issues in project processes like communication, coordination and control [21] [22] [3].

1.8.Major challenges in GSD

2.1.1 Temporal DistanceMany Researchers have found that software organizations that are situated in different

time zones face more issues with communications and the coordination of team members than those organizations that are situated in closer time zones [22]. Temporal distance is also referred to as Time Zone Difference [23]. Time zone difference and time shifting work patterns are the main causes of temporal distance because team members at remote locations may be operating within working hours that do not overlap [24]. Many researchers suggest that synchronous and asynchronous channels can reduce the temporal distance [25].

2.1.2 Geographical DistanceThe effort required for one actor to visit another actor and to reduce the intensity of

communication is known as geographical distance [26]. While informal communication with remote colleagues in order to achieve certain goals is possible through technological means, face-to-face interaction is better than informal communication [27]. When working on GSD projects in TCS Company, Netherlands; offshore team members will visit the onshore members and customer company. This helps them to develop closer working relationships and resolve any issues that occur in a timely manner. Geographical distance renders the possibility of face-to-face meetings very difficult and this impacts on the effectiveness of the communications between project development team members.

2.1.3 Socio-Cultural DistanceDistributed teams consist of members from different nationalities, cultures, languages,

response capability, working styles and life styles [23]. Cultural differences between project team members may influence the way in which certain situations are handled by developers [26]. Due to language barriers, distributed projects introduce misunderstandings [28]. Therefore, they hinder effective coordination in GSD projects. Face-to-Face meeting when it is required, training on national culture and sharing knowledge regarding culture issues and language barriers [29]. Different activities for reducing the negative effect of cultural differences are identified in the literature [27].

1.9.Coordination Coordination between team members is necessary to achieve the overall project

objectives [4] [1]. Coordination was discussed in section 1.1. Some risks in GSD can lead to

coordination breakdown and issues such as lack of group awareness and lack of language skills. These may affect the coordination costs and quality of the product [39] [1] [4]. Coordination is a key factor in developing software in GSD [3][1].

2.1.4 Importance of coordination in GSDIn the current era of globalization, more and more companies are seeking software

solutions that can assist their teams to work remotely from one another. However, the challenges relating to successful GSD remain. Effective coordination between team members is a very important aspect [20]. Awareness of team coordination within a GSD environment is more important when compared to that of a collocated development environment because of the nature and complexity of the challenges associated with GSD. Such issues can often lead to a delay in project completion and an increase in the costs associated with delivering a project [9]. For this reason organizations must realize the importance of coordination in order to fulfill the objectives and increase the likelihood of the project being delivered successfully in the GSD environment [10].

Selection of the right coordination mechanism is situational and depends upon different factors. These include task complexities and geographic distribution [42], both of which have a potential to impact the success of GSD projects. In case the failure of standardization leads to direct supervision or mutual adjustment. Complexity of project is another significant factor that should be considered when selecting an appropriate coordination mechanism [9]. After selecting the right mechanism, trust & common understanding between team members is a foundation for the success of the GSD projects. Increased levels of communication will also help to overcome the complex tasks [9].

Process DimensionTemporal Distance Geographical

DistanceSocio-Cultural Distance

Coordination Coordination efforts and costs typically increase [26] [54].

Reduced informal meeting can lead to lack of critical task awareness [26][54].

Inconsistent work practices can lead to ineffective coordination [26] [54].

Table 5: GSD challenges and Coordination

1.10. Coordination mechanismsMintzberg [9] describes how many projects will be divided into sub-tasks. Such tasks

require proper coordination because of the dependencies between them. Distributed team members will need to pass information to one another, understand the progress that has occurred on other elements of the project and access the same resources. Effective

coordination is imperative in delivering the objectives of the associated tasks and if the successful delivery of one task depends upon dependencies with other tasks then such dependencies need to be managed and coordinated [30][50].

Mintzberg [9] describes three basic coordination mechanisms for organizational work coordination.

Mutual adjustment- based on a simple process of informal and ad-hoc communication.

Direct supervision- one person takes responsibility and acts as manager or leader by issuing instructions and monitoring other factors for the work

Standardization– involves specifying a process or method by which things should be done and the results that are expected. Standardization can occur across work processes, outputs, skills and norms. Standardization of work processes means to achieve the coordination by specifying the work processes of employees whose work is interrelated. Standardization of outputs means to achieve the coordination by specifying the results that are expected. Standardization of skills means to achieve the coordination by schooling the employees to handle various types of tasks. Standardization of norms means to achieve the coordination by specifying the norms to spread out the work. Change in a norm may lead to changes in the coordination of work [9].

Software organizations can’t rely on one coordination mechanism alone and any researchers have found the existence of all coordination mechanisms at play within a development organization [9]. Interestingly, the coordination mechanism can change according to the complexity of the project. Mutual adjustment is used to coordinate easy tasks that have simple dependencies. Direct supervision is used when work between dependencies becomes more complex [42]. Further complexity tends to coordinate the work by standardization. However, as tasks become more complex, the coordination returns to a mutual adjustment mechanism. This is show in Figure 2. Mintzberg explains the mutual adjustment works both in simplest forms of coordination and on the other end of the spectrum in the most complex form of coordination [9].

Figure 2: Coordination mechanism and task complexity [42].

2.1.5 Coordination mechanism in GSDThe negative impact of distance is the main barrier for coordination activities in GSD.

Due to this factor, distributed team members are often negatively affected by geographic dispersion, cultural differences, coordination breakdown and loss of communication. These risks may reduce cooperation between distributed team members and may also reduce mutual understanding between them. Standardization is one of the most effective coordination

mechanisms for a GSD and is often cited as being the primary means of ensuring projects across disparate teams are delivered according to the intended objectives. [10].

1.11. Thesis Related Concepts2.1.6 Risk

Risks are identified as being unwanted events or threats that have a negative impact on the software project in terms of the quality and timeliness of the delivered objectives. Risks can occur in many forms including business risks, technical risks, organizational risks and communication risks [32].

2.1.7 Risk ManagementRisk management is defined as the approach by which potential risks are identified,

analyzed, controlled and managed throughout the software development life cycle of a project. The management of risk throughout the lifecycle of a software project is a common research topic [32].

2.1.8 Coordination RiskCoordination risk pertains to the risks that occur when attempting to coordinate the

delivery of common goals between the team members at different sites. Coordination risks often relate to issues such as communication, language and cultural barriers [4].

2.1.9 GSD ProjectA GSD project is one that involves different people placed in different geographical

locations. When software organizations utilize project outsourcing they create GSD projects that involve people that are located in different areas. These often consist of people of different cultural background and languages [45] [46].

1.12. Related WorkThis section addresses related works pertaining to coordination in GSD.

Mintzberg [9] believes that the role of coordinating mechanisms change in association

with task complexities. Emam Hossain [10] considers the ways in which different

coordinating mechanisms can be used to coordinate distributed projects through the use of

agile software development practices. He identifies two agile methodologies and their

relationship with distributed development. Furthermore, he discusses the use of Scrum and

XP within a distributed environment. He explains that specific scrum and XP practices can be

used to reduce the communication, coordination and control challenges associated with GSD

projects. He also addresses the problems related to use of different coordination mechanisms

and their impact in GSD projects when they are used to coordinate team members through the

use of agile practices [10].

Marcelo Cataldo et al [18] illustrates the coordination breakdown problems in Global

Software Development through the use of four case studies. He provides possible solutions to

overcome the identified problems and increase the ability of the teams to perform their tasks.

Darja smite [1] explains a case study on the coordination practices used in the

organization (Latvia company) and suggests some coordination practices by interviewing

some experienced managers from one particular organization. This article can be used to

identify some coordination risks, their causes and effects and coordination practices that can

be used to mitigate the coordination problems in the software organization.

Darja smite et al [39] considers the coordination challenges that are experienced by

remote teams. The article explains the different coordination mechanism and the threats that

can affect the effectiveness of the coordination. The article recommends that keeping team

sizes small so that members can more readily coordinate with each other and to adjust

coordinating mechanisms and apply mutual adjustment when needed reduces such risks.

Erran Carmel et.al [38] explains the consequences of time zone differences on

coordination costs. The model presented is based on the formula on production, coordination

and vulnerability costs. They describe and evaluate the model with regression analysis by

using randomly generated observations.

David F. Redmiles et.al [44] developed a tool that is based on the relationship between

coordination and software dependencies of GSD work. Global project managers can use this

tool to monitor the interaction among distributed team members.

In 2006 H. Holmstrom et al[21] proposed some recommendation for overcoming the

issues of temporal distances. These included keeping the dependencies as low as possible,

attempting to ensure that subtasks are not divided across more than two sites and avoiding a

‘follow-the-sun’ concept. Near shoring was also named as a means of decreasing the risk of

temporal distances and reducing coordination and communication problems. Carmel, E. [22]

explains that coordination is best achieved through standardization: “[the] most effective way

to manage global software teams is reliance on methodological standardization”

Matthew Bass et al [4] explore coordination risk analysis methods for GSD projects.

Project team members work at different geographic distance because of many global

distributed projects and thus have an impeded ability to coordinate among project teams and

members. This may cause a mismatch. Coordination risk analysis methodology is used to

determine the significant coordination mismatches before they become an issue [4]. Matthew

Bass et al [4] categorized the coordination risks as follows: Technical Risk Factors,

Organizational Risk Factors and People Risk Factors.

1.13. List of coordination risks, it’s causes and effectsThe literature review and analysis of existing research [1][4][10][25][27][34][35][36]

[37][38][39][40][42][49][53], was used to produce a list of coordination risks and their accompanying causes and effects. These are follows:

Note: The literature review revealed that risks, causes and effects in GSD projects are interrelated. One risk may lead to other risks and other risks may lead to, or can be caused by, one or more risks.

For example , time delay may occur due to poor communication. Poor communication can be caused by cultural barriers and lack of language skills [39]. Some researchers consider lack of language skills as a further risk to effective coordination across GSD projects[4][1].

The relation between cause-risk-effect is shown in Figure 3.

Error: Reference source not found

Figure 3: Relationship between cause, risk and effect.

Risk Name 1 Lack of trust[42][36]Explanation Trust is required between team members at

different sites in order for them to work well together. Staff needs to have the belief that other teams are operating with a shared objective [42].

Causes Infrequent communication between team members[42][36]

Lack of face-to-face meeting[36] Poor socialization[36] Lack of willingness to collaborate

between team members[42] Increased monitoring[36] No conflict handling[36] Lack of predictability in

communication[36]Effects Reduction in the productivity and

quality[42][36] Reduction in feedback [36]

Risk Name 2 Lack of proximity [42][1]Explanation Personal contact is required between team

members or project managers in order to coordinate with other team members and ensure shared goals. In a distributed project, lack of personal contact and face-to-face meetings can cause coordination breakdown[42]

To build mutual understandings between partners in software project then closeness may be required [1].

Causes Coordination breakdown[42] Distance between team members[42] Missing feedback[42] Lack of communication[38] Lack of language skills [1]

Effects Increase cost for traveling between sites[42]

Time delay[1]

Risk Name 3 Unclear task allocation[34]Explanation In software development life cycle, the

interdependence tasks are require the efficient coordination between different teams [34]

Causes Lack of experience on task allocation [34]Effects Less team performance[34]

Risk Name 4 Lack of experience[42][27]Explanation If project managers have no experience in

managing GSD projects then this may lead to problems like managing team members and loosing control on the project [42].

Causes Less feedback [42]Effects Reduce team performance [42]

Risk Name 5 Distance [39][25][10]Explanation In GSD projects, team members work at

different sites and different location with ineffective communication tools causes the problems in coordinating the work activities[25].

Causes Lacking face-to-face meeting [42] [25]

Miscommunication [25]Effects Too little feedback [42][39]

Reduce the spontaneous interaction between team members [25]

Risk Name 6 Poor communication [39]Explanation When team members work on common

goals at different sites in the project, there is a requirement for frequent communication and feedback in order to achieve the project objectives [39].

Causes(fame work supplier)

Distance between team members [39]Linguistic differences [39]Poor cultural fit [39]

Effects Time delay [39]Late project delivery[39]

Risk Name 7 Lack of language skills [4][39][40]Explanation Team members work from different culture

backgrounds and language differences. This may cause poor communication

Causes Poor communication [39]Linguistic differences [39]

Effects Time delay [39]Late project delivery [39]Quality problems [4]

Risk Name 8 Disparities of work practices[42][40][10]Explanation Team members not working according to

defined process which, leads to time delay and failure of the project[42]

Causes Misunderstandings between team members [42]

Effects Reduction in team performance [42]

Risk Name 9 Terminology differences [1][40]Explanation Team members from different background

culture and languages leads to misunderstanding the requirements by different terminology [1]

Causes Lack of language skills [1]Effects Time delay [1]

Risk Name 10 Cultural differences [4]Explanation Team members from different culture

background to accomplish the overall project objectives and common goals , coordinate on work activities [1]

Causes Misunderstandings between team members [1]

Effects Time delay [1]

Risk Name (darja smite framework) 11 Lack of team spiritExplanation In GSD projects, team members encourage

each other and work on shared goals. Team spirit is required for team members to work effectively with other teams.

Causes Lack of understanding of the common goals [39]Importance for individual goals [39]Misunderstanding between teams [39]

Effects Time delay[39]

Risk Name 12 Time zone differences [38]Explanation When the distributed teams operate across

multiple time zones with reduced opportunity for synchronous communication regarding common goals [53]

Causes Miscommunication [38][35]Reduced the spontaneous interaction [53][35]

Effects Rework [38]Increased coordination costs [53]Difficult to resolve the unclear messages [53]

Risk Name 13 Lack of group awareness [49][37]Explanation Team members should know what other

people are doing within the project and should know how they are progressing against project deliverables.

Causes Coordination breakdown [49]Effects Time delay [39]

Risk Name 14 Unclear requirements or poor requirement management [1][40]

Explanation Lack of agreed understanding about what

the work tasks are. Lack of leadership pertaining to the management of the requirements.

Causes Misunderstandings between team members [1]

Effects Time delay [1]

Risk Name 15 Poor communication bandwidth[4]Explanation Team members across multiple sites need

effective communication channels, with good quality transmission and tools to coordinate the work activities between them [4][39][37].

Causes Lack of tool support [37]Effects Rework [39]

Time delay [39]

Risk Name 16 Lack of tool support [37]Explanation In GSD projects, distributed teams depend

upon more effective communication tools to accomplish the task [37]. If these tools are not supported and maintained the ability of the teams to collaborate will be impacted.

Causes Insufficient communication [37]Effects Time delay [37]

Reduced team performance [37]

Risk Name 17 Lack of common goals [39]Explanation In GSD projects, team members work on

shared goals and frequent communication is required to achieve the project objectives within project time [39]

Causes Misunderstandings between team members.Importance to individual goals than shared goals [39]

Effects Time delay [39]Requirement for rework [39]

Risk name 18 Lack of synchronous communication[39]Explanation If team members from different sites and

time zones are required to collaborate then they require frequent and synchronous communication [39].

Causes Lack of tool support [37]Time zone difference [39]

Effects Time delay [39]Late project delivery [39]

Risk name 19 Lack of willingness [37][39]Explanation Team members need to be willing to

operate in a team environment, often with people they have never met, across different sites. Without a willingness to participate in such a work environment the likelihood of effective collaboration occurring is slim.

Causes Lack of trust [39][36]No mutual understanding between team members [39]

Effects Time delay [39]

Risk name 20 Lack of domain knowledge [4]Explanation Teams need to have the knowledge needed

to address the project tasks and understand the shared goals.

Causes Lack of expertise [4]Effects Time delay [39][4]

Late project delivery [4]Decrease the quality [4]

Risk name 21 Task dependencies[4]Explanation Tasks within a project will be interrelated.

GSD teams need to understand how the tasks they complete are related to those in operation on a different site and need to openly communicate their progress on these tasks.

Causes Lack of experience [4]Effects Time delay [4]

As a result, 21 coordination risks across GSD projects were identified through the literature review.

1.2. Case studies overview1.14. Participants

22 interviews were conducted with 10 project managers, 1 consultant and 1 software developer at seven different software organizations, all of which were involved in GSD projects. Software organizations included in this study are located in USA, Netherlands, Denmark, Sweden, England, Germany, India and Pakistan. Semi structured interviews were conducted both face to face and/or through the use of VOIP software, depending upon availability and distance. All interviews from participants of Sweden, Denmark and Netherlands conducted face-to-face interviews. Interviews were also conducted with six suppliers, four customer and two sub-contractors.

2.1.10 Organization 1: TCS Company, NetherlandsTCS Company is an IT consultancy service that operates in a global market. The

interviewee works at the office in Eindhoven, The Netherlands. The company holds CMMI 5 certificate. One of the researchers observed audit reports and requirement specifications. He also participated in direct observation of the work environment and informal communication with employees in TCS Company.

Project Manager: Has been working as a project manager in TCS Company since 2003. Prior to this he has 13 years experience in a global software development company. His interview was used to collect data on the product lifecycle management project.

Interview Approach: One of the researchers conducted two face-to-face interviews with the project manger, each consisting of approximately 1 hr. After analysis of the interview data, additional questions were answered through emails.

Project Detail:

Collaboration mode Inter-organizationNumber of sites 3Perspective SupplierReason for outsourcing Cost, Extra peopleSoftware development methodology On-site offshore Business ModelApplication domain Product life cycle management for semi-

conductor industryTable 6: TCS Company Project Detail

On-site offshore business model means application development process between TCS onshore team members, TCS offshore team members and customer team members.

Error: Reference source not found

2.1.11 Organization 2: Mermaid Technology, Denmark Mermaid Technology Company specializes in digital signage systems. The company

has been involved in global software development for the last 6 years. It is a Danish based company. Data was collected from both sites with project managers in this company.

Project Manager, Denmark: Operates in this company as a project manager. He has 3 years experience in project management.

Interview approach: F2F interviews were conducted, each lasting approximately 1 hr. In addition to this, one of the researchers conducted a supplementary interview by telephone. This lasted about 25 minutes.

Project Manager, Pakistan: 4 years work experience in GSD Projects as a project manager.

Interview approach: Interview questionnaires were sent through email before conducting interview via Skype. There were three interviews of about 30 to 45 minutes that were conducted on different days of availability of the project manager. Emails were exchanged to establish the availability days for conducting interviews with him.

Project Detail:

Collaboration mode Inter-organizationNumber of sites 2Perspective Supplier & CustomerReason for outsourcing Cost, Extra peopleSoftware development methodology Scrum methodology in Offshore

DevelopmentApplication domain Digital Signage System.

Table 7: Mermaid Technology Company Project Detail.

Error: Reference source not found

2.1.12 Organization 3: Sequel System, USASequel Systems is a leading healthcare solution provider and medical software

vendor that offers integrated EHR, EMR software, Physicians, Practice Management, Medical Billing, Hospital Systems and PHR solutions. They have been in operation since 1995. One of the researchers involved in this report has been working within Sequel Systems for over 4 years and has been involved in the development of the product at their Pakistan office. During this time he was able to observe the coordination mechanism of the organization and was also able to participate and observe the challenges that offshore offices face during coordination with a head office that is based in the USA, especially when end customer/clients face some difficulties in installation/ deployment of application during their working hours. As a developer, one of the researchers involved in this report was responsible for coordination with USA office, often during out of hour’s times. The agreement that communications may need to take place at unsocial hours in order to aid the delivery of objectives across the sites was mutual and calls would often be made between Pakistan and the USA in the middle of each respective location’s nights.

CEO& Project Manager, USA: Has more than 15 years work experience in GSD environment as project manager.

Interview Approach: One interview was conducted with the help of VoIP through cell phone. The meeting lasted about half an hour.

Project Manager, Pakistan: He has involved in global software development past 6 years. Currently, he is working on sequel MED EMR project.

Interview Approach: We sent an interview questionnaire through Gmail to him before conducting interview. An interview lasting approximately one hour was conducted through gtalk. A further 25-minute interview was conducted to address additional questions that had arisen as a result of the analysis of data.

Project Detail:

Collaboration mode Inter-organizationNumber of sites 3Perspective Supplier & CustomerReason for outsourcing Extra KnowledgeSoftware development methodology Spiral ModelApplication domain Flexible baggage tracking and management

solutions to airports and airlines.Table 8: Sequel System Company Project Detail

Error: Reference source not found

2.1.13 Organization 4: Quantum Aviation Company, UKQuantum Aviation Solutions Company was established in 2005. They provide

baggage tracking and management solutions to airlines. Currently, they are working on Bag Suite software for airlines and airports. Main information and detail about project get from UK site.

Project Manager USA: CEO of Quantum Aviation is responsible for getting the requirements from customers, including change requests. Customer support department is also working under his supervision. After analyzing the change requests he forwards these to the UK office, where another project manager deals with the change requests.

Interview approach: A half hour interview was conducted by telephone. This was deemed to be sufficient because the UK Project Manager was the individual who had more experience of gathering functional requirements.

Project Manager UK: Project manager with more than 18 years experience in the airline industry. This individual is responsible for managing the development process. If he feels that, there is ambiguity in change requirements then he is required to visit the customer site.

Interview approach: A one-hour interview was conducted through the VoIP application to his office phone number. A questionnaire was sent to him prior to the interview.

Project Detail:

Collaboration mode Inter-organizationNumber of sites 3Perspective Supplier & Customer

Reason for outsourcing Extra KnowledgeSoftware development methodology Spiral ModelApplication domain Flexible baggage tracking and management

solutions to airports and airlines.Table 9: Quantum Aviation company project Detail

Error: Reference source not found

2.1.14 Organization 5: Teradata Company

Teradata is the world largest company in the field of data warehousing, they provide custom built solutions through their high quality platform for industry. The company has around 6000 employees across 60 countries. Teradata has quite a different organization structure for GSD when compared with the other companies that were studied. In each country, Teradata deals with local projects and provides the services including installation of hardware. However, Teradata has very different departments who deal with Global projects. These are known as TeradataGSE. When other departments require services from TeradataGSE, they pay for their services just as they may do if the work was outsourced to a different company. Currently, Teradata has three GSE departments; Pakistan, India and a newly established office in the Czech republic.

Project manager: The project manager is responsible for coordinating with the UK site and managing the development in Pakistan. The current project is research based and commenced 3 years ago. The nature of project is new for everyone but the project manager has more than 7 years experience in GSD, including 2 years experience in another company.

Interview Approach: The researchers conducted three interviews through Skype. Due to project complexity, we conducted two interviews for one hour each and a further supplementary interview of approximately half an hour was held in order to address outstanding questions that had arisen after data analysis.

Consultant: Born in Pakistan and has a secondary level education from his home country. The consultant achieved higher education from UK, did doctorate in the field of oil and gas, and has good technical knowledge. He acts as the key person on the current project as a result of his knowledge of the UK culture and his ability to coordinate with customers (British Petroleum) and other consultants from the University of Manchester. He is responsible for all requirements and acts as bridge between customers and developer. His knowledge about domain, along with his knowledge of culture and working environment within customer and supplier countries allows him to better coordinate activities across remote sites.

Interview Approach: One interview of 45 minutes was conducted via telephone.

Project Detail:

Collaboration mode UnclearNumber of sites 4Perspective Supplier & CustomerReason for outsourcing Cost

Software development methodology Spiral ModelApplication domain British oil Industry

Table 10: Teradata Company Project Detail

Error: Reference source not found

NOTE. Both are Teradata but remote site treat as other software organization.

2.1.15 Organization 6: Infomist Company, Pakistan.Infomist offer E-commerce solutions. The company provides different kinds of

solutions, including cloning and web portals. Most of the company projects are short-term in duration and last between one and two months. Infomist have experience in every major sector including—but not limited to—Real Estate, Health, Travel and Accommodation, Medicine, Hospitals, Doctors, Dentists, Car Financing, Shipping, Entertainment.

Project Manger: CEO of this company has responsibility as project manager as well. Site in Ireland is also under the control of this project manager. He is responsible for assigning module to Sweden site or Ireland site.

Interview Approach: Two interviews were conducted through Skype. One interview Infomist: One main interview conducted duration of one hour. Questions that arose from data analysis demanded a further 20 min minute interview. Both interviews were conducted through VoIP (Net to phone application).

Developers: Company allows its developer to get higher education from Sweden. They live in Sweden for approximately two years. Developers are paid as they would be if they were operating in Pakistan and this allows the company access to European support at a lower cost. The majority of the projects in existence within the company are based in the USA or the EU. The developers based in Sweden can easily establish direct communicate with clients and implement the change requirements. This working environment leads to concept of On-Site offshore development.

Interview approach: Two face-to-face interviews were conducted, each lasting approximately 45 minutes.

Project Detail:

Collaboration mode UnclearNumber of sites 3Perspective Supplier & sub-contractorReason for outsourcing CostSoftware development methodology Agile Application domain E-Commerce solutions

Table 10: Infomist Company Project Detail

Error: Reference source not found

2.1.16 Organization 7: Acrologics Pvt.Ltd USA, Germany, PakistanAcrologics (Pvt.) Ltd, Pakistan, is an ISO 9001:2000 certified IT organization that

was established in June 2000. They have highly experienced computer professionals. Acrologics supports its clients in a broad range of products and development services in order to help them create intelligent e-business solutions.

Project Manager : Project Manger has about 5 years of experience in different countries and has good knowledge about cultural differences, along with the needs of customers in different countries. He is currently operating in a market driven project in which one consultant from customer site is also involved in the explanation of the requirements.

Interview Approach: Acrologics is working as sub-contractor and the manager is responsible for development only. Only one interview was conducted and this lasted approximately one and a half hours through phone call. An interview questionnaire was mailed prior to the phone call.

Project Detail:

Collaboration mode Intera-organizationNumber of sites 3Perspective Sub-contractorReason for outsourcing Cost, extra peopleSoftware development methodology Not ClearApplication domain ------------------

Table 11: Acrologics Pvt.Ltd Company Project Detail

Error: Reference source not found

1.15. Summary Error: Reference source not found

Figure 4: Summary of empirical study overview

This chapter briefly provided an overview of the outputs of the case studies about participant software organizations.

1.3. ResultsThis chapter explains the results from our literature review and case studies.

1.16. Results of grounded theory Open coding is first phase in the data analysis. Interview text was reviewed “word –by-

word and line-by-line” to identify the coordination risks in GSD projects and related practices. The interview text labeled with proper instances or keywords.

Note: The researchers found some similar codes like Videoconferences; videoconferences meeting made into general code videoconferences.

The researchers made general codes like instant message tool, teleconference and videoconferences into synchronous communication general concepts. Interconnections were made between existing categories and these concepts [39].

Axial coding was used for deriving the relationship among the existing categories and risks management concepts [39]. Relations between risks and practices were discovered from the existing categories like risk factors, threats (causes of risks), consequences (effects of risks) and practices (recommendations for risk treatment) [39]. An example showing the relationship between risks and practices for GT is shown below. The main core category is risks management for the purpose of the research study.

Interview texts were reviewed three times in order to remove unclear statements in the transcripts. Selective coding was applied in order to consistently validate relationships and populate categories. Grounded theorizing resulted into 22 risks and 27 practices.

Example for GT:

Interview Transcript

Interview Text Codes(keywords)

1 Videoconference tools are used to overcome lack of face-to-face contact and language issue.

Video conference tools

Instant message tool

teleconference

Video confereces

Synchronous communication

2 Instant message tools are used as communication tools to reduce the time delay and language problem.

Instant message tools

Table 11: Example for GT

From interview text, codes address “language skill” risk. Videoconference and Instant message tools were used to alleviate the language skill risk. In the next step, these two codes were combined into synchronous communication concept. Synchronous communication and similar concepts were then grouped into a more general category of “Practices”. Further, “language skill” grouped with other coordination risks and their consequences, were put into a more general category of “risks”. The relationship between “Synchronous communication practice” and “language skill risk”, resulted in the “Use synchronous communication tools among distributed team members to reduce language barrier” recommendation.

Note: All practices obtained by participant software organizations and industrial study from literature review. The researchers found one risk during the data analysis and this is explained in section 4.2.

1.17. Risk During data analysis the research team identified a further risk that had not been found during

the literature review.

Risk Name Unclear documentationExplanation When change requirement not update into

master documentationCauses Lack of language skills

Lack of experience Effects Time delay

Rework Late project delivery

As a result, 21 risks were identified from literature review and 1 risk from semi-structured interviews, totaling 22 risks.

1.18. Finding of risks in all case studies projectThe table below shows the risks that were identified tracked across the project case studies.

Risk Name TCS Project

Mermaid Project

Sequel project

Quantum aviation project

Teradata project

Infomist project

Acrologics project

Lack of trust - - - - - - √Lack of proximity

- - √ - - √

Unclear task - - - - - √ √

allocationLack of experience

- - - - - √ -

Distances √ √ √ √ √ √ √Poor communication

- - √ - - √ √

Lack of language skills

- √ - - - - -

Inconsistent work practices

- - - - - √ √

Terminology difference

- - √ - - - -

Cultural difference

√ - - - - - -

Lack of team spirit

- - - - - - √

Time zone difference

√ √ √ √ √ √ -

Lack of group awareness

- - - - - √ √

Unclear requirements

√ - - - - √ √

Poor communication bandwidth

√ - - - - - -

Lack of tool support

- √ - - - √ √

Lack of common goals

- - - - - - √

Lack of synchronous communication

- - √ - - √ √

Lack of willingness

- - - - - - -

Lack of domain knowledge

- - - - - - √

Task dependencies

- √ - - √ √ -

Unclear documentation

√ √ - - - √ √

Table 12: Risks identified through research

The findings reveal that time zone differences and distances are major factors that affect coordination across GSD projects. Many researchers also mentioned distance and time

separation as being major problems in GSD [25][6]. In our findings, we do not find the lack of willingness risk but some researchers mentioned lack of willingness is also coordination problem in the GSD projects [39].

1.19. Recommendations 1. “Create a team charter and operating procedure which outlines responsibility for all

areas of the project and communication mechanisms that are to be employed across the teams to optimize coordination”.

Explanation:Time zone differences were an issue across all projects studied during the case study except one. In order to overcome the issues associated with operating across different time zones project teams need to be fully aware of who is responsible for what during the duration of the project. This should include times and methods of passing forward information and communicating progress. The operating procedure should include details of when updates are expected and what forms these updates should take. It should also include details of how and when team members in a different time zone can be contacted in the event of a series issue.Motivation: Through agreeing roles up front team members will be fully aware of what is expected of them and how the work they perform fits in with the rest of the team. This will prevent the risks associated with unclear requirements.

2. “Utilize requirement engineers who have excellent proficiency in both English and native language”

Explanation: The requirement engineers perform a vital role during the project and it is essential that requirements are adequately documented and understood by all teams involved in the GSD. Requirement engineers, in order to communicate with customers and elicit detailed specification of the requirements, often perform multiple interpretations. All the information related to requirements, these requirement engineers communicate design, code and testing. The success of the project depends on the success of communicating requirements. TCS project manager-“ we hire some local Dutch employees( who are excellent in both Dutch and English communication skills) to communicate with customers in all phase of software development”Motivation: The utilization of recruitment engineers with language competency will maximize the potential for requirements to be clearly understood and communicated. This will assist the prevention of problems across all three categories; unclear documentation, unclear requirements, communication barriers.

3. “Keep team size to a minimum”

Explanation : The more people that are involved in a GSD, the harder it will be to manage the entire process and remain in control of the tasks, dependencies and outputs. Where possible, team members should be kept to the minimum required to adequately complete the tasks to the required level of quality. Managers should avoid the temptation to throw vast amounts of resource at a project as this may cause further issues and complicate the

communication structures that are in place.Motivation: Smaller teams are easier to coordinate as less people are involved. This recommendation will assist to prevent risks associated with communication barriers.

4. “Try to change the coordinating mechanisms according to the project needs”

Explanation: There is no “one size fits all” method of coordinating the work across GSD teams. The way in which the work is to be coordinated should form an important basis of the project plan and the operational plans put in place should be tailored to fit the teams involves and the nature of the tasks that they will be completing.Motivation: Requirements and plans will fit the team and the organizational structure. This will help to prevent problems with unclear requirements.

5. “Use online bug fixing tracking tools”

Explanation: An online bug-tracking tool should be used for online user interface issues. If any staff from head office identifies a bug in the project then details of this should be uploaded into the tool. The offshore team members will check and remove that bug and report to the head office through this tool. Without using this application tracking of bugs becomes difficult and as a result of heavy work load developers often forget to resolve these bugs. In addition to this, they sometimes introduce new bugs during the process of fixing the old bugs.. Online bug tracking tools like Test Director, Fog Bugz and AceProject tool etc.Motivation: These online tools give a lot of help for resolving such problems and promote open communication between the team members. They will assist to remove communication barriers.

6. “Liaisons (software engineers) visits from one site to another site”

Explanation: This practice can reduce the cultural barriers and lack of trust between two distributed team members at different sites. This will prevent many issues, such as delayed response to communication requests, and perceived ability. Motivation: More trust will reduce the risk of coordination between sites and the officer can assist to ensure that the work is coordinated in the most efficient manner possible. This will help to remove communication barriers.

7. “Formal agreement of requirements”

Explanation: Problems understanding the requirements often arise when customers explain their needs through voice or video communication to supplier. These can cause conflicts at a later date. When suppliers translate requirements into written documents the customer has an opportunity to review them and the two parties can formally agree on what the requirements are. If the customer is asked to sign up to the transcribed requirements then there will be less possibility of conflicts occurring at a later date. This is highly recommended for outsourcing organizations.Motivation: Requirements will be agreed and clear. This will prevent problems with unclear requirements.

8. “Create a project coordinator role”

Explanation: Each site must have one project coordinator that communicates frequently with other site representative. Each project needs proper coordination between team members. In GSD projects, when each member of project cannot meet with each other, then at least one coordinator who possesses good communication skills, both oral and written, is required.Motivation: Creates environment of open communication and helps to remove communication barriers.

9. “Hold regular video conferences meetings with different site team members”

Explanation: Through the use of videoconference technology, employees can interact with different team members at different sites on the project. Motivation: Videoconference meetings are similar to Face–to-Face meetings and can improve coordination between different team members. This will help to remove communication barriers.

10. “Make sure that requirement team members collocated with customer”

Explanation: Requirement team members should have face-to-face kick off meetings with customer team members. If team members have a clear idea of the requirements then we can mitigate risks and prevent their occurrence in the next phases of the software development life cycle (SDLC).Motivation: This will create a direct line of communication and assist to prevent unclear requirements and remove communication barriers.

11. “Encourage frequent interaction between distributed team members”

Explanation: If team members frequently communicate with other site team members then all stakeholders know the status of the project and are aware of any issues. By this practice, team members can solve errors in the software with information of other team members by communication tools like synchronous and asynchronous tools.Motivation: Opens a communication line between project team members and helps to remove communication barriers.

12. “Produce clear and updated documentation for the requirements according to developer point of view”

Explanation: Unclear documentation can create many risks in the development phase between team members. Clear and updated documentation allows team members to more effectively coordinate and work on the common goals & objectives.Motivation: Creates clear documentation and prevents unclear requirements.

13. “Developers and team leaders review Software Architecture”

Explanation: If any changes in the architecture occur then developers and team leaders should review and clearly document these. By this practice, reductions can be made in the coordination effort and cost, time delay and complexity of the project. It is highly recommended to global distributed projects and this practice is used to alleviate the architectural change risk.

Motivation: Changes to requirements will be agreed up front and documented. This will assist to remove risks across all areas. It will prevent unclear documentation, ensure requirements are clear and understood and will remove communication barriers.

14. “Select team members who have domain knowledge in the project”

Explanation: Team members should have domain knowledge in the project. This is highly recommended for the project manager because team members work and coordinate with other teams on the same domain. Lack of domain knowledge will induce the risks in the project.Motivation: If team members have domain knowledge then they easily coordinate with other team members at different site. This will remove communication barriers.

15. “Select team members who have previous experience in GSD projects”

Explanation: There is no substitute for experience. The organization should select experienced people who have knowledge about the other site development model, culture, language and organization settings. Inexperienced team members should work under experienced people to get familiar with GSD challenges.Motivation: People with knowledge will be better placed to deal with the challenges associated with multiple site environments.

16. “Team members should be skilled and trained in the technology like software and hardware”

Explanation: Team members should have an appropriate knowledge of the technology. If one team member has lack of technology knowledge then other team members must coordinate with him in order to solve any issues in the project that could potentially increase the coordination cost and delay time.Motivation: People with appropriate skills will be better placed to deal with the challenges associated with multiple site environments.

17. “Make architecture design at one site and documentation should written by considering the developer perspective”

Explanation: In a GSD environment requirements are often documented at one site, while a different site actually produces the coding. The terminology and language of the developer should be considered when producing design documents and proactively consulting with the developer can reduce the risk of rework at both ends. Motivation: Creates clear documentation and prevents unclear requirements.

18. “Use synchronous communication tools among distributed team members”

Explanation: The major problem in distributed teams is lack of social awareness. By using synchronous communication tools like instant messenger, video conferencing and shared documents we can create social awareness between team members. Team members coordinate with other team members to ramp the work fast. Motivation: This will help distributed teams to overcome the problem of face-to-face communication and will remove communication barriers.

19. “Arrange initial face-to-face kick off meeting”

Explanation: Virtual Team cohesiveness is very important for coordination over various communication mediums. When there is no informal communication over communication medium then an initial face-to face meeting should take place between the projects manager and coordinator of both sides. Motivation: This will establish a relationship and help to overcome coordination related issues.

20. “Arrange regular meetings with remote team members by video conference”

Explanation: Team members should be provided with an opportunity to coordinate with remote colleagues by videoconference meeting and update the progress of the software project. By this practice, team members exchange the information regarding project like issues, status and risk etc.Motivation: This will establish a relationship and help to overcome communication barriers

21. “Use telephone communication and instant messenger for communication purposes where possible”

Explanation: Email can often delay the progress of work between team members. Project managers should encourage team members to use telephone and instant messenger for communication purposes. Through using this practice any misunderstandings or questions can be immediately qualified.Motivation: Communication barriers will be reduced and assumptions about requirements may be avoided.

22. “Where possible, make sure that no more than two distributed sites are involved for one project”

Explanation: It is highly recommended to software organizations that they minimize the number of sites involved in a project. The more sites that are working on the project the higher the potential for lack of domain knowledge, risks and more coordination efforts. Two sites are enough to develop the software project through a global approach.Motivation: Simplify communications.

23. “Ensure customers communicate with the development team”

Explanation: Development team members who work geographical distance on the project. If development team and customer coordinate directly then this can potentially reduce delay time and coordination effort in the project. The communication between developer and customer enhance the quality of the product.Motivation: Changes to requirements will be agreed up front and documented. This will assist to remove risks across all areas. It will prevent unclear documentation, ensure requirements are clear and understood and will remove communication barriers.

24. “Ensure team members work on one project at one time”

Explanation: Where possible, team members should be dedicated to one project. This simplifies the approach and prevents confusion and mistakes from occurring. Working on more than one project can lead to delay and reduction in quality of work. Doing different projects parallel by one team can affect the overall quality of work. Motivation: By focusing on one project team members can operate in a clear manner and be fully aware of what is expected of them. This will ensure requirements are clear and understood.

25. “Generate a prototype for the completed project and ensure this is validated by the customer”

Explanation: Through this practice, team members will have a detailed prototype that can be used as a basis for the project deliverables. Motivation: The team will be aware of what they are expected to deliver and this will remove the requirement for continual validation to occur between the project team and the customer.

26. “Ensure all sites use same tools for configuration management and change management”

Explanation: In order to collaborate effectively teams need to be using the same configuration tools. Motivation: Through using the same tools on each site teams will have continuity and can reduce the opportunity for misunderstanding and help for increasing the coordination.

27. “Try to keep low task dependencies among teams”

Explanation: Where possible task dependencies across GSD projects should be kept to a minimum. Teams should be planned in such a way that small teams operate on end-to-end tasks that are not dependent upon the work of other teams. The various disparate elements can then be placed together at a later stage in the project by one team who has the responsibility for making them all work together.Motivation: Issues pertaining to coordination will be removed as less coordination will be required.

1.4. Discussion This paper has explained the effect of coordination depending upon no of sites by

observing seven case studies. Three issues have emerged from the semi-structured interviews and literature review; unclear documentation, unclear requirements and communication barriers. These are believed to negatively impact the success of the coordination between GSD teams.

In order to address the fifth research question, these three factors have been assessed in accordance with the number of sites that each of the case study companies operated across

Table 12: major factors, sites and Impact of coordination

F1: unclear documentation, F2: unclear requirements, F3: communication barrier and/or ineffective communication tools, N: no, Y: yes, N/A: not applicable, NS: Number of Sites and GDS: Globally Distributed Sites and TD: time zone difference.

Some organizations have minor problems with these factors. However, if it was deemed that the impact of them was not of serious consequence to the project objectives than an “N”, for no, was recorded. On the contrary, if it was deemed to be an issue then a “Y”, for yes, was recorded. If no information relevant to the issue was revealed during the course of the interviews then an “N/A”, for none applicable, was recorded.

Distributed Sites and TD: time zone difference.

TCS Company has problems with documentation and they often fail to update the master documentation when the requirements changes are there. This causes problems for the teams involved in the project.

Organization

Sites TD Customer Supplier Sub-contractorNS GDS F1 F2 F3 F1 F2 F3 F1 F2 F3

TCS 3 2 4 ½ N/A

N/A

N/A

Y N N N/A

N/A

N/A

Sequel 3 2 13 N Y Y Y Y Y N/A

N/A

N/A

Mermaid 2 2 4 N N Y Y Y Y N/A

N/A

N/A

Acrologics

3 3 4*,9**

N/A

N/A

N/A

N/A

N/A

N/A

Y Y Y

Teradata 4 2 5 N N N N N N N/A

N/A

N/A

Infomist 3 3 13*,9*,4**

N/A

N/A

N/A

Y Y Y Y Y N

Quantum 2 2 8 N Y N N Y N N/A

N/A

N/A

Sequel has problems due to the fact that the time zones involved in the projects provide very little overlap time during office hours during which the customer and the supplier can hold discussions.

Teradata Company has well planned projects. They have trained employees on domain knowledge. They do not appear to face the same issues that other project teams endure.

Acrologics Company has all factors because they do not have direct contact or coordination with customer.

Infomist company case, sub-contractor has no communication barriers. They have direct contact with customer and time differences between customer and sub-contractor is four hrs, leaving sufficient time for communication to take place.

Mermaid Company follows agile methodology due to time zone differences may some coordination risks and they follow scrum rule which they don’t have more than two globally distributed sites.

Quantum have only requirements because near 25 airlines customers with different countries.

Error: Reference source not found

Figure 5: Impact of coordination with respect to number of sub-contractors and sites

: Coordination between them

: No coordination between them

We observed that the coordination complexity of the project did depend upon the no of sites, no of distributed sites globally and no of sub-contractors involved in the project. Figure 5 shows that more coordination effort is required when the no of sites and sub-contractors increases. In figure 7, coordination effort increases when the no of sub-contractors or sites increase. For example, organization 7 assessed during the case study is a case in point. This organization had a USA based customer who sent their requirements to a German based company. The German based company had a further subcontractor in Pakistan. During the development of the project, when the Pakistan based company was required to provide an explanation related to part of the development, they made contact with the central company instead of ultimate customer. This long chain of coordination has a negative impact on the overall project.

Error: Reference source not found

Figure 6: Impact of coordination among customer, supplier and sub-contractors

: Coordination between them

: No coordination between them

In most of the case studies conducted, the software organizations do not have a sub-contractor and do not have more than two distributed sites. The analysis used to respond to the fifth research question has found that some other factors should take into account like sub-contractors, no of distributed sites, team size and no direct coordination between sites. One major factor should take into account time-zone difference.

Table 13, maps the set of recommendations against the potential risks.

Risk Name Set of Recommendations TotalLack of Trust 1, 3, 5, 6, 7, 8, 9, 11, 12, 18, 19,

2112

Lack of proximity 1, 3, 5, 6, 7, 8, 9, 11, 12, 13, 17, 18, 19, 20, 21, 23, 25, 26, 27

19

Unclear task allocation 1, 2, 4, 7, 10, 12, 19, 25, 26 9Lack of experience 14, 15 2Distance 1, 3, 5, 6, 7, 8, 9, 11, 12, 13, 17,

18, 19, 20, 21, 23, 25, 26, 2719

Poor communication 1, 3, 5, 6, 7, 8, 9, 11, 12, 13, 17, 18, 19, 20, 21, 23, 25, 26, 27

19

Lack of language skills 6, 8, 12, 17, 25 5Disparities of work practices 1, 4, 7, 8, 12, 17, 22, 27 8Terminology difference 2, 4, 6, 7, 12, 17, 21, 25 8Cultural difference 1, 4, 7, 8, 12, 17, 22, 27 8Lack of team spirit 1, 3, 6, 8, 11, 19, 20, 21, 22 9Time zone difference 1, 3, 5, 6, 7, 8, 9, 11, 12, 13, 17,

18, 19, 20, 21, 23, 25, 26, 2719

Lack of group awareness 1, 3, 5, 6, 7, 8, 9, 11, 12, 13, 17, 18, 19, 20, 21, 23, 25, 26, 27

19

Unclear requirements 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 16, 18, 19, 20, 21, 23, 25, 26

21

Poor communication bandwidth

1, 3, 5, 6, 7, 8, 9, 11, 12, 13, 17, 18, 19, 20, 21, 23, 25, 26, 27

21

Lack of tool support 26 1Lack of common goals 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12,

13, 14, 16, 18, 19, 20, 21, 23, 25, 26

21

Lack of synchronous communication

1, 3, 5, 6, 7, 8, 9, 11, 12, 13, 17, 18, 19, 20, 21, 23, 25, 26, 27

19

Lack of willingness 1, 3, 6, 8, 11, 19, 20, 21, 22 9Lack of domain knowledge 14, 15, 16 3

Task dependencies 22 1Unclear documentation 1, 2, 5, 7, 12, 25 6

Supplier companies rely on local employees rather than remote site employees to reduce the language barrier.

1.5. Validity Threats Validity threats means to identify all risk factors, which can affect the reliability of

research results. There are four types of validity threats: Internal validity, External validity, Construct validity threat and Conclusion validity threat [47]. For this kind of qualitative study, we will discuss internal and external validity threats. In the following sub section, we will describe the activities for mitigating and avoiding each threat in this study.

1.20. Internal ValidityThis thesis work is exploratory in nature, so there is no strong emphasis on causal

relationship in order to study constructs. Internal validity can be explained as the extent to which the exploration contained within the study represents a causal relationship of independent and dependent variable [43] [19] [47]. Internal validity is a causal relationship of cause and effects [47]. Therefore, internal validity is used to ensure that we conclude the valid results based on collected data.

Interviews were transcribed immediately following the meetings thus reducing the chance of information being forgotten. Transcripts were distributed to the interviewees, who were asked to check and confirm the content. English was the main language used during the interviews. Taking the answer in English reduce the risk of language ambiguity. Participants of this study use English as their business language. There was no threat regarding language.

2.1.17 Qualitative Validity ThreatsTriangulation is often used as a validation technique for qualitative studies [48]. This

kind of method is used to compare three or more types of independent view on a given research process in order to improve the findings. Data, investigator and methodological triangulations were used in this research study.

2.1.18 Data Triangulation:Where study results are based on the different sources of information/data, this is

called data triangulation. The data collected from various data sources having consistency would be considered as and used then the collected data is valid [48].

In this research study, the data was collected from project managers by semi-structured interviews. The plan was to interview all site project managers in each participating organization. Acrologics is only organization where supplier side coordination prospective is mentioned in this research work. In the remaining organizations, both supplier and customer side interviews were conducted in order to get a perspective of the coordination on current projects.

2.1.19 Methodological Triangulation: There are different methodological techniques used in quantitative or qualitative

studies. If the results from each method have consistency then the validity of the results will increase [48]. We used qualitative methods in literature review and semi-structured interviews from project managers.

2.1.20 Investigator Triangulation:

Investigator triangulation involves the participation of various researchers/investigators within the research process and accompanying work [48]. In every phase in the research study, such as data collection, data analysis and validation, processes were validated. The researchers reviewed each of their work and findings in the research process. Through this method, investigator triangulation was performed in the research study. Supervisor reviews were also conducted at all phases in the study in order to improve the validity of the findings.

The ecological validity threat was also taken into consider throughout the research work. Various software organization settings were accepted for participation like globally distributed team members, collocated team members, small or large software organizations, off shoring and outsourcing. As a result of this, the results are not generalized in various contexts since this study covers all kind of software organizations.

1.21. External ValidityExternal validity is defined as research finding for generalizing the results across time,

setting and population of persons [19].

Population validity: the study utilized various software organizations with different types of software projects in order to cover broader range of various aspects software organizations. Companies across Asia, Europe and the USA were studied.

Temporal validity: the research results were not generalized over time. Many new communication tools, approaches and technology will be introduced for team members to coordinate between them. The research results were not generalized over time.

2.2 Construct Validity

Construct validity concerns the extent to which the inferences made during the research can be considered appropriate to the concepts involved in the study. The study measured the risks associated with coordinating work across GSD projects and it is believed by the researchers that the labels utilized were accurate and appropriate to the context.

1.6. EPILOGUE

1.22. ConclusionDuring this research work, Coordination among global distributed team members in

GSD projects was analyzed. The research was primarily concerned with the ways in which risks across GSD projects during the project development could be mitigated. The research work was based on exploratory study, grounded theory and semi-structured interviews. The work was separated into four phases, which were as follows. In first step, the coordination risks in GSD projects were identified via a literature review. In second step, practices that can be used to overcome these coordination risks were identified through a further literature review. In third step, industrial practices that are applied in software organizations to overcome these coordination risks through project managers and team leaders were identified through the implementation of semi-structured interviews. In the final step, grounded theory was applied to analyze the collected data and conclude the research work.

The research revealed that there are 22 risks associated with coordinating teams across GSD projects. These risks can be grouped into three broad categories; unclear documentation, unclear requirements and communication barriers. In order to effectively collaborate teams across multiple sites, project managers need to ensure that all of these risks are managed. Recommendations for such management methods are made in this paper.

The research also established that the number of teams and groups involved in a project does impact the effectiveness of the collaboration that takes place across the teams and people who are involved in that project.

1.23. Answers to the Research Questions

It is useful to verify the research questions based on the output of this thesis work. Each question is addressed with the answers driven from the research work.

RQ1. What are the risks in coordinating GSD projects and their causes and effects? The research work identified 22 risks associated with GSD projects, these are detailed in section 2.6 together with their causes and effects. Further details of these are provided in 4.3, where their occurrence is tracked against the case studies utilized in the study.

RQ2. What are the best practices reported in the current research literature to alleviate the risks? Sections 2.3 and 2.5 describe some of the common theories pertaining to how coordination activities across GSD projects can be measured and any risk associated with them minimized.

RQ3. Which practices are currently applied in industry to overcome coordination risk in GSD projects?Section 3.1 details some of the issues that the project teams addressed in the case study have faced and the ways in which they have overcome them. Section 5 also briefly discusses differences between the companies studied during the research and how these have impacted their ability to run coordinated projects across multiple sites.

RQ4. Is there any way, or combination of recommendation that help to avoid the risks or mitigate the effect after they occur?Section 4.4 presents 27 recommendations for assisting project teams to avoid risks and mitigate their effect if they do occur. Table 13 maps these recommendations across the 22 risks identified through research question 1 and 2.

1.24. Future WorkCoordination is one of the key challenges facing teams that are attempting to collaborate

across GSD projects[4][42]. The results of this study were based on the outputs of semi-structured interviews and case studies that considered project teams that operated with minimum 4 hrs and maximum 13 hrs time zone differences between different sites. No language issues were in existence at any of the sites. Further studies may wish to conduct an empirical study on coordination risks analysis with near shoring companies, companies with less time zone differences and countries with more significant language barriers due to the fact that the business languages are different. To fulfill this study, it could be useful to conduct semi-structured interviews with different near shoring companies and provide a further set of recommendations to alleviate the coordination risks. There is high potential for coordination related problems where as English is not a main language of communication for GSD environment on both customer and supplier side for example, Japan, Germany, china and Russia.

Within the scope of this project, 22 risks were identified across 3 areas; unclear documentation, unclear requirement and communication barriers. The importance of these categories of risk in relation to one another was not addressed, i.e. which leads to the greatest negative impact on a GSD project, unclear documentation or communication barriers. This is also potentially a future area for study.

1.7. References:[1] Smite, D; “A Case Study: Coordination Practices in Global Software Development”, 2008, pp.234-244.

[2] D. Šmite, Claes Wohlin, Robert Feldt and Tony Gorschek,” Reporting Empirical Research in Global Software Engineering: a Classification Scheme”, IEEE International Conference on Global Software Engineering, 2008, pp no: 173-181.

[3] Holmstrom H., E.Ó. Conchúir, P. J Ågerfalk, and B. Fitzgerald, Global Software Development Challenges: A Case Study on Temporal, Geographical and Socio-Cultural Distance, in Proceedings of the ICGSE 2006 conference, published by IEEE, pp.3-11.

[4]. Matthew Bass, James D. Herbsleb and Christian Lescher, “A Coordination Risk Analysis Method for GSD Projects: Experience Report”, 2009 Fourth IEEE International Conference on Global Software Engineering.page no 31-40.

[5] J.D. Herbsleb, D.J. Paulish, M. Bass, Global softwaredevelopment at Siemens: Experience from nine projects. International Conference on Software Engineering (ICSE), St. Louis, MO, May 15-21, 2005, pp. 524-533.

[6] James D. Herbsleb, “Global Software Engineering: The Future of Socio-technical Coordination”, Future of Software Engineering (FOSE'07), 2007.

[7] James D. Herbsleb and Audris Mockus, “An Empirical Study of Speed and Communication in Globally Distributed Software Development”, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 6, JUNE 2003, pp no: 481-494.

[8] James D. Herbsleb and Audris Mockus, “Why Not Improve Coordination in Distributed Software Development by Stealing Good Ideas from Open Source?”, USA.

[9] H. Mintzberg, “Mintzberg on Management: Inside OurStrange World of Organizations”, the Free Press, New York1989.

[10] Emam Hossain, “Coordinating mechanisms for Agile Global Software Development”, IEEE International Conference on Global Software Engineering,2008.

[11] D. Barstow, “ Artificial Intelligence and Software Engineering, Proc. Ninth Int'l Conf. Software Eng ”, vol.9, no. 5, pp. 541-561, 1987.

[12 ] B. Curtis, H. Krasner, N. Iscoe, (1988), “A Field Study of the Software Design Process for Large Systems Communications of the ACM”, Vol. 31, Issue 11,November 1988, pp. 1268 – 1287.

[13] J.D. Herbsleb and R.E. Grinter, “ Architectures, Coordination, and Distance: Conway's Law and Beyond”, IEEE Software, Sept/Oct 1999, pp. 63-70.

[14] R.E. Kraut, L.A. Streeter, “ Coordination in Large Scale Software Development. Comm. ACM” , vol. 38, no. 7, pp. 69-81, 1995.

[15] S.D. Teasley, et al., “ Rapid Software Development through Team Collocation. IEEE Transactions on Software Engineering” , 28, 7 (2002), pp. 671-683.

[16] D. Šmite “Global Software Development Projects in One of the Biggest Companies in Latvia: Is Geographical Distribution a Problem”, In the SPIP journal, Wiley, 2006; Vol.11, pp.61-76.

[17] C. B. Seaman (1999); “Qualitative Methods in Empirical Studies of Software Engineering”, IEEE Transactions on Software Engineering, IEEE, 25(4), pp.557-572.

[18] Marcelo Cataldo, Matthew Bass, James D Herbsleb, Len Bass; “On Coordination Mechanisms in Global Software Development”, International Conference on Global Software Engineering, 2007.

[19] J.W. Creswell, “Research Design: Qualitative, Quantitative, and Mixed Methods Approaches”, Sage Publications, Inc; 2nd edition, 2002.

[20] Carmel, E; “Global software teams: collaborating across borders and time zones”, Prentice-Hall, 1999.

[21] SAHAY, S, “Global software alliances: the challenge of ‘standardization’. Scandinavian Journal of Information Systems”, Vol. 15,2003, pp. 3-21.

[22] DAMIAN, D ; “Workshop on Global Software Development”, In Proceedings of International Conference on Software Engineering (ICSE), Orlando, Florida, USA, May 19-25, 2002.

[22] D. L. Duarte; N. T. Snyder (2001); Mastering Virtual Teams: Strategies,Tools, and Techniques That Succeed, Second Edition, Jossey-Bass Inc.

[23] S. Jalali and B. Zlatkovic, “Success Factors in Building andMaintaining Trust Among Globally Distributed Team Members”, Master’s Thesis, BTH, Sweden,2009.

[24] SARKER, S., and SAHAY, S. (2004). Implications of space and time for distributed work: an interpretive study of US-Norwegian systems development teams, European Journal of Information Systems, 13, pp. 3-20.

[25] E. Carmel; R. Agarwal (2001); “Tactical Approaches for Alleviating Distance in Global Software Development”, IEEE Software, IEEE, 18(2), pp. 22-29.

[26] ÅGERFALK, P. J., FITZGERALD, B., HOLMSTRÖM,H., LINGS, B., LUNDELL, B., and Ó CONCHÚIR, E; “ A Framework for Considering Opportunities and Threats in Distributed Software Development ”, In Proceedings of the International Workshop on Distributed Software Development (DiSD 2005), Austrian Computer Society, 2005, pp. 47–61.

[27] SMITH, P.G., and BLANCK, E.L; “ From experience: leading dispersed teams”, The Journal of Product Innovation Management, Vol. 19, No. 4, 2002, pp. 294-304.

[28] J. D. Herbsleb; D. Moitra (2001), “Guest Editors' Introduction: Global Software Development”, IEEE Software, 18(2), pp. 16-20.

[29] S. Komi-Sirvio and M. Tihinen (2005); “Lessons Learned by Participants of Distributed Software Development”, Knowledge and Process Management, vol 12(2), Wiley InterScience, pp. 108-122.

[30] Salas, E., Sims, D. E. & Burke, C. S. (2005), “is there a "big five" in teamwork? Small Group Research", 36, 555-599.

[31] U. Sekaran (2003); “Research Methods for Business: A Skill Building Approach”, Fourth Edition, ISBN: 978-0-471-20366-7, Hardcover.

[32] Samaneh Barati and Shahriyar Mohammadi, “Enhancing Risk Management with an Efficient Risk Identification Approach”, 2008.

[33] P. Jarvinen (2001); On Research Methods, Opinpajan Kirja, Tampere.

[34] Chintan Amrit, “Coordination in Software Development: The problem of Task Allocation”, in proceedings Human and Social Factors of Software Engineering (HSSE) May 16, 2005, St. Louis, Missouri, USA.

[35] Emam Hossain, Muhammad Ali Babar, and June Verner, “How Can Agile Practices Minimize Global Software Development Co-ordination Risks?”, In procceding of 16th

European conference software process improvement, 2009, pp. 81-92.

[36] N. B. Moe; D. Šmite (2008); “Understanding a Lack of Trust in Global Software Teams: A Multiple-case Study”, Software Process Improvement and Practice, Wiley InterScience, pp. 217 231.

[37] Emam Hossain, Muhammad Ali Babar, Hye-young Paik and June Verner, “Risk Identification and Mitigation Processes for Using Scrum in Global Software Development: A Conceptual Framework”, In 16th Asia-Pacific Software Engineering Conference, 2009.

[38] Erran Carmel and J. Alberto Espinosa, “The effect of time separation on coordination costs in global software teams: A Dyad model”, In proceedings of the 37th Hawaii international conference on system sciences, 2004.

[39] Darja Šmite and Juris Borzovs, “A Framework for Overcoming Supplier Related: Threats in Global Projects”, in proceedings 13th European conference on software process improvement, vol. 4257, pp. 50-61 October, 2006.

[40] D. Šmite, Requirements Management in Distributed Projects”, In Proceedings of the Int. Workshop on Learning Software Organizations and Requirements Engineering (LSO+RE), published by the University of Hannover, March 2006, Germany, pp. 9-16.

[41] HERBSLEB, J.D. and GRINTER, R.E. (1999); “Splitting the Organization and Integrating the Code: Conway’s Law Revisited ”, In Proceedings of the 21st International Conference on Software Engineering (ICSE’99), ACM Press, New York, pp. 85-95.

[42] D. Šmite; N. B. Moe; R. Torkar (2008); “Pitfalls in Remote Team Coordination: Lessons Learned from a Case Study”, Accepted for presentation and publication in PROFES 2008 int. conf. proceedings, Italy.

[43] D. Dematteo; G. R. Marczyk; D. Festinger; Essentials Of Research Design And Methodology, John Wiley & Sons Inc., ISBN: 9780471470533, Paperback.

[44] David F. Redmiles, Sebastião B. Fonseca and Cleidson R. B. de Souza, “Exploring the Relationship between Dependencies and Coordination to Support Global Software Development Projects”, in proceedings IEEE International Conference on Global Software Engineering (ICGSE'06), 2006.

[45] J. J. J. Kasvi, M. Vartiainen, and M. Hailikari, “Managing knowledge and knowledge competences in projects and project organizations,” International Journal of Project Management, vol. 21, no. 8, pp. 571-582, January 2003.

[46] I. Ruuska, and M. Vartiainen,“Characteristics of knowledge sharing communities in project organizations”, International Journal of Project Management, vol. 23, no. 5, pp. 374-379, July 2005.

[47] C. Wohlin; P. Runeson et al; Experimentation in Software Engineering an Introduction, Kluwer Academic Publishers, London.

[48] L. Guion (2002); Triangulation: establishing the validity of qualitative studies, University of Florida Extension: Institute of Food and Agricultural Sciences.

[49] Christian Bird, Nachiappan Nagappan, Premkumar Devanbu, Harald Gall, Brendan Murphy (2009), “Does Distributed Development Affect Software Quality? An Empirical Case Study of Windows Vista”, in Proceedings International Conference on Software Engineering, Pages 518-528, Washington, DC, USA.

[50] Malone, T. W. & Crowston, K. (1994) the interdisciplinary study of coordination. ACM Computing Surveys (CSUR), 26, 87-119.

[51] A. Strauss; A. J. Corbin (1998); Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory, Thousand Oaks, CA: Sage Publications.

[52] B. Glaser; A. Strauss (1967); The discovery of grounded theory: Strategies of qualitative research, Wiedenfeld and Nicholson, London.

[53] Espinosa, J.A. and E. Carmel (2003), “The impact of time separation on coordination in global software teams: a conceptual foundation”, Software Process Improvement and Practice, 2003. 8(4): p. 249-66.

[54] Eoin Ó Conchúir, Pär J. Ågerfalk, Helena H. Olsson and Brian Fitzgerald, “Global Software Development: Where are the benefits?” Communications of the ACM, 2009, vol: 52(8), p. 127-131.

1.8. INTERVIEW QUESTIONS

Introduction

What is your role in the organization?

1. For how long have you been in a managerial position?2. For how long have you been involved in GSD?3. Can you please give brief history of the Organization? 4. Can you please give introduction of the current product or GSD project?

Domain questions

1. Which kind of development methodology, you use for this project?

2. How many project managers are involved in this project?

3. How many sites are involved in this project?

a. How many sites are globally distributed? (different countries)

b. Do you have sub-contractors for this project?

Yes: How many sub-contractors involved in this project?

i. Did sub-contractor have direct coordination and communication with customer?

Yes: Then how will he contact with customer regarding issues in the project?

No: Is there any impact on coordination?

c. What are major factors that affect the coordination by increasing no of sites?

d. Do all sites team members use same methods, tools and approaches?

Yes: Are all team members trained with these tools?

No: Then do you face any challenges in this project?

4. What kinds of communication tools are used to coordinate the distributed team members?

5. Do team members cooperate and coordinate with each other in the project?

6. Which is the most effective communication tool used to coordinate with the distributed team members?

7. If team members have any issues in the project then how do they coordinate with remote teams or central teams?

8. Who will create software architecture regarding division of labor and coordination needs etc?

9. Do you face any challenges in coordination between central team members and remote team members in the project?

a. How will you resolve these challenges?

10. Do you have project coordinator at each site?

11. What are major effects of coordination risks in software development?

12. How you can resolve misunderstanding issue between distributed team members?

13. Do you have responsibility of more than one project?

Yes: then how you will manage it?

14. Do each team is aware of other teams’ capability?

15. Is Communication between remote team and local team planned or unplanned?

a. What is the way of introducing your team to other team with different sites?

b. Does team know their roles and responsibilities in the project?

16. How the task distributed among team members?

a. How do you manage task dependencies between team members?

17. What are the reasons for misunderstandings between team members?

a. Lack of language skills

Yes: what practices are used to alleviate this risk?

No: how can you prevent this?

b. Cultural barrier

Yes: what practices are used to alleviate this risk?

No: how can you prevent this?

c. Lack of communication

Yes: what practices are used to alleviate this risk?

No: how can you prevent this?

Etc…

18. Do you use your previous experience in GSD projects to resolve the coordination and communication challenges in the current project?

19. Does usage of standards or conventions in the project cause any time delay or work overload?

20. What are the ways of socializing the teams?

a. Whether team members have chance of meeting each other?

b. Is team using any channels of communication (formal/informal) with each other?

21. What type of collaboration mode?(Inter organization or Intra organization )