global software development projects in one of the biggest companies in latvia: is geographical...

SOFTWARE PROCESS IMPROVEMENT AND PRACTICESoftw. Process Improve. Pract. 2006; 11: 61–76Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/spip.252

Global SoftwareDevelopment Projects inOne of the BiggestCompanies in Latvia: IsGeographical Distributiona Problem?

Research Section

Darja Smite*,†

Riga Information Technology Institute, Audit and Consulting, Kuldigas iela45b, LV-1083, Riga, Latvia

Global software development appears to be the latest trend in software engineering, bringingnew opportunities as reaching mobility in resources, speeding time-to-market, obtaining extraknowledge, and increasing operational efficiency. Despite the popularity of the topic, thereis a lack of research answering all the questions about how to perform in a distributedenvironment. This article describes research that aims to develop a framework for global projectmanagement and performance. In particular, the research shares information about the varietyof collaboration models and project characteristics, and highlights areas of concern and specificrisks examined in an observation of 19 distributed projects in a software development companyin Latvia. The case study gives an overview of distributed projects emphasizing the specificrisks such as organizational and cultural differences, language and time zone differences, lackof personal contact, and troubled communication over geographical distances. The preliminaryresearch concludes that there is a necessity of specific methods and practices for effective projectperformance 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 TechnologyInstitute, Audit and Consulting, Kuldigas iela 45b, LV-1083,Riga, Latvia.†E-mail: [email protected]/grant sponsor: European Social FundContract/grant sponsor: Latvian Council of Science; con-tract/grant number: 02.2002

Copyright 2006 John Wiley & Sons, Ltd.

1. GLOBAL SOFTWARE DEVELOPMENTAS A TREND

Global software development (GSD) appears to bethe latest trend in software engineering. The termGSD marks the way of producing software by sev-eral geographically distributed teams, bringing newopportunities as reaching mobility in resources,

Research Section D. Smite

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 outsourcingservice provider, economics, and contractual man-agement in outsourcing (Aubert et al. 2003, Roy andAubert 2000, Willcocks and Fitzgerald 1994, Lacity2002). Nevertheless, such areas as GSD perfor-mance, key success/failure factors, social-culturalissues, and global project and risk managementlack a deeper analysis. Accordingly, practitionerscurrently seek guidelines for risk minimization andbetter performance, adjusting their own practicesand analyzing the causes of project failures.

One of the major hypothesis considering GSDprojects is the difference between the in-land anddistributed projects. The author’s research in thearea of GSD aims to specify this difference byexploring GSD project risks. The questions seekinganswers are ‘How are distributed projects differ-ent?’ and ‘Do practitioners have to implement newpractices, methods, and tools for GSD projects?’The objective of the entire research is to develop aframework for GSD projects, consisting of the accu-mulation of the best practices, software engineeringmethods adopted for global specifics, and tools forbetter performance. However, this article will shareonly preliminary research results, highlighting spe-cific project risks and deepening the understandingof the research area.

2. RESEARCH APPROACH

The research on GSD is an ongoing softwareprocess improvement project in one of the biggestsoftware development companies in Latvia, given apseudonym XYZ (Smite 2004, Smite and Borzovs2004). The author is involved in XYZ qualityprocesses performing internal audits and providingconsultancies on project measurement.

The research approach chosen for the entire GSDmanagement improvement in XYZ is an actionmethodology – ‘learning by doing’. Action researchmethodology aims to contribute to the practicalconcerns of people in an immediate problematicsituation and to further the goals of social sciencesimultaneously (Greenwood and Levin 1998). Inpractice, 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 astandardized framework describing global projectperformance and management.

The preliminary research in its turn aimed toclarify how the present distributed projects aremanaged and what are the major project risks. Inparticular, the following questions were put:

• Are there any audit observations consideringglobal 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 relatedliterature urgent for XYZ projects? Are thereany other specific risks?

The further sections of this article will describean organization used as a case study, preliminaryresearch steps, and the results.

2.1. Case Description

XYZ is an ISO 9001 : 2000 certified company witharound 350 employees. XYZ offers outsourcingservices in the area of information system develop-ment, implementation, support and maintenance, aswell as information system reengineering. XYZ usesseveral development approaches such as waterfall,incremental development, and rapid applicationdevelopment (RAD). The company has been partic-ipating in GSD projects since the early 1990s, work-ing with customers from countries including theUnited Kingdom, Germany, Austria, Switzerland,and Finland. Software development outsourcingservices are focusing on the following areas:

