Global Software Development Projects in One of the Biggest Companies in Latvia: Is Geographical Distribution aproblem?

Transcription

1 SOFTWARE PROCESS IMPROVEMENT AND PRACTICE Softw. Process Improve. Pract. 2006; 11: Published online in Wiley InterScience ( DOI: /spip.252 Global Software Development Projects in One of the Biggest Companies in Latvia: Is Geographical Distribution aproblem? Research Section Darja Šmite*, Riga Information Technology Institute, Audit and Consulting, Kuldigas iela 45b, LV-1083, Riga, Latvia Global software development appears to be the latest trend in software engineering, bringing new opportunities as reaching mobility in resources, speeding time-to-market, obtaining extra knowledge, and increasing operational efficiency. Despite the popularity of the topic, there is a lack of research answering all the questions about how to perform in a distributed environment. This article describes research that aims to develop a framework for global project management and performance. In particular, the research shares information about the variety of collaboration models and project characteristics, and highlights areas of concern and specific risks examined in an observation of 19 distributed projects in a software development company in Latvia. The case study gives an overview of distributed projects emphasizing the specific risks such as organizational and cultural differences, language and time zone differences, lack of personal contact, and troubled communication over geographical distances. The preliminary research concludes that there is a necessity of specific methods and practices for effective project performance in a distributed environment. Copyright 2006 John Wiley & Sons, Ltd. KEY WORDS: global software development; software development in distributed environment; software process improvement Correspondence to: Darja Šmite, Riga Information Technology Institute, Audit and Consulting, Kuldigas iela 45b, LV-1083, Riga, Latvia. Darja.Smite@riti.lv Contract/grant sponsor: European Social Fund Contract/grant sponsor: Latvian Council of Science; contract/grant number: Copyright 2006 John Wiley & Sons, Ltd. 1. GLOBAL SOFTWARE DEVELOPMENT AS A TREND Global software development (GSD) appears to be the latest trend in software engineering. The term GSD marks the way of producing software by several geographically distributed teams, bringing new opportunities as reaching mobility in resources,

2 D. Šmite speeding time-to-market, obtaining extra knowledge, and increasing operational efficiency. There are many researches considering best practices for evaluating and selecting an outsourcing service provider, economics, and contractual management in outsourcing (Aubert et al. 2003, Roy and Aubert 2000, Willcocks and Fitzgerald 1994, Lacity 2002). Nevertheless, such areas as GSD performance, key success/failure factors, social-cultural issues, and global project and risk management lack a deeper analysis. Accordingly, practitioners currently seek guidelines for risk minimization and better performance, adjusting their own practices and analyzing the causes of project failures. One of the major hypothesis considering GSD projects is the difference between the in-land and distributed projects. The author s research in the area of GSD aims to specify this difference by exploring GSD project risks. The questions seeking answers are How are distributed projects different? and Do practitioners have to implement new practices, methods, and tools for GSD projects? The objective of the entire research is to develop a framework for GSD projects, consisting of the accumulation of the best practices, software engineering methods adopted for global specifics, and tools for betterperformance.however, this article will share only preliminary research results, highlighting specific project risks and deepening the understanding of the research area. 2. RESEARCH APPROACH The research on GSD is an ongoing software process improvement project in one of the biggest software development companies in Latvia, given a pseudonym XYZ (Smite 2004, Smite and Borzovs 2004). The author is involved in XYZ quality processes performing internal audits and providing consultancies on project measurement. The research approach chosen for the entire GSD management improvement in XYZ is an action methodology learning by doing. Action research methodology aims to contribute to the practical concerns of people in an immediate problematic situation and to further the goals of social science simultaneously (Greenwood and Levin 1998). In practice, the author performs the following routine global projects observation, risks and failure indication, preventive action and guideline development, guidelines testing in ongoing projects, measuring the results of guidelines implementation, and improving the guidelines. The expected result of the entire research is a standardized framework describing global project performance and management. The preliminary research in its turn aimed to clarify how the present distributed projects are managed and what are the major project risks. In particular, the following questions were put: Are there any audit observations considering global project performance? Are the global projects successful in XYZ, considering the following factors project budget, schedule, and user expectations? Is a set of global risks explored in related literature urgent for XYZ projects? Are there any other specific risks? The further sections of this article will describe an organization used as a case study, preliminary research steps, and the results Case Description XYZ is an ISO 9001 : 2000 certified company with around 350 employees. XYZ offers outsourcing services in the area of information system development, implementation, support and maintenance, as well as information system reengineering. XYZ uses several development approaches such as waterfall, incremental development, and rapid application development (RAD). The company has been participating in GSD projects since the early 1990s, working with customers from countries including the United Kingdom, Germany, Austria, Switzerland, and Finland. Software development outsourcing services are focusing on the following areas: public sector, telecommunications, insurance, banking, tourism, logistics. XYZ is engaged in GSD projects either as a direct supplier or as a subcontracting party. In most of the cases there is a mediating company (a partner), which shares some activities during the software 62

3 GSD Projects and Geographical Distribution life cycle and is responsible for project coordination and communication with the end customer. Recently, XYZ became a part of the GSD enterprise, participating in GSD projects worldwide. The enterprise often involves several distributed developers for one project realization, which brings new challenges of performance. This highlights the necessity of the research in the area of GSD project improvement and gives an opportunity to analyze thecaseworldwide Preliminary Research The preliminary research of GSD projects included two steps. The first step of the research was devoted to an investigation of a set of XYZ internal and external audit reports and the second step was a survey of global projects Documentation Examination Documentation examination covered XYZ software development process and external and internal project audit reports during 2003, 2004; and inspection findings from one of the major XYZ external partners in Western Europe. Documentation examination gave a significant insight into what the customers think about XYZ as a service supplier (see Section 3.1.) Survey The survey aimed to clarify the present situation of GSD projects in XYZ and highlight project risks for deeper analysis. The survey was conducted using a questionnaire given at the end of It was developed in the Latvian language and distributed among project managers from the XYZ side. For a translated version of the survey see Appendix 1. The questionnaire included structured and open questions considering the following areas: Basic project information; Success evaluation; Methodologies used; Responsibility share; Development process distribution; Risks and problems; Communication tools used. The survey gathered information about 19 distributed software development and maintenance Figure 1. Characteristics of the projects explored by the questionnaire 63

4 D. Šmite projects. Figure 1 shows the characteristics of the projects being examined. The results of the survey are summarized according to preliminary guidelines (Kitchenham et al. 2002). The number of projects explored during the preliminary research does not reach the statistical minimum. Therefore, these findings must be considered preliminary. Nevertheless, this report serves multiple functions, including summarizing the information collected, deepening the understanding of the present situation of GSD project in XYZ, pointing to the major trends in the company s project management risks and challenges, and preparing the input for further research. 3. THE RESEARCH RESULTS 3.1. What do Partners Think of XYZ? XYZ s major partners from Western Europe conducted an inspection of GSD projects in XYZ in The inspection aimed to identify improvement areas and activities necessary to de-risk the chance of failure. The inspection produced a list of risks and areas of concern (see Table 1). This review was conducted by means of interviews using standard checklists of issues to cover and ad hoc questioning based on the answers received. In addition, there were breakaway sessions organized to evidence the processes Are Distributed Projects Successful? Project success was measured according to three major categories budget conformity, calendar plan conformity, and customer satisfaction. A project is successful if all three objectives are achieved; and not successful if any of the categories is within the following values: budget or calendar plan are overrun, or customer satisfaction is average or low. The questionnaire distributed among 19 projects received the following results (see Table 2). To comment on the results it has to be noted that the projects that had budget overrun had an equal order of calendar overrun, nevertheless, not always causing customer dissatisfaction. Analyzing the results, we can see that five projects exceeded the budget and calendar plans; and there was one project with extremely high budget and calendar overrun (over 200%) and low user satisfaction. The comparison with XYZ partner inspection findings shows that these deviations (in 6 projects out of 19) could have been caused by the risk of over optimistic planning. The results of success evaluation are subjective, as they are based on XYZ s project manager s opinions. Table 1. Partner s inspection Areas of concern Risks Negative outcome Requirements 1. Lack of business knowledge Difficulties in system development and testing from the business perspective Planning/management 2. Planning is extremely high risk and optimistic Project deliverables might fail 3. Lack of contingency 4. No real support time built in 5. Too short windows between completion of development and system test Communication 6. Too much reliance is placed on , Delays in turnaround times for solutions telephone is little used Process/quality 7. Lack of common understanding of the process in process management, escalation and closure Time delays 8. Lack of analysis reviews and improper requirement specifications usage Testing 9. Testing team has lack of business knowledge (see also Risk No. 1) and time (see also Risk No. 2) to complete testing activities successfully Serious problems of specific requirement omission that would not be identified until the system or acceptance test stages Project deliverables might fail time savings on testing activities account can result in low quality products 10. Gap in problem prioritization Improper time expenditure 64

5 GSD Projects and Geographical Distribution Table 2. Success criteria evaluation Table 3. Organizational structure appearance Project type Budget conformity Overrun No 1 30% % Over overrun 200% Software development Software implementation Software maintenance and improvement Project type Calendar plan conformity Overrun No 1 30% % Over overrun 200% Software development Software implementation Software maintenance and improvement Project type Customer satisfaction High Evaluation Average Low Unknown Software development Software implementation Software maintenance and improvement How are the Global Projects Managed? Distributed project management is an outstanding challenge. It is essential for each project to build an effective project management structure, which can help in managerial and performance risk minimization. XYZ together with its major partner from Western Europe developed guidelines for distributed project organization, considering the following management structures: Steering Committee (SC), whose main task is strategic and 6-month project assignment planning, as well as overall cooperation process monitoring; Upper Level Change Control Board (UCCB), whose main task is operational planning, Statement of Work coordination and project performance monitoring; Organizational structures In place Missing Project manager on XYZ side 95 5 Project manager on the partner s side SC UCCB PCCB Project Level Change Control Board (PCCB), whose main task is to ensure qualitative and punctual work in compliance with the requirements stated in Statement of Work, as well as change control; Project managers from both sides, whose main task is to provide operational management and problem reporting for upper management. The questionnaire aimed to clarify if the projects actually use these structures. The results were surprising these guidelines are followed by less than a half of the projects (see Table 3). Specifying the results, several facts have to be emphasized. It was interesting that there was only one project with all the organizational structures in place. The projects with the partners from Western Europe, who developed these management guidelines, either had no organizational structures as SC, UCCB, and PCCB, or had no information about them. Taking into account that the questionnaire was filled by project managers, it was surprising that some of them were not aware of upper organizational structures. This fact points out an issue for further investigation, aiming to clarify, how deep the partnership between the parties involved is in these projects. Other project management activities as process management and risk management are discussed in the following sections How is the Responsibility Shared? One of the questionnaire objectives was to clarify how the responsibility is shared in distributed projects among the partner and the offshore developer. Analyzing XYZ data about projects where XYZ is participating as a subcontracting party (14 projects), the following results were derived (see Table 4). The results of the questionnaire show a variety of answers. Accordingly, the following conclusions 65

6 D. Šmite Table 4. Responsibility share Responsibilities XYZ Partner Both Quality control Project control Project coordination Responsibility for project results Covering of expenses Project effort estimation Communication with the end customer can be drawn. Both parties are responsible for quality management in half of the projects. Project control is either partner s responsibility (50%) or a shared activity (43%), while responsibility for project coordination varies XYZ (43%) or the partner (43%). Responsibility for project results (schedule and effort conformity) is either partner s (43%) or a shared (43%) activity. The partner is usually the one who covers all the expenses (71%), estimates the project effort (43%), and communicates with the end customer (78%). Predictably, an offshore entity is never responsible for communication with the end customer, and only in 14% cases it appears to be a shared activity. Therewereprojectswherethepartnerwasfully responsible, as well as projects where most of the activities were shared. Common activity sharing and sharing of goals indicates a close relationship among the participants of the project How is the Software Produced in a Distributed Environment? Information gathered with the help of the questionnaire assisted in deriving the models of collaboration between XYZ and the partners involved in software development in a distributed environment. This information considers software development process distribution and methodologies used. The models were then analyzed in order to understand whether each model is successful or not, considering the following questions: What was the quality of systems requirement specification; design specification? How easily were requirements clarified during the project? Were there joint development teams? Did the offshore developer meet the end customer? The software product implementation and software maintenance project was not included in the analyses; therefore the results contain information about 17 software development or improvement projects. The first model was followed by five projects. This first model (see Figure 2) describes the software development cycle, in which systems analysis and design stages are done by the partner. The offshore developer is involved in the development stage as a member of a joint system development team. Testing is performed either by the partner (two cases) or as a joint activity (three cases). All the projects had mixed development teams. Most of the projects (four) were involved in independent functional development. Three of these projects were successful, although in two projects the offshore team never met the end customer, and in one project requirement clarification during the projects was troublesome. The other project ended with 1 30% deviation in budget and time, nevertheless, achieving good customer satisfaction. The project manager reported that XYZ was a small part of a huge multidistributed team and the major problems in the project were connected with system integration and testing. The last project followed incremental approach using prototyping. This project also ended with 1 30% deviation in budget and time, but achieved good customer satisfaction. Although the offshore team had regular meetings with the customer, both Figure 2. A variation of the first process distribution model (testing is a joint activity) 66

7 GSD Projects and Geographical Distribution requirement specification and design quality were evaluated as medium, and requirement clarification during the project was troublesome. There was also a project, where systems analysis was done by the partner and all the other activities (design, coding, and testing) were performed by the joint team. Although the results of systems analysis and design were evaluated as medium, and the offshore team had never met the customer, the project was successful with no deviations and achieved good customer satisfaction. The second model (see Figure 3) was followed by two projects. This model prescribes independent offshore coding and joint systems analysis, design and testing activities. Both projects followed incremental software development life cycle. Software requirement quality in both projects was reported as medium, but design quality in one of the projects was high. Requirement clarification in both projects was easy. This model appears to be one of the most successful, as both projects were on budget and on time and achieved good customer satisfaction. There was a variation of the second model followed by one project, where systems analysis was performed by the offshore team. The team never met with the customer in this project. The quality of requirement specification was evaluated as low and was possibly the reason for failure. Therefore, the design was further developed jointly. The project had no deviations and achieved good customer satisfaction. There was another variation of the second model followed by one project, where the design activities were performed only by the offshore team. This project was developed on the prototype basis, the requirement clarification was fast, but the offshore team never met the end customer. The project had deviations in time and budget (1 30%) but the end customer was very well satisfied. The third project model (see Figure 4) was followed by four projects with some variations. Three projects followed prototyping methodology and omitted the design phase. Systems analysis and development was performed by the offshore team and tested by the partner. These projects were special because of the close collaboration between the offshore developer and partner, meeting in person on a regular basis. Therefore, requirement clarification during the project was fast in two projects and medium fast in one project. All the projects were successful (on time, on budget, and achieved good customer satisfaction). In the other project, design was developed by the offshore team. This project performed independent functional development. Although the offshore team organized regular on-site meetings with the customer, requirement clarification during the project appeared to be troublesome. Besides, the low quality of requirement specification appeared Figure 3. The second process distribution model Figure 4. The third process distribution model 67

8 D. Šmite Figure 5. The fourth process distribution model to be the reason for the project failure. Accordingly, customer satisfaction was low; and the budget and calendar plan deviations exceeded 200%. The fourth model (see Figure 5) was followed by two projects. This model described projects, where systems analysis, design and testing activities were done by the partner and only the coding was sent offshore. In both cases, the offshore team never met the end customer. One of the two projects developed the software on a prototype basis, with medium software requirement quality and medium fast requirement clarification, and never met the customer. The project ended with budget and calendar plan overrun (1 30%), but the client was well satisfied. The other project performed independent functional development, with fast requirement clarification process, never met the customer and appeared to be successful. There was also a variation of this model followed by one project. The design in this project was performed jointly. The project followed incremental development methodology, requirement specification and design quality was evaluated as medium, requirement clarification appeared to be medium fast, and this offshore team never met the customer too. This project has budget and calendar plan deviations (1 30%), but the customer was satisfied Who Should Develop Requirements? Systems requirement analysis is an important step in software development, which if handled inappropriately can cause high cost escalation and calendar deviations. The major factors that effect systems requirement analysis in a distributed environment are communication problems, lack of business knowledge, and organizational and cultural differences. The following are the three ways in which XYZ projects manage systems requirement analysis: Systems requirement analysis performed by XYZ; Systems requirement analysis performed by the remote partner; Systems requirement analysis performed jointly. One of the questions aimed to clarify what is the quality of requirement specification produced by the partner; XYZ; and both sides jointly. The quality of requirements was evaluated by project managers according to such factors as stability, completeness, clarity, validity, and feasibility. The following coherence was derived (see Table 5). Both the project managers evaluated requirement quality as low, and mentioned that this appeared to be the reason for project failure (both projects overrun budget and calendar plan more than 200%). This might have been caused by a lack of business knowledge, which was emphasized during the XYZ partner inspection. Unfortunately, 40% of project managers did not give their requirement evaluation. The existent results show that joint performance in systems requirement analysis appears to be the most successful (accepted also by other case studies (Heeks et al. 2001)), leaving the partners independent performance in the second place. Yet most of the project managers evaluated requirement quality as medium. This indicates that systems analysis performance is a challenge in a distributed environment and has to be given special attention. Table 5. Requirement specification quality evaluation Requirement specification author(s) High Requirement quality evaluation Medium Low Partner XYZ Joint team

9 GSD Projects and Geographical Distribution 3.7. How are the Communication Liaisons Established? Communication is an integral part of any relationship. Distribution in space and time is affected by many interrelated factors as organizational and cultural differences, language skills, and terminology differences, which are discussed later in this article. Therefore establishing effective communication liaisons between the geographically distributed partners is an essential part of cooperation in GSD. The questionnaire was used to clarify what communication tools are used in XYZ distributed projects and how often. The results were as follows (see Table 6). The survey results confirmed XYZ partner observations concerning prior usage instead of telephone. appears to be the most common means of communication (100% of participants use either every day (58%) or often (42%)), while telephone communication follows with only 5% of participants using it every day and 63% using it often. Using as a prior means of communication between the distributed partners often leads to misunderstandings and delays in information turnaround. According to E. Carmel and R. Agarwal a small issue can take days of back-and-forth discussions over to resolve, but a brief conversation can quickly clarify the problem before it becomes bigger (Carmel and Agarwal 2001). While there is a lack of personal contact working in a distributed environment, telephone and electronic means of video and audio conferencing bring humanity in relationships between the distributed teams. Although the results of the questionnaire uncovered a seldom-used application of modern collaboration tools, those projects using audio and videoconferences in their everyday collaboration have high regard for them. Table 6. Communication tools used Communication tools Every day Often Seldom Never Voice mail On-line discussion groups Telephone Audio conferences Video conferences Meeting in person The questionnaire has also shown that the partners rarely meet in person. Nevertheless, none of the electronic means of communication can provide an adequate level of confidence for building trust between the distributed partners. XYZ project managers, in discussions, reported that there is a necessity for personal contact at least in the beginning of the relationship What are the Major Risks in Distributed Projects? According to the GSD researchers, software development process distribution brings new challenges and risks. On the basis of extended research articles on GSD risk management (Battin et al. 2001, Carmel and Agarwal 2001, Ebert and De Neve 2001, Orlikowski 2002) the questionnaire aimed to evaluate the application of these risks in XYZ distributed projects. The questionnaire provided the following results (see Table 7). The most important risk factor according to the questionnaire results is organizational differences (16% important, 37% medium important) considering such factors as complicated organizational structure, many escalation levels, and different approaches in responsibility sharing. Many organizations involved in distributed projects are not ready to change their internal structure and processes along with new partners. Low language skills of XYZ employees, lack of understanding of tasks assigned, cultural differences, and terminology differences are also seen as areas of concern by many projects. These risks are Table 7. Risk factors Risk factor Important Medium Important Unimportant Time zones Low language skills (XYZ) Low language skills (other side) Terminology differences Lack of understanding of tasks assigned Organizational differences Cultural differences

10 D. Šmite brought about by geographic distribution, which cannot be avoided in GSD. With negative outcomessuchasdelaysintimeforcommunicationand problem solution, misunderstandings and communication problems, unexpected costs, and so on, risk management in distributed environment appears to be a complicated task for both partner and the offshore developer. Analyzing the results of the questionnaire, the relationship with the partners nearshore demonstrated relative coherence. On the contrary, the greater the distance between the partners the more important become the risk factors. Project managers working with partners at a distance of 4000 km named a set of additional risk factors important in their case as follows: lack of quality management at the partner s side; different understanding of cooperation approach; differences in supporting the customer; disagreement on marketing activities. Because of global project specifics, new project management practices are necessary for better performance. One of the further steps of the research aims to develop a checklist for distributed projects, in order to provide appropriate risk identification. 4. DISCUSSION: WHAT IS THE DIFFERENCE BETWEEN IN-LAND AND DISTRIBUTED PROJECTS? Although the set of data gathered during the preliminary research is insufficient for factorial analysis and cannot provide statistical minimum it is used as a case study to derive the hypotheses considering global influence on software development specifics for the Latvian company XYZ. Summarizing information gathered with the help of the questionnaire and during informal discussions with the project managers, the following factors and their outcomes for geographically distributed projects have been derived (see Table 8). Project technological organization is essential for distributed team support. Practitioners see the necessity for modern communication tools and Table 8. Specific risk factors in distributed projects and their outcomes Risk factor Project phases distribution Lack of personal contact Time zone difference Organizational differences Cultural differences Language difference Terminology differences Lack of business knowledge Inadequate infrastructure Different understanding of cooperation approach and related project activities Outcome Problematic overall joint management Problematic responsibility share Extra management needed at every location Troubled trust and confidence achievement Time delays for solution turnaround Problematic asynchronous communication Time delays for communication and solution turnaround Complex problem escalation Time delays for solution turnaround Misunderstandings Communication problems Misunderstandings Communication problems Avoidance of verbal contact Misunderstandings Time delays for terminology clarification and possible rework Time delays for problem domain clarification Extra costs for possible rework Time delays for communication and solution turnaround Extra costs for infrastructure improvement Troublesome disagreements Time delays Communication problems 70

11 GSD Projects and Geographical Distribution joint repository implementation for distributed project data, code storage, problem tracking, and joint version control. Inadequate infrastructure can hamper communication and collaboration among the distributed project members and cause project failure. Finally, the human factors in a distributed environment are as important as technological factors. The overall project atmosphere, influenced by many different factors such as cultural and organizational differences, time zones and geographic distance, plays an important role in successful communication in a geographically distributed environment. According to Rudy Bakalov, cultural differences are often the root cause of many of the risks discussed (e.g. protection of intellectual capital and communications) and can create significant stress in offshore project team members (Bakalov 2004). Lack of personal contact among the project members leads to troubled trust; confidence achievement is not the least objective of project management. Trust in the relationship enables cooperative behavior, reduces conflicts, decreases transaction costs, and promotes effective responses to crises (Rousseau et al. 1998). The involved parties may consider each other as us and them, but may also perform as a unified team labeled as us. Therefore, building a unified team is considered to be one of the ways for various risk mitigations. All the additional risks and specifics lead to the conclusion that there is a necessity for new approaches and practices for project management, communication establishment, process distribution and coordination, in order to provide appropriate management in a distributed environment. The further steps of the research aim to develop a risk management framework, consisting of a software development risk identification checklist tailored for global specifics and knowledge base for best practice accumulation to provide risk mitigation guidance. ACKNOWLEDGEMENTS This research is partly supported by the European Social Fund and the Latvian Council of Science project No Latvian Informatics Production Unit Support Program in the Area of Engineering, Computer Networks, and Signal Processing. REFERENCES Aubert B, Houde JF, Patry M, Rivard S Characteristics of IT Outsourcing Contracts. HICSS: Hawaii, 269. Bakalov R Risk management strategies for offshore application and systems development. Information Systems Control Journal 5: Battin RD, Crocker R, Kreidler J Leveraging resources in global software development. IEEE Software 18(2): Carmel E, Agarwal R Tactical approaches for alleviating distance in global software development. IEEE Software 18(2): Ebert C, De Neve P Surviving global software development. IEEE Software 18(2): Greenwood DJ, Levin M Introduction to Action Research. Sage Publications: Thousand Oaks, Canada. Heeks R, Krishna S, Nicholson B, Sundeep S Synching or sinking: Global software outsourcing relationships. IEEE Software 18(2): Kitchenham BA, Pfleeger SL, Pickard LM, Jones PW, Hoaglin DC, Emam KE, Rosenberg J Preliminary guidelines for empirical research in software engineering. IEEE Transactions on Software Engineering 28: Lacity M Lessons in global information technology sourcing. IEEE Computer 35(8): Orlikowski WJ Knowing in practice: Enacting a collective capability in distributed organizing. Organization Science 13(3): Rousseau DM, Sitkin SB, Burt RS, Camerer C Not so different after all: A cross discipline view of trust. Academy of Management Review 23(3): Roy V, Aubert B A Resource-Based Analysis of IT Sourcing, Scientific Series. CIRANO: Montreal, Canada. Smite D Global software development project management distance overcoming. Proceedings of 11th European Conference, EuroSPI 2004, Trondheim, Norway, November 2004, Smite D, Borzovs J Global software development process management: Problem statement. Proceedings of 16th International Baltic Conference Baltic DB&IS 2004 Doctoral Consortium, Riga, Latvia, June , Willcocks L, Fitzgerald G A Business Guide to Outsourcing Information Technology, A Study of European Best Practice in the Selection, Management and Use of External IT Services. Business Intelligence: Wimbledon, London, 372, ISBN

12 D. Šmite APPENDIX 1 72

13 GSD Projects and Geographical Distribution 73

14 D. Šmite 74

15 GSD Projects and Geographical Distribution 75

16 D. Šmite 76