Global Software
Development Projects in
One of the Biggest
Companies in Latvia: Is
Geographical Distribution
a Problem?
Research Section
Darja ˇSmite*
,†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 ˇSmite, Riga Information Technology Institute, Audit and Consulting, Kuldigas iela 45b, LV-1083, Riga, Latvia.
†E-mail: Darja.Smite@riti.lv
Contract/grant sponsor: European Social Fund
Contract/grant sponsor: Latvian Council of Science; con-tract/grant number: 02.2002
Copyright2006 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 sev-eral geographically distributed teams, bringing new opportunities as reaching mobility in resources,
speeding time-to-market, obtaining extra knowl-edge, and increasing operational efficiency.
There are many researches considering best prac-tices for evaluating and selecting an outsourcing service provider, economics, and contractual man-agement in outsourcing (Aubertet al. 2003, Roy and Aubert 2000, Willcocks and Fitzgerald 1994, Lacity 2002). Nevertheless, such areas as GSD perfor-mance, 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 differ-ent?’ 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 accu-mulation of the best practices, software engineering methods adopted for global specifics, and tools for better performance. However, this article will share only preliminary research results, highlighting spe-cific 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 rou-tine – global projects observation, risks and failure
indication, preventive action and guideline devel-opment, 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, con-sidering 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.
2.1. Case Description
XYZ is an ISO 9001 : 2000 certified company with around 350 employees. XYZ offers outsourcing services in the area of information system develop-ment, 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 partic-ipating in GSD projects since the early 1990s, work-ing with customers from countries includwork-ing 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 Copyright2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006;11: 61–76
life cycle and is responsible for project coordination and communication with the end customer.
Recently, XYZ became a part of the GSD enter-prise, 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 the case worldwide.
2.2. 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.
2.2.1. Documentation Examination
Documentation examination covered XYZ software development process and external and internal project audit reports during 2003, 2004; and inspec-tion findings from one of the major XYZ exter-nal 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.).
2.2.2. 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 2004. 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 dis-tributed software development and maintenance
Figure 1. Characteristics of the projects explored by the questionnaire
projects. Figure 1 shows the characteristics of the projects being examined.
The results of the survey are summarized accord-ing to preliminary guidelines (Kitchenham et al. 2002). The number of projects explored during the preliminary research does not reach the statisti-cal minimum. Therefore, these findings must be considered preliminary. Nevertheless, this report serves multiple functions, including summarizing the information collected, deepening the under-standing of the present situation of GSD project in XYZ, pointing to the major trends in the com-pany’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 con-ducted an inspection of GSD projects in XYZ in 2003. The inspection aimed to identify improve-ment 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 inter-views using standard checklists of issues to cover and ad hoc questioning based on the answers
received. In addition, there were breakaway ses-sions organized to evidence the processes.
3.2. 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 e-mail, telephone is little used
Delays in turnaround times for solutions 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
Serious problems of specific requirement omission that would not be identified until the system or acceptance test stages
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
Project deliverables might fail time savings on testing activities’ account can result in low quality products
10. Gap in problem prioritization Improper time expenditure
Table 2. Success criteria evaluation Budget conformity
Project type Overrun
No overrun (%) 1–30% 31–200% Over 200% Software development 53 21 0 5 Software implementation 5 0 0 0 Software maintenance and improvement 10 5 0 0
Calendar plan conformity
Project type Overrun
No overrun (%) 1–30% 31–200% Over 200% Software development 53 21 0 5 Software implementation 5 0 0 0 Software maintenance and improvement 10 5 0 0 Customer satisfaction
Project type Evaluation
High (%) Average (%) Low (%) Unknown (%) Software development 58 0 5 16 Software implementation 0 0 0 5 Software maintenance and improvement 15 0 0 0
3.3. 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, State-ment of Work coordination and project perfor-mance monitoring;
Table 3. Organizational structure appearance Organizational structures In place
(%)
Missing (%) Project manager on XYZ side 95 5 Project manager on the partner’s side 68 32
SC 32 68
UCCB 26 74
PCCB 21 79
• Project Level Change Control Board (PCCB), whose main task is to ensure qualitative and punctual work in compliance with the require-ments 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 guide-lines, 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 organi-zational 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.
3.4. How is the Responsibility Shared?
One of the questionnaire objectives was to clar-ify how the responsibility is shared in distributed projects among the partner and the offshore devel-oper. 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 Copyright2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006;11: 61–76
Table 4. Responsibility share Responsibilities XYZ (%) Partner (%) Both (%) Quality control 28 22 50 Project control 7 50 43 Project coordination 43 43 14
Responsibility for project results 14 43 43
Covering of expenses 22 71 0
Project effort estimation 28 43 28 Communication with the end customer 0 78 14
can be drawn. Both parties are responsible for qual-ity 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 part-ner (43%). Responsibility for project results (sched-ule 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.
There were projects where the partner was fully 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.
3.5. How is the Software Produced in a Distributed Environment?
Information gathered with the help of the question-naire assisted in deriving the models of collabora-tion between XYZ and the partners involved in soft-ware 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 cus-tomer?
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 inde-pendent 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, never-theless, 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)
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 indepen-dent offshore coding and joint systems analysis, design and testing activities. Both projects fol-lowed 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
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 per-formed jointly. The project followed incremental development methodology, requirement specifica-tion 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 devi-ations (1–30%), but the customer was satisfied.
3.6. 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 suc-cessful (accepted also by other case studies (Heeks
et al. 2001)), leaving the partners’ independent per-formance 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 environ-ment and has to be given special attention.
Table 5. Requirement specification quality evaluation Requirement specification author(s) Requirement quality evaluation High (%) Medium (%) Low (%) Partner 0 15 0 XYZ 0 15 10 Joint team 5 15 0
3.7. How are the Communication Liaisons Established?
Communication is an integral part of any relation-ship. Distribution in space and time is affected by many interrelated factors as organizational and cultural differences, language skills, and terminol-ogy differences, which are discussed later in this article. Therefore establishing effective communica-tion 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 obser-vations concerning prior e-mail usage instead of telephone. E-mail appears to be the most common means of communication (100% of participants use e-mail 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 e-mail as a prior means of communi-cation between the distributed partners often leads to misunderstandings and delays in information turnaround. According to E. Carmel and R. Agar-wal a small issue can take days of back-and-forth discussions over e-mail to resolve, but a brief con-versation 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 elec-tronic 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 (%) E-mail 58 42 0 0 Voice mail 5 5 5 84
On-line discussion groups 0 10 21 68
Telephone 5 63 26 5
Audio conferences 0 10 10 79
Video conferences 0 0 0 100
Meeting in person 5 16 68 10
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.
3.8. What are the Major Risks in Distributed Projects?
According to the GSD researchers, software devel-opment process distribution brings new challenges and risks. On the basis of extended research arti-cles on GSD risk management (Battin et al. 2001, Carmel and Agarwal 2001, Ebert and De Neve 2001, Orlikowski 2002) the questionnaire aimed to evalu-ate 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) consid-ering such factors as complicated organizational structure, many escalation levels, and different approaches in responsibility sharing. Many orga-nizations involved in distributed projects are not ready to change their internal structure and pro-cesses along with new partners.
Low language skills of XYZ employees, lack of understanding of tasks assigned, cultural differ-ences, 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 5 21 74
Low language skills (XYZ)
10 47 43
Low language skills (other side) 0 5 95 Terminology differences 0 32 68 Lack of understanding of tasks assigned 0 63 37 Organizational differences 16 37 47 Cultural differences 5 32 63
brought about by geographic distribution, which cannot be avoided in GSD. With negative out-comes such as delays in time for communication and problem solution, misunderstandings and commu-nication 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 demon-strated 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 app-roach;
• 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 pre-liminary 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 infor-mation 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 Outcome
Project phases distribution Problematic overall joint management Problematic responsibility share
Extra management needed at every location Lack of personal contact Troubled trust and confidence achievement
Time delays for solution turnaround Time zone difference Problematic asynchronous communication
Time delays for communication and solution turnaround Organizational differences Complex problem escalation
Time delays for solution turnaround Cultural differences Misunderstandings
Communication problems Language difference Misunderstandings
Communication problems Avoidance of verbal contact Terminology differences Misunderstandings
Time delays for terminology clarification and possible rework Lack of business knowledge Time delays for problem domain clarification
Extra costs for possible rework
Inadequate infrastructure Time delays for communication and solution turnaround Extra costs for infrastructure improvement
Different understanding of cooperation approach and related project activities
Troublesome disagreements Time delays
Communication problems
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 envi-ronment are as important as technological fac-tors. The overall project atmosphere, influenced by many different factors such as cultural and orga-nizational differences, time zones and geographic distance, plays an important role in successful com-munication in a geographically distributed envi-ronment. 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 sig-nificant 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 par-ties 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 con-sidered 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. 02.2002 ‘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. 2003.
Characteris-tics of IT Outsourcing Contracts. HICSS: Hawaii, 269.
Bakalov R. 2004. Risk management strategies for offshore application and systems development. Information
Systems Control Journal5: 36–38.
Battin RD, Crocker R, Kreidler J. 2001. Leveraging resources in global software development.IEEE Software
18(2): 70–77.
Carmel E, Agarwal R. 2001. Tactical approaches for alleviating distance in global software development.IEEE
Software18(2): 22–29.
Ebert C, De Neve P. 2001. Surviving global software development.IEEE Software18(2): 62–69.
Greenwood DJ, Levin M. 1998. Introduction to Action
Research. Sage Publications: Thousand Oaks, Canada.
Heeks R, Krishna S, Nicholson B, Sundeep S. 2001. Synching or sinking: Global software outsourcing relationships.IEEE Software18(2): 54–60.
Kitchenham BA, Pfleeger SL, Pickard LM, Jones PW, Hoaglin DC, Emam KE, Rosenberg J. 2002. Preliminary guidelines for empirical research in software engineering.
IEEE Transactions on Software Engineering28: 721–734.
Lacity M. 2002. Lessons in global information technology sourcing.IEEE Computer35(8): 26–33.
Orlikowski WJ. 2002. Knowing in practice: Enacting a collective capability in distributed organizing.
Organization Science13(3): 249–273.
Rousseau DM, Sitkin SB, Burt RS, Camerer C. 1998. Not so different after all: A cross discipline view of trust.
Academy of Management Review23(3): 393–404.
Roy V, Aubert B. 2000. A Resource-Based Analysis of IT
Sourcing,Scientific Series. CIRANO: Montreal, Canada.
Smite D. 2004. Global software development project management–distance overcoming. Proceedings of 11th
European Conference, EuroSPI 2004, Trondheim, Norway,
November 2004, 23–33.
Smite D, Borzovs J. 2004. Global software development process management: Problem statement.Proceedings of 16th International Baltic Conference Baltic DB&IS 2004
Doctoral Consortium, Riga, Latvia, June 6–9 2004, 198–207.
Willcocks L, Fitzgerald G. 1994. 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 1 898085 10 2.