• public sector,• telecommunications,• insurance,• banking,• tourism,• logistics.

XYZ is engaged in GSD projects either as a directsupplier or as a subcontracting party. In most ofthe cases there is a mediating company (a partner),which shares some activities during the software

Copyright 2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006; 11: 61–76

62

Research Section GSD Projects and Geographical Distribution

life cycle and is responsible for project coordinationand 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 distributeddevelopers for one project realization, which bringsnew challenges of performance. This highlights thenecessity of the research in the area of GSD projectimprovement and gives an opportunity to analyzethe case worldwide.

2.2. Preliminary Research

The preliminary research of GSD projects includedtwo steps. The first step of the research was devotedto an investigation of a set of XYZ internal andexternal audit reports and the second step was asurvey of global projects.

2.2.1. Documentation ExaminationDocumentation examination covered XYZ softwaredevelopment process and external and internalproject 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 thecustomers think about XYZ as a service supplier(see Section 3.1.).

2.2.2. SurveyThe survey aimed to clarify the present situation ofGSD projects in XYZ and highlight project risks fordeeper analysis. The survey was conducted usinga questionnaire given at the end of 2004. It wasdeveloped in the Latvian language and distributedamong project managers from the XYZ side. For atranslated version of the survey see Appendix 1.

The questionnaire included structured and openquestions 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


63


projects. Figure 1 shows the characteristics of theprojects being examined.

The results of the survey are summarized accord-ing to preliminary guidelines (Kitchenham et al.2002). The number of projects explored during thepreliminary research does not reach the statisti-cal minimum. Therefore, these findings must beconsidered preliminary. Nevertheless, this reportserves multiple functions, including summarizingthe information collected, deepening the under-standing of the present situation of GSD projectin 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 in2003. The inspection aimed to identify improve-ment areas and activities necessary to de-risk thechance of failure. The inspection produced a list ofrisks and areas of concern (see Table 1).

This review was conducted by means of inter-views using standard checklists of issues to coverand 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 threemajor categories – budget conformity, calendarplan conformity, and customer satisfaction. Aproject is successful if all three objectives areachieved; and not successful if any of the categoriesis within the following values: budget or calendarplan are overrun, or customer satisfaction is averageor low.

The questionnaire distributed among 19 projectsreceived the following results (see Table 2).

To comment on the results it has to be noted thatthe projects that had budget overrun had an equalorder of calendar overrun, nevertheless, not alwayscausing customer dissatisfaction.

Analyzing the results, we can see that fiveprojects exceeded the budget and calendar plans;and there was one project with extremely highbudget and calendar overrun (over 200%) and lowuser satisfaction. The comparison with XYZ partnerinspection findings shows that these deviations (in6 projects out of 19) could have been caused by therisk of over optimistic planning.

The results of success evaluation are subjective, asthey 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 testingfrom the business perspective

Planning/management 2. Planning is extremely high risk and optimistic Project deliverables might fail3. Lack of contingency4. No real support time built in5. 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 theprocess in process management, escalationand closure

Time delays

8. Lack of analysis reviews and improperrequirement specifications usage

Serious problems of specific requirement omissionthat would not be identified until the system oracceptance test stages

Testing 9. Testing team has lack of business knowledge(see also Risk No. 1) and time (see also RiskNo. 2) to complete testing activitiessuccessfully

Project deliverables might fail time savings ontesting activities’ account can result in low qualityproducts

10. Gap in problem prioritization Improper time expenditure


64


Table 2. Success criteria evaluation

Budget conformity

Project type Overrun

Nooverrun (%)

1–30% 31–200% Over200%

Software development 53 21 0 5Softwareimplementation

5 0 0 0

Software maintenanceand improvement

10 5 0 0

Calendar plan conformity

Project type Overrun

Nooverrun (%)

1–30% 31–200% Over200%


5 0 0 0


10 5 0 0

Customer satisfaction

Project type Evaluation

High(%)

Average(%)

Low(%)

Unknown(%)


0 0 0 5


15 0 0 0

3.3. How are the Global Projects Managed?

Distributed project management is an outstandingchallenge. It is essential for each project to buildan effective project management structure, whichcan help in managerial and performance riskminimization. XYZ together with its major partnerfrom Western Europe developed guidelines fordistributed project organization, considering thefollowing management structures:

• Steering Committee (SC), whose main taskis strategic and 6-month project assignmentplanning, as well as overall cooperation processmonitoring;

• 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 5Project manager on the partner’s side 68 32SC 32 68UCCB 26 74PCCB 21 79

• Project Level Change Control Board (PCCB),whose main task is to ensure qualitative andpunctual work in compliance with the require-ments stated in Statement of Work, as well aschange control;

• Project managers from both sides, whose maintask is to provide operational management andproblem reporting for upper management.

The questionnaire aimed to clarify if the projectsactually use these structures. The results weresurprising – these guidelines are followed by lessthan a half of the projects (see Table 3).

Specifying the results, several facts have to beemphasized. It was interesting that there was onlyone project with all the organizational structures inplace. The projects with the partners from WesternEurope, who developed these management guide-lines, either had no organizational structures as SC,UCCB, and PCCB, or had no information aboutthem. Taking into account that the questionnairewas filled by project managers, it was surprisingthat some of them were not aware of upper organi-zational structures. This fact points out an issue forfurther investigation, aiming to clarify, how deepthe partnership between the parties involved is inthese projects.

Other project management activities as processmanagement and risk management are discussedin 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 distributedprojects among the partner and the offshore devel-oper. Analyzing XYZ data about projects whereXYZ is participating as a subcontracting party (14projects), the following results were derived (seeTable 4).

The results of the questionnaire show a varietyof answers. Accordingly, the following conclusions


65


Table 4. Responsibility share

Responsibilities XYZ(%)

Partner(%)

Both(%)

Quality control 28 22 50Project control 7 50 43Project coordination 43 43 14Responsibility for project results 14 43 43Covering of expenses 22 71 0Project effort estimation 28 43 28Communication with the end customer 0 78 14

can be drawn. Both parties are responsible for qual-ity management in half of the projects. Projectcontrol is either partner’s responsibility (50%) ora shared activity (43%), while responsibility forproject 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 theone who covers all the expenses (71%), estimatesthe project effort (43%), and communicates with theend customer (78%). Predictably, an offshore entityis never responsible for communication with theend customer, and only in 14% cases it appears tobe a shared activity.

There were projects where the partner was fullyresponsible, as well as projects where most of theactivities were shared. Common activity sharingand sharing of goals indicates a close relationshipamong the participants of the project.

3.5. How is the Software Produced in aDistributed 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 developmentprocess distribution and methodologies used. Themodels were then analyzed in order to understand

whether each model is successful or not, consideringthe following questions:

• What was the quality of systems requirementspecification; design specification?

• How easily were requirements clarified duringthe project?

• Were there joint development teams?• Did the offshore developer meet the end cus-

tomer?

The software product implementation and softwaremaintenance project was not included in theanalyses; therefore the results contain informationabout 17 software development or improvementprojects.

The first model was followed by five projects.This first model (see Figure 2) describes the softwaredevelopment cycle, in which systems analysis anddesign stages are done by the partner. The offshoredeveloper is involved in the development stageas a member of a joint system development team.Testing is performed either by the partner (twocases) 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 theseprojects were successful, although in two projectsthe offshore team never met the end customer, andin one project requirement clarification during theprojects was troublesome. The other project endedwith 1–30% deviation in budget and time, never-theless, achieving good customer satisfaction. Theproject manager reported that XYZ was a smallpart of a huge multidistributed team and the majorproblems in the project were connected with systemintegration and testing.

The last project followed incremental approachusing prototyping. This project also ended with1–30% deviation in budget and time, but achievedgood customer satisfaction. Although the offshoreteam had regular meetings with the customer, both

Figure 2. A variation of the first process distribution model (testing is a joint activity)


66


requirement specification and design quality wereevaluated as medium, and requirement clarificationduring the project was troublesome.

There was also a project, where systems analysiswas done by the partner and all the other activities(design, coding, and testing) were performed bythe joint team. Although the results of systemsanalysis and design were evaluated as medium,and the offshore team had never met the customer,the project was successful with no deviations andachieved good customer satisfaction.

The second model (see Figure 3) was followedby 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 wasreported as medium, but design quality in one ofthe projects was high. Requirement clarification inboth projects was easy. This model appears to beone of the most successful, as both projects were onbudget and on time and achieved good customersatisfaction.

There was a variation of the second modelfollowed by one project, where systems analysiswas performed by the offshore team. The teamnever met with the customer in this project. Thequality of requirement specification was evaluatedas low and was possibly the reason for failure.Therefore, the design was further developed jointly.

The project had no deviations and achieved goodcustomer satisfaction.

There was another variation of the second modelfollowed by one project, where the design activitieswere performed only by the offshore team. Thisproject was developed on the prototype basis, therequirement clarification was fast, but the offshoreteam never met the end customer. The project haddeviations in time and budget (1–30%) but the endcustomer was very well satisfied.

The third project model (see Figure 4) wasfollowed by four projects with some variations.Three projects followed prototyping methodologyand omitted the design phase. Systems analysisand development was performed by the offshoreteam and tested by the partner. These projects werespecial because of the close collaboration betweenthe offshore developer and partner, meeting inperson on a regular basis. Therefore, requirementclarification during the project was fast in twoprojects and medium fast in one project. All theprojects were successful (on time, on budget, andachieved good customer satisfaction).

In the other project, design was developed by theoffshore team. This project performed independentfunctional development. Although the offshoreteam organized regular on-site meetings withthe customer, requirement clarification during theproject appeared to be troublesome. Besides, thelow quality of requirement specification appeared

Figure 3. The second process distribution model

Figure 4. The third process distribution model


67


Figure 5. The fourth process distribution model

to be the reason for the project failure. Accordingly,customer satisfaction was low; and the budget andcalendar plan deviations exceeded 200%.

The fourth model (see Figure 5) was followedby two projects. This model described projects,where systems analysis, design and testing activitieswere done by the partner and only the codingwas sent offshore. In both cases, the offshore teamnever met the end customer. One of the twoprojects developed the software on a prototypebasis, with medium software requirement qualityand medium fast requirement clarification, andnever met the customer. The project ended withbudget and calendar plan overrun (1–30%), butthe client was well satisfied. The other projectperformed independent functional development,with fast requirement clarification process, nevermet the customer and appeared to be successful.

There was also a variation of this model followedby one project. The design in this project was per-formed jointly. The project followed incrementaldevelopment methodology, requirement specifica-tion and design quality was evaluated as medium,requirement clarification appeared to be mediumfast, and this offshore team never met the customertoo. 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 importantstep in software development, which if handledinappropriately can cause high cost escalationand calendar deviations. The major factors thateffect systems requirement analysis in a distributedenvironment are communication problems, lackof business knowledge, and organizational andcultural differences. The following are the threeways in which XYZ projects manage systemsrequirement analysis:

• Systems requirement analysis performed byXYZ;

• Systems requirement analysis performed by theremote partner;

• Systems requirement analysis performed jointly.

One of the questions aimed to clarify what isthe quality of requirement specification producedby the partner; XYZ; and both sides jointly. Thequality of requirements was evaluated by projectmanagers according to such factors as stability,completeness, clarity, validity, and feasibility. Thefollowing coherence was derived (see Table 5).

Both the project managers evaluated requirementquality as low, and mentioned that this appearedto be the reason for project failure (both projectsoverrun budget and calendar plan more than 200%).This might have been caused by a lack of businessknowledge, which was emphasized during the XYZpartner inspection.

Unfortunately, 40% of project managers did notgive their requirement evaluation. The existentresults show that joint performance in systemsrequirement analysis appears to be the most suc-cessful (accepted also by other case studies (Heekset al. 2001)), leaving the partners’ independent per-formance in the second place. Yet most of theproject managers evaluated requirement qualityas medium. This indicates that systems analysisperformance is a challenge in a distributed environ-ment and has to be given special attention.

Table 5. Requirement specification quality evaluation

Requirement specificationauthor(s)

Requirement qualityevaluation

High(%)

Medium(%)

Low(%)

Partner 0 15 0XYZ 0 15 10Joint team 5 15 0


68


3.7. How are the Communication LiaisonsEstablished?

Communication is an integral part of any relation-ship. Distribution in space and time is affectedby many interrelated factors as organizational andcultural differences, language skills, and terminol-ogy differences, which are discussed later in thisarticle. Therefore establishing effective communica-tion liaisons between the geographically distributedpartners is an essential part of cooperation in GSD.

The questionnaire was used to clarify whatcommunication tools are used in XYZ distributedprojects 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 oftelephone. E-mail appears to be the most commonmeans of communication (100% of participants usee-mail either every day (58%) or often (42%)), whiletelephone communication follows with only 5% ofparticipants using it every day and 63% using itoften. Using e-mail as a prior means of communi-cation between the distributed partners often leadsto misunderstandings and delays in informationturnaround. According to E. Carmel and R. Agar-wal a small issue can take days of back-and-forthdiscussions over e-mail to resolve, but a brief con-versation can quickly clarify the problem beforeit becomes bigger (Carmel and Agarwal 2001).While there is a lack of personal contact workingin a distributed environment, telephone and elec-tronic means of video and audio conferencing bringhumanity in relationships between the distributedteams. Although the results of the questionnaireuncovered a seldom-used application of moderncollaboration tools, those projects using audio andvideoconferences in their everyday collaborationhave high regard for them.

Table 6. Communication tools used

Communication tools Every day(%)

Often(%)

Seldom(%)

Never(%)

E-mail 58 42 0 0Voice mail 5 5 5 84On-line discussion groups 0 10 21 68Telephone 5 63 26 5Audio conferences 0 10 10 79Video conferences 0 0 0 100Meeting in person 5 16 68 10

The questionnaire has also shown that thepartners rarely meet in person. Nevertheless, noneof the electronic means of communication canprovide an adequate level of confidence for buildingtrust between the distributed partners. XYZ projectmanagers, in discussions, reported that there isa necessity for personal contact at least in thebeginning of the relationship.

3.8. What are the Major Risks in DistributedProjects?

According to the GSD researchers, software devel-opment process distribution brings new challengesand 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 distributedprojects. The questionnaire provided the followingresults (see Table 7).

The most important risk factor according to thequestionnaire results is organizational differences(16% important, 37% medium important) consid-ering such factors as complicated organizationalstructure, many escalation levels, and differentapproaches in responsibility sharing. Many orga-nizations involved in distributed projects are notready to change their internal structure and pro-cesses along with new partners.

Low language skills of XYZ employees, lack ofunderstanding of tasks assigned, cultural differ-ences, and terminology differences are also seen asareas of concern by many projects. These risks are

Table 7. Risk factors

Risk factor Important(%)

MediumImportant

(%)

Unimportant(%)

Time zones 5 21 74Low language skills(XYZ)

10 47 43

Low language skills(other side)

0 5 95

Terminologydifferences

0 32 68

Lack ofunderstanding oftasks assigned

0 63 37

Organizationaldifferences

16 37 47

Cultural differences 5 32 63


69


brought about by geographic distribution, whichcannot be avoided in GSD. With negative out-comes such as delays in time for communication andproblem solution, misunderstandings and commu-nication problems, unexpected costs, and so on, riskmanagement in distributed environment appearsto be a complicated task for both partner and theoffshore developer.

Analyzing the results of the questionnaire, therelationship with the partners nearshore demon-strated relative coherence. On the contrary, thegreater the distance between the partners the moreimportant become the risk factors. Project managersworking with partners at a distance of 4000 kmnamed a set of additional risk factors important intheir 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 projectmanagement practices are necessary for better

performance. One of the further steps of theresearch aims to develop a checklist for distributedprojects, in order to provide appropriate riskidentification.

4. DISCUSSION: WHAT IS THEDIFFERENCE BETWEEN IN-LAND ANDDISTRIBUTED PROJECTS?

Although the set of data gathered during the pre-liminary research is insufficient for factorial analysisand cannot provide statistical minimum it is usedas a case study to derive the hypotheses consideringglobal influence on software development specificsfor the Latvian company XYZ. Summarizing infor-mation gathered with the help of the questionnaireand during informal discussions with the projectmanagers, the following factors and their outcomesfor geographically distributed projects have beenderived (see Table 8).

Project technological organization is essentialfor distributed team support. Practitioners see thenecessity 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 managementProblematic responsibility shareExtra management needed at every location

Lack of personal contact Troubled trust and confidence achievementTime delays for solution turnaround

Time zone difference Problematic asynchronous communicationTime delays for communication and solution turnaround

Organizational differences Complex problem escalationTime delays for solution turnaround

Cultural differences MisunderstandingsCommunication problems

Language difference MisunderstandingsCommunication problemsAvoidance of verbal contact

Terminology differences MisunderstandingsTime delays for terminology clarification and possible rework

Lack of business knowledge Time delays for problem domain clarificationExtra costs for possible rework

Inadequate infrastructure Time delays for communication and solution turnaroundExtra costs for infrastructure improvement

Different understanding of cooperationapproach and related project activities

Troublesome disagreementsTime delaysCommunication problems


70


joint repository implementation for distributedproject data, code storage, problem tracking, andjoint version control. Inadequate infrastructure canhamper communication and collaboration amongthe distributed project members and cause projectfailure.

Finally, the human factors in a distributed envi-ronment are as important as technological fac-tors. The overall project atmosphere, influenced bymany different factors such as cultural and orga-nizational differences, time zones and geographicdistance, plays an important role in successful com-munication in a geographically distributed envi-ronment. According to Rudy Bakalov, ‘culturaldifferences are often the root cause of many ofthe risks discussed (e.g. protection of intellectualcapital and communications) and can create sig-nificant stress in offshore project team members’(Bakalov 2004). Lack of personal contact among theproject members leads to troubled trust; confidenceachievement is not the least objective of projectmanagement. Trust in the relationship enablescooperative behavior, reduces conflicts, decreasestransaction costs, and promotes effective responsesto 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 labeledas ‘us’. Therefore, building a unified team is con-sidered to be one of the ways for various riskmitigations.

All the additional risks and specifics lead tothe conclusion that there is a necessity for newapproaches and practices for project management,communication establishment, process distributionand coordination, in order to provide appropriatemanagement in a distributed environment.

The further steps of the research aim to developa risk management framework, consisting of asoftware development risk identification checklisttailored for global specifics and knowledge basefor best practice accumulation to provide riskmitigation guidance.

ACKNOWLEDGEMENTS

This research is partly supported by the EuropeanSocial Fund and the Latvian Council of Scienceproject No. 02.2002 ‘Latvian Informatics ProductionUnit 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 offshoreapplication and systems development. InformationSystems Control Journal 5: 36–38.

Battin RD, Crocker R, Kreidler J. 2001. Leveragingresources in global software development. IEEE Software18(2): 70–77.

Carmel E, Agarwal R. 2001. Tactical approaches foralleviating distance in global software development. IEEESoftware 18(2): 22–29.

Ebert C, De Neve P. 2001. Surviving global softwaredevelopment. IEEE Software 18(2): 62–69.

Greenwood DJ, Levin M. 1998. Introduction to ActionResearch. Sage Publications: Thousand Oaks, Canada.

Heeks R, Krishna S, Nicholson B, Sundeep S. 2001.Synching or sinking: Global software outsourcingrelationships. IEEE Software 18(2): 54–60.

Kitchenham BA, Pfleeger SL, Pickard LM, Jones PW,Hoaglin DC, Emam KE, Rosenberg J. 2002. Preliminaryguidelines for empirical research in software engineering.IEEE Transactions on Software Engineering 28: 721–734.

Lacity M. 2002. Lessons in global information technologysourcing. IEEE Computer 35(8): 26–33.

Orlikowski WJ. 2002. Knowing in practice: Enactinga collective capability in distributed organizing.Organization Science 13(3): 249–273.

Rousseau DM, Sitkin SB, Burt RS, Camerer C. 1998. Notso different after all: A cross discipline view of trust.Academy of Management Review 23(3): 393–404.

Roy V, Aubert B. 2000. A Resource-Based Analysis of ITSourcing, Scientific Series. CIRANO: Montreal, Canada.

Smite D. 2004. Global software development projectmanagement–distance overcoming. Proceedings of 11thEuropean Conference, EuroSPI 2004, Trondheim, Norway,November 2004, 23–33.

Smite D, Borzovs J. 2004. Global software developmentprocess management: Problem statement. Proceedings of16th International Baltic Conference Baltic DB&IS 2004Doctoral Consortium, Riga, Latvia, June 6–9 2004, 198–207.

Willcocks L, Fitzgerald G. 1994. A Business Guide toOutsourcing Information Technology, A Study of EuropeanBest Practice in the Selection, Management and Use of ExternalIT Services. Business Intelligence: Wimbledon, London,372, ISBN 1 898085 10 2.


71


APPENDIX 1


72



73



74



75



76

global software development projects in one of the biggest companies in latvia: is geographical...

Documents