understanding a lack of trust in global software teams: a multiple-case study

SOFTWARE PROCESS IMPROVEMENT AND PRACTICESoftw. Process Improve. Pract. 2008; 13: 217–231

Published online 12 June 2008 in Wiley InterScience(www.interscience.wiley.com) DOI: 10.1002/spip.378

Understanding a Lack ofTrust in Global SoftwareTeams: A Multiple-caseStudy

Research SectionNils Brede Moe1*,† and Darja Smite2

1 SINTEF Information and Communication Technology, NO-7465Trondheim, Norway2 University of Latvia, LV-1050, Raina bulv.19, Rıga, Latvia

Many organizations have turned towards globally distributed software development (GSD) intheir quest for cheap, higher-quality software that has a short development cycle. However,this kind of development has often been reported as being problematic and complex tomanage. There are indications that trust is a fundamental factor in determining the successor failure of GSD projects. This article studies the key factors that cause a lack of trustand the effect of lacking trust and present data from four projects in which problems withtrust were experienced. We found the key factors to be poor socialization and socio-culturalfit, increased monitoring, inconsistency and disparities in work practices, reduction of andunpredictability in communication; and a lack of face-to-face meetings, language skills, conflicthandling, and cognitive-based trust. The effect of lacking trust was a decrease in productivity,quality, information exchange and feedback, morale among the employees, and an increase inrelationship conflicts. In addition, the employees tended to self-protect, to prioritize individualgoals over group goals, and to doubt negative feedback from the manager. Further, themanagers increased monitoring, which reduced the level of trust even more. These findingshave implications for software development managers and practitioners involved in GSD.Copyright 2008 John Wiley & Sons, Ltd.

KEY WORDS: trust; global software development; global software teams; virtual teams; multiple-case study

1. INTRODUCTION

Many organizations have turned towards globallydistributed software development (GSD) in theirquest for cheap, higher-quality software that has ashort development cycle. Nowadays, GSD is becom-ing the norm (Damian and Moitra 2006). A GSD

∗ Correspondence to: Nils Brede Moe, SINTEF ICT, NO-7465Trondheim, Norway†E-mail: [email protected]

Copyright 2008 John Wiley & Sons, Ltd.

team consists of distributed members who collabo-rate on a common software project while workingacross geographic, temporal, cultural, political, andorganizational boundaries to accomplish an inter-dependent task (Smite and Borzovs 2006). Sucha working environment presents significant chal-lenges with respect to communication, coordina-tion, and control (Agerfalk and Fitzgerald 2006).Therefore, GSD is recognized as being consider-ably more complex to manage than even the mostcomplex in-house project (Karolak 1998, Carmel1999).

Research Section N. B. Moe and D. Smite

Although a body of knowledge on GSD has beenbuilt up, much work remains to be done for it tobecome a mature discipline: understanding mustbe deepened, methods and techniques must bedeveloped, and practices must evolve and improve(Sahay et al. 2003, Damian and Moitra 2006).

According to Martins et al. (2004), GSD teamscan be characterized as virtual teams. It is believedthat trust is a fundamental factor in determiningthe success and failure of virtual teams (Grabowskiand Roberts 1999, Kanawattanachai and Yoo 2002,Martins et al. 2004). Therefore, it is reasonable tobelieve that trust is also important for GSD teams.

The objective of this article is to understand theimportance of trust in GSD by describing the keyfactors that lead to a lack of trust, and the effect thata lack of trust has on a GSD team. To the best of ourknowledge, the existing literature does not addressthese issues. Several related studies have confirmedthis (Edwards and Sridhar 2003, Ali-Babar et al.2006). The core research questions are therefore:

• What are the key factors that cause a lack of trust ina GSD team?

• What is the effect of a lack of trust on the performanceof a GSD team?

The remainder of the article is organized asfollows. In Section 2, we first present backgroundinformation on how work is coordinated in softwaredevelopment, and how this is related to GSD andtrust. Then we use the literature to describe theeffect of a lack of trust on GSD teams and to identifyseveral factors that work against the developmentof a high level of trust. In Section 3, we describe ourresearch method in detail. In Section 4, we presentthe results of our investigation of the role of trustin four projects in a Latvian software company,according to both the findings in the literatureand the additional findings from the multiple-casestudy. We discuss our findings in Section 5. Section6 concludes and provides recommendations on howto avoid trust-related problems in GSD teamwork.

2. BACKGROUND

2.1. Coordinating Work in SoftwareDevelopment Teams

Software development processes depend signifi-cantly on team performance, as does any processthat involves human interaction. Two important

factors related to group performance are feedbackand communication (Guzzo and Dickson 1996).According to Mintzberg (1989), there are three basicmechanisms that describe the fundamental ways inwhich work can be coordinated:

1. Mutual adjustment – based on the simple pro-cess of informal communication, achieved bya continuous exchange of information amongparticipants;

2. Direct supervision – one person takes responsi-bility for the work of others by issuing instruc-tions and monitoring their actions;

3. Standardization – of which there are four types:work processes, output, skills (as well asknowledge), and norms.

The coordinating mechanisms may be consideredas the most basic elements of structure, the glue thatholds the organization together (Mintzberg 1989).Mutual adjustment and direct supervision can becategorized as coordination by feedback (Groth1999), where coordination is adjusted continuallyas people observe the effects of their own andothers’ actions. Standardization can be categorizedas coordination by programme (Groth 1999), wherecoordination is effected through instructions andplans generated beforehand. The mechanisms mayact as substitutes for each other to some degree,but all will typically be found in a reasonably well-developed organization.

A software organization often deploys experts inmultidisciplinary teams that carry out projects ina complex and dynamic environment. Such orga-nizations can be classified as innovative, wheremutual adjustment is the most important coordi-nating mechanism (Mintzberg 1989). The managersshould avoid rigid control (direct supervision),which impairs creativity and spontaneity (Takeuchiand Nonaka 1986). Given that innovation meansbreaking away from established patterns, innova-tive organizations should not rely on standardiza-tion as the primary mechanism of coordination.

However, given that mutual adjustment in itspure form requires everyone to communicate witheveryone, the team or network needs to be compact(Groth 1999).

Nowadays, GSD relies mainly on formal mech-anisms (standardization), which rely on detailedarchitectural design and plans, to address imped-iments to team communication that result fromgeographical separation (Agerfalk and Fitzgerald

Copyright 2008 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2008; 13: 217–231

218 DOI: 10.1002/spip

Research Section Understanding a Lack of Trust in Global Software Team

2006, Ramesh et al. 2006). The limited opportunitiesfor personal contact and constant feedback make itdifficult to use mutual adjustment as the principalmechanism for coordination.

2.2. Global Software Development Teams andTrust

Trust is believed to be a fundamental factor forthe success or failure of virtual teams (Grabowskiand Roberts 1999, Kanawattanachai and Yoo 2002,Martins et al. 2004). We define trust as (Mayer et al.1995) follows:

‘‘the willingness of a party to be vulnerable to theactions of another party based on the expectationthat the other will perform a particular actionimportant to the trustor, irrespective of the abilityto monitor or control that other party’’ (p. 712).

Trust in virtual teams has been studied for a longtime, and the effect is well documented. Virtualteams that exhibit a high degree of trust experiencethe following (Jarvenpaa and Leidner 1999):

• significant social communication;• predictable communication patterns;• substantial feedback;• positive leadership;• enthusiasm;• ability to cope with technical uncertainty.

Given that a high degree of trust yields significantsocial communication, predictable communicationand feedback, we conclude that trust is a prerequi-site for effective mutual adjustment and is thereforenecessary for achieving effective coordination ofwork, which is important for cooperation and per-formance (Jarvenpaa et al. 2004). Jarvenpaa et al.(2004) also argue that an increase in trust in teamsthat have a weak structure is likely to have a directpositive impact on team members’ attitudes andperceived outcomes.

Davidson and Tay (2003) and Vanzin et al. (2005)argue that trust is a recurring problem in GSD teams,because of geographical, temporal, organizational,cultural, and political differences among the teammembers. Carmel (1999) argues that distance is animpediment to building relationships of trust andthat dispersed teams meet infrequently or never.Ramesh et al. (2006) studied three GSD companiesand found that the trust built between the teams

helped to limit the formality with which agreementswere specified and thus enabled the developmentteams to adapt rapidly to the changing needs ofthe project. Humphrey (1989) argues that when atrusting relationship is assumed, the developmentprocess has a new degree of freedom; requirementscan be handled more sensibly and a great deal ofexpensive documentation can be avoided.

2.3. The Effect of Lacking Trust

Using a review of the literature as a basis, Salaset al. (2005) argue that mutual trust is neededfor the team members to work interdependently.They must be willing to accept a certain amountof risk to rely on each other to meet deadlines,contribute to the team task, and cooperate withoutsubversive intentions. Dirks and Ferrin’s (2001)review of the literature on the role of trust inorganizational settings demonstrates that trust haseither a direct or moderating effect on a varietyof variables that pertain to desired performanceand behavioural outcomes. In their view, trustfacilitates the effects of other determinants onperformance or behavioural outcomes because itprovides conditions under which certain outcomesare more likely to occur. Bandow (2001) arguesthat a lack of trust within the group may interferewith how effectively individuals contribute toteams, reduce overall team performance, increasecycle time, create higher costs, and affect productquality.

Several effects of lacking trust have been iden-tified. If one does not trust a partner, it might bedifficult to work towards the joint goal and it islikely that the employees will pay more attentionto competitive motives and not to cooperation (Dirksand Ferrin 2001), and even withdraw from partici-pation because they feel insecure (Bandow 2001). Inaddition, in a low trust situation, the individuals ina group will direct their efforts towards individualgoals rather than the group’s goals (Dirks and Ferrin2001), and task conflict within a group is interpretednegatively and subsequently results in relationshipconflict (Dirks and Ferrin 2001, Salas et al. 2005).

If individuals do not trust their manager, theyfind it difficult to behave as expected; and themanagement’s request is likely to exert a muchweaker effect on their behaviour, because theydivert resources to self-protection (Dirks and Ferrin2001). In addition, when a manager in whom


DOI: 10.1002/spip 219


employees have little trust gives negative feedback,it is likely that the employees will doubt the accuracyof the feedback (Dirks and Ferrin 2001, Salas et al.2005). This will hinder the team leader frommanaging the team effectively.

A low level of trust is also associated withsuspicion about information, and therefore lowtrust will result in reduced information exchange andfeedback (Bandow 2001, Dirks and Ferrin 2001, Salaset al. 2005).

In a low-trust situation, there will be a fall-off inthe mutual monitoring of performance. Such mon-itoring facilitates common understandings of theteam environment and the accurate monitoring ofteam members’ performance. Mutual performancemonitoring is thus essential for identifying mis-takes and lapses in other team members’ actions,and for providing feedback regarding actions on thepart of team members that facilitates self-correction(Salas et al. 2005). A fall-off in mutual performancemonitoring will affect all these factors negatively.It will also affect the ability to anticipate otherteam members’ needs through accurate knowledgeof their responsibilities (back-up behaviour). Thisincludes the ability to shift workloads among membersto achieve balance during periods of high workloador pressure (Carmel 1999, Salas et al. 2005).

Given that a lack of trust affects team performancenegatively (Bandow 2001, Dirks and Ferrin 2001,Salas et al. 2005), productivity and quality will alsosuffer.

2.4. Key Factors Causing Lack of Trust

The means by which trust is established in a GSDteam differ from how it is established in an internalsoftware development team, where participantsoften know each other already and are awarethat their future personal relationships will reachbeyond the current project. Trust in virtual teamsneeds to be developed quickly because teams mayonly interact for a short period of time or may beworking on a task that is very important and urgent(Jarvenpaa and Leidner 1999, Kanawattanachai andYoo 2002). Earlier work on trust in the virtualenvironment has found that short-lived teams dodevelop high trust, but that they do so by followinga swift trust model rather than the traditionalmodel of trust development (Jarvenpaa et al. 1998,Jarvenpaa and Leidner 1999). Members of suchteams do not have the time to develop trust in a

gradual and cumulative fashion. Rather, the teammembers act as if trust is present from the start.‘Swift trust’ enables members to take action, andthis action will help the team to maintain trust anddeal with uncertainty, ambiguity, and vulnerabilitywhile working on complex interdependent taskswith strangers in a situation of great time pressure(Jarvenpaa et al. 1998).

Several factors that affect the level of trust ina virtual team have been identified. In order forteam members to maintain/strengthen trust invirtual teams, it is important for them to socialize(Jarvenpaa and Leidner 1999, Kanawattanachai andYoo 2002). Therefore, team members should travelto remote sites to engage in a team-building activityto maintain/strengthen trust (Rocco 1998).

For both developing and repairing trust in virtualteams, face-to-face meetings are considered irreplace-able (Carmel 1999, Piccoli and Ives 2003, Bhat et al.2006). Face-to-face contact is the richest communi-cation channel we have, and any electronic channelis significantly poorer (Groth 1999). Hence, if thereis no face-to-face communication in a virtual team,this tends to hinder effective communication. Forexample, when team members communicate aboutmutual responsibility and obligations, different per-ceptions of their commitments may develop. Thiscreates a potential for trust to decline (Piccoli andIves 2003). In fact, Karolak considers lack of trust asa natural consequence of losing face-to-face interac-tion (Karolak 1998).

Virtual teams in a low-trust situation need fre-quent and predictable communication if trust is to grow.Frequent communication is important for provid-ing constant confirmation that team members arestill there and still working (Jarvenpaa et al. 2004). Iffeedback is provided on a regular basis, communi-cation improves, which in turn leads to greater trustand improved team performance (Jarvenpaa et al.1998, Jarvenpaa and Leidner 1999). Team membersmay experience anxiety, or their level of trust maydecline, due to negative interpretations of silence ordelays associated with time differences (Piccoli andIves 2003).

Behavioural controls, such as having membersfile weekly reports and assigning specific tasks, areassociated with a decline in trust (Piccoli and Ives2003). In addition, too much communication mightcause team members to be suspicious that othersare monitoring them and this causes a decline intrust (Jarvenpaa et al. 2004).


220 DOI: 10.1002/spip


Virtual teams need to focus on cognitive-basedtrust (e.g. competence, reliability, and profession-alism) (Kanawattanachai and Yoo 2002), which isalso known as performance-based trust (Sabherwal1999). It is therefore important to provide task-relevant background information to team membersso that they can quickly develop cognitive-based trust.If the remote team does not deliver what is expected,cognitive-based trust will decline.

Conflicts in virtual teams, such as global devel-opment teams, are inevitable (Karolak 1998) and itis often difficult to maintain trust when conflictsamong team members emerge. That being so, anabsence of mechanisms for handling conflict is athreat to building and maintaining trust (Jarvenpaaand Leidner 1999, Kanawattanachai and Yoo 2002).

Culture influences the common understandingbetween teammates due to diversity in people’sassumptions, behaviours, expectations about lead-ership practices, team norms, attitudes towardshierarchy, sense of time, and communication styles(Duarte and Snyder 2001, Herbsleb and Moitra2001). Lack of familiarity with cultural diversity isseen as a barrier to achieving trust (Ali-Babar et al.2006).

3. RESEARCH METHOD

The goal of the research reported herein wasto understand the importance of trust in GSD;hence, it is important to understand the softwarepractitioners’ perceptions of the importance of trustin this context. Therefore, we collected data fromsupply teams that participated in four globallydistributed software projects run by LatSoftware(the company name has been changed for reasons ofconfidentiality). The projects were chosen becausethey all reported problems with trust. Hence, wefocused on investigating the role of trust betweenteams in LatSoftware that worked closely withteams from different companies outside Latvia,and between teams in LatSoftware with differentlocations.

We report on a multiple-case holistic study (Yin2003), in which we studied one phenomenon inseveral projects in one company. In a multiple-case study, each case must be selected carefullyso that it either (a) predicts similar results or(b) predicts contrasting results but for predictablereasons (Yin 2003). We chose option (a) and picked

four global software development projects thatall reported problems with trust. Therefore, theresults from each case should not be regarded asobjects for comparison; rather, they should be seenas complementary findings that work together toenrich our understanding of a lack of trust in globalsoftware teams.

A multiple-case study is considered to yieldmore robust and compelling evidence than evidencegathered through a single case. In addition, it isconsidered that conclusions from multiple casescan be generalized to a greater extent than findingsfrom a single case (Yin 2003).

3.1. Study Context

The context for the research was the Latvian soft-ware development company LatSoftware, situatedin Riga. Latvia has become one of the majorcentres for outsourcing in Europe (Minevich andRichter 2005). LatSoftware was established in thelate 1980s and has been oriented towards the inter-national market, focusing on providing softwareoutsourcing services. LatSoftware has successfullycompleted more than 200 projects in Latvia, West-ern Europe, and Scandinavia. At the time of thestudy, the company got over 380 employees. Webelieve that LatSoftware is a representative exam-ple of typical outsourcing partners from Latvia,because they have been involved in GSD for severalyears.

While LatSoftware was extending its operationinto global markets, quality certification was givena high priority. A new system for managingquality has been implemented and the companyhas been certified according to the ISO 9001 : 2000standards. The quality management system consistsof descriptions of processes and procedures forsoftware development, methodological guidelines,templates and forms (for example project plans,contracts, and requirements specifications), jobinstructions and administrative reports. There aremore than 500 documents and around 100 processdescriptions. The system’s use is mandatory for allprojects.

3.2. Data Sources

We used multiple data sources (see Table 1): qual-itative interviews with project participants, resultsfrom postmortem meetings (Birk et al. 2002), and


DOI: 10.1002/spip 221


Table 1. Data sources

Proname

Duration Project type Team locationa andTeam size

Effort Data collection

A 1995–present SW product developmentand maintenance

DE(3) + LV(5) 46080 hours Interviewed current project manager,previous project manager andone developer

Problem checklistsB 2002–2006 SW product development UK(13) + LV(16) 40480 hours Interviewed project manager and

three team leaders.Postmortem analysisProblem checklists

C 2006 SW pilot productdevelopment

SE + LV(3) 320 hours Interview with project manager

Problem checklistsD 2005 SW product development NO(2) + LV(6) + LV(5) 11680 hours Interview with project manager, system

analysts and testing team managerfrom Riga

Group interview with the remote teamfrom Rezekne

Postmortem analysisProblem checklists

a DE, Germany; LV, Latvia; UK, the United Kingdom; SE, Sweden; NO, Norway.

project problem reports. We interviewed projectmanagers from Latvia because they were able toprovide a broad perspective on issues of collabo-ration, acting as communication hubs between thesupplier and customer teams. In addition, projectsA and D allowed us to conduct interviews withother project members. Talking to project memberswithout a project manager’s involvement provideda richer view of the projects. Owing to the limitedavailability of team members, it was not possible tointerview project members from projects B and C.For projects B and D, we also used results from post-mortem meetings (Birk et al. 2002). A postmortemmeeting involves every team member. It focusesfirst on describing what went well and what did notwork in the project, then on conducting a root-causeanalysis of the main issues that are identified. Usingpostmortem meetings, it was possible to identifythe root causes of problems related to trust. Post-mortem meetings for projects A and C were notpossible, because project managers did not acceptspending more resources on the project. The min-utes from the postmortem meeting was sent to theparticipants for approval. Project problems werealso recorded using a problem checklist, whichmade it possible to compare findings between theprojects.

We only present data collected from the Latvianteams.

3.3. Data Analysis

For the analysis, we relied mainly on qualitativeinterviews, because these provide a rich pictureof the reasons for, and effects of, a lack of trust.We analysed the data in several steps. First, weread all interviews and postmortem analysis data,and coded the material according to open coding(Strauss and Corbin 1998). During open coding,every passage of the interview was studied todetermine exactly what was said and each passagerelated to trust was labelled with an adequatecode. Then we compared fragments from differentinterviews, but from the same project, that wereassigned the same code (axial coding). In axialcoding, indicators and characteristics for eachconcept are searched for, in order to define thatconcept (Strauss and Corbin 1998).

After the axial coding, we assigned the conceptsto the categories of ‘reasons for lacking trust’ and‘effect of lacking trust’ found in the literature onGSD, teams and virtual teams. We also foundsome new concepts that were not described in thetheory.


222 DOI: 10.1002/spip


For example, we coded: ‘Because I did not trustthem fully I decided to monitor them more’. Thiswas coded as ‘increased monitoring’: an effect oflacking trust. To avoid bias and misunderstanding,the conclusions from our coding were sent back tothe interviewees for approval.

3.4. Threats to Validity

We now discuss briefly the main threats to con-struct validity, internal and external validity, andreliability (Yin 2003).

To increase construct validity, multiple sourcesof evidence were used and the draft case studyreport was reviewed by key informants. For projectC, we collected data from only the project leader(through an interview) and the problem checklist.This was because of the limited access to the otherparticipants in project C. However, we believe thatthe project manager was able to give a complete anddetailed picture of this relatively small project (only320 hours). To support findings regarding qualityand productivity, we also collected measurementdata. However, there was no company standard formeasuring these data, so they are reported unevenlybetween the projects.

A threat to the internal validity of our study is thepotential bias with respect to selecting the projectsthat participated in the study. If the selected groupis not representative of the population studied,internal validity is threatened. To meet this threat,we selected all the GSD projects that had reportedproblems with trust and that were available at thestart of our study.

The threat to external validity is addressed inthis multiple-case study by using literal replica-tion. The four projects represent a replication forunderstanding what leads to a lack of trust, and theeffect of lacking trust, in a GSD team. However, thestudy is limited because it is only validated fromthe viewpoint of LatSoftware developers, not Lat-Software partners. The participants only came fromLatvia; hence, the findings cannot be generalizedwidely to practitioners from other countries. Fur-ther, the projects only involved teams from Europe,which means that the effect of temporal and politicaldiversity on trust could not be observed.

As for reliability, we have described in detail howthe study was performed.

4. RESULTS

We describe four global projects run in the inves-tigated software house, describing why trust waslacking, and the effects of this on each project.

4.1. Project A

4.1.1. OverviewProject A was a long-term ongoing softwareenhancement project with close collaborationbetween five Latvian developers and three rep-resentatives from a German company that wasdeveloping a software product for a customer.

4.1.2. Reasons for a Lack of TrustThe project used modern collaboration tools, suchas video conferencing and instant messaging, exten-sively. However, the Riga team claimed that thisdid not compensate for the necessity of face-to-facemeetings.

The lack of language skills caused time delays,because some of the developers needed to gete-mails translated when written in German. Thisresulted in too little, and unpredictability in, communi-cation, because it took time to translate and answere-mail. The lack of language skills also resultedin a loss of quality in the information exchanged,because there is always some information loss aftertranslation.

There were misperceptions. The Riga team claimedthat their German partners perceived the Riga teamas not fully dedicated to the project and thereforetried to control them by constantly monitoring theirperformance. This situation persisted for 10 years,during which time the German team never visitedtheir Latvian colleagues and there was no possibilityfor socialization. When the two teams finally met,it became evident that the German team did notknow much about their Latvian partner; they weresurprised to see the modern offices with high-levelsecurity and technical equipment. Their perceptionof the remote team members changed and there wasa period when the German and Latvian teams metfrequently. Overall project performance, and teammorale and psychological comfort consequentlyimproved.

However, after the period of improvement,new problems arose. Germans presented high-level ideas with frequent changes without detaileddocumentation. These received a poor response


DOI: 10.1002/spip 223


from the Latvian side, because the corporate cultureof LatSoftware did not support an agile approach.As a result of not meeting deadlines, the Germansbegan to lose their cognitive-based trust. The Germanmanager frequently required LatSoftware to changethe project leader because he did not trust theleaders’ abilities to add value to the project. Socio-cultural diversity that existed between the remotepartners only sharpened the disputes and conflictsthat arose over time.

4.1.3. Effect of Lacking TrustThe lack of trust generated a negative feedback loop.First, the Riga team experienced a radically reducedability to self-correct and started to doubt negativefeedback from the remote partner. This initiatedextensive monitoring from the contracting partner,which in turn affected the level of trust negatively.There was a decrease in information exchange andfeedback, which resulted in the Latvian colleaguesoften claiming that they were not even beinginformed about the important changes in projectdocuments.

When the German partner started to search formore beneficial collaboration partners, the Rigateam was placed in an environment of competi-tion, rather than collaboration. The resultant projectatmosphere influenced team morale and productiv-ity negatively, caused relationship conflicts, and wasthe reason for individual goals dominating over groupgoals. Effort overruns of 50–80% per iteration werereported.

4.2. Project B

4.2.1. OverviewProject B was a software product developmentand enhancement project run by a UK softwarehouse that outsourced part of the programming toLatSoftware. The management in the UK made astrategic decision to involve LatSoftware. However,the Latvian project manager felt that the UK teamrepresentatives who were directly involved in thecollaboration did not like this.

4.2.2. Reasons for a Lack of TrustThe main problem in this project was a missingconsensus on how to cooperate, because of a disparityin work practices and poor cultural fit. For exam-ple, the Latvian team experienced inconsistencyin the development process regarding requirement

and testing. The UK partner seemed to developrequirements according to one method, but testedthe software according to other methods. The Lat-vian project manager also felt that their partner wasunwilling to inform the remote team about changesand deviations in the project plans. The Latvianpartner felt that their UK counterpart was monitor-ing them, rather than working collaboratively.

Another important issue was related to commu-nication and language skills. The desire to cooperatefrom the Latvian side met with total indifferencefrom the other side. Such problems as a dom-inant use of asynchronous communication tools,and unwillingness or slowness on the part of theUK team to respond to suggestions from the Latvianpartner, led to poor and unpredictable communication.Poor language skills among the Latvian team mem-bers also resulted in a need to translate the writtencommunication, which delayed communication.

There was also a problem with cognitive-basedtrust. Performance problems within the new devel-opment environment resulted in unavoidable timedelays. The UK partner perceived this as low pro-ductivity by the LatSoftware team, which reducedthe cognitive-based trust.

Owing to a lack of joint conflict handling, poorsocialization, and lack of face-to-face meetings, it wasdifficult to solve the project problems and to increaseand maintain the level of trust.

4.2.3. Effect of Lacking TrustThe Latvian team came to doubt negative feedbackfrom the continuously indifferent UK partner, anda generally poor work atmosphere ensued. Thisreduced information exchange and feedback causingpoor collaboration and poor morale. In addition, themonitoring increased in the form of an unreasonableamount of reporting. These effects prevented theeffective utilization of resources, which causedperiods with a heavy workload with correspondingovertime and stand-by periods with no work. Thisreduced morale and the motivation to give the clientvalue for money, which again, in the opinion of theLatvian team, reduced productivity.

4.3. Project C

4.3.1. OverviewProject C was a pilot project to evaluate the investi-gated Riga software house as an external provider ofcoding for a software house in Sweden, which has


224 DOI: 10.1002/spip


recently switched to GSD and outsourcing. Theircooperation started by developing a small piece ofsoftware, but the project was later suspended.

4.3.2. Reasons for a Lack of TrustThe most important reasons for a lack of trust weresocio-cultural and organizational differences, disparityin work practices, and a lack of common procedures andtools.

The Swedish partner wanted to start by workingin small increments to check whether their Lat-vian partner could deliver as expected. However,due to the factors just mentioned, both partnersfaced an increasing complexity of distributed mul-titeam management. After joint risk-managementmeetings with the Swedish client, the project man-ager from Latvia reported that the client needed tochange its structure and work practices in orderto adjust to collaborative software developmentprojects. However, the Swedish partner realizedthat they were not ready for such changes in theirown organization, even though this would makeGSD easier.

The level of trust was also affected by too littlecommunication, a missing belief in joint performance,and a lack of socialization and face-to-face meetings.There was also no conflict handling.

4.3.3. Effect of Lacking TrustAccording to the Riga project manager, the client’semployees felt insecure about their jobs, due tothe corporate decision to switch to GSD andoutsourcing. This missing trust in the GSD projectundermined the morale of the Swedish employees,and could be why the Swedish team acted ascompetitors instead of collaborators, thus causing adecrease in productivity for the whole GSD project.Consequently, the client team’s individual goalsdominated over shared project goals.

All task conflicts within the joint team wereinterpreted negatively. Loss of trust and unresolvedconflicts between the teams finally led to a 50% effortoverrun and suspension of the collaboration.

4.4. Project D

4.4.1. OverviewProject D was a complex project that involved acustomer from Norway, a direct supplier from Riga,and a remote team of programmers from Rezekne,a small Latvian town situated in the poorest region,

around 250 km from Riga. The project manager inRiga coordinated both of the LatSoftware teams’activities. We focused primarily on collaborationbetween the two separated teams in Latvia.

4.4.2. Reasons for a Lack of TrustThe main reason for a lack of trust in this project wasproblems with technology and communication betweenthe teams. Despite the fact that the Latvian teamsworked for the same company, the Rezekne team,which worked in a poorer region of Latvia, hadsignificant problems with technology and lines ofcommunication. This poor infrastructure increasedthe number of hours required for compiling code,which resulted in the Rezekne team not deliveringas fast as was expected by the Riga team. Thiswas perceived as low productivity by the Rigateam, which resulted in cognitive-based trust beingeroded. Owing to too little communication, the projectmanager in Riga was not informed about theproblems with technology and their consequencesbefore the end of the project. The problem withcognitive-based trust was exacerbated because therewas little, or a slow, response from the Rezekneteam to project requests from the Riga team. Otherimportant reasons for a lack of trust were the absenceof face-to-face meetings and increased monitoring.Experiencing significant delays in the project, andlittle and unpredictable communication, the Rigaproject manager increased the monitoring to findout what was going on in the remote team, andwhy they did not deliver as quickly as expected.Instead of trying to solve the problems by arrangingface-to-face meetings, the Riga project managersent a representative to investigate the situationin Rezekne. This increased monitoring confirmedthe suspicion on the part of the Rezekne team thatthey were not trusted by the project manager inRiga.

Lack of socialization, conflict handling and face-to-face meetings made it very difficult to improvetrust and solve problems throughout the project.Despite the fact that both teams are situated in thesame country, they also experienced socio-culturaldiversity, which also affected the level of trustnegatively.

4.4.3. Effect of Lacking TrustThe lack of trust in this project increased the Rigaproject manager’s desire to control the remote team.As a result of his attempts at control, the remote


DOI: 10.1002/spip 225


team became self-protective and apprehensive about theRiga manager’s feedback. They also communicated lesswith the Riga manager, prioritized their own goalsover the group goals, and experienced poor morale. Themissing trust, desire to self-protect, and insufficientinformation exchange resulted in an unwillingnessto shift the workload between the two distributedteams, even when problems arose. The amountof unresolved project issues increased and thisresulted in both Latvian teams being poorly motivatedto self-correct, as well as a fall-off in productivityand quality. There was a 12% effort overrun, andthere were serious problems with the quality.The number of bugs uncovered during system(1144) and acceptance testing (220) were consideredsignificant and were more than expected.

4.5. The Effects of, and Key Factors Causing, aLack of Trust in the Projects

In addition to the effect of lacking trust found inthe literature, we found three further effects byanalysing our data:

• Increased monitoring (projects A, B and D) – whenthey lack trust in supplier performance andexperience a lack of direct control due togeographic and temporal distribution, managersstruggle with a desire to control, instead ofcooperating with, the remote teams. It seems thatsome software managers often start with at leasta subconscious fear that the developers cannotbe trusted to perform without close supervisionand control. This results in increased monitoring(Humphrey 1989) and extra time is needed forreporting. A negative feedback loop ensues,because increased monitoring results in a lackof trust, and a lack of trust leads to increasedmonitoring.

• Undermined morale of the employees (all projects) – alack of trust creates a negative atmosphere thatresults in the psychological discomfort of themembers.

• Threat of project cancellation (projects A and C) – wealso found that a lack of trust may put the overallcollaboration in jeopardy.

In Table 2, we present the key effects of lackingtrust that were found in the study

In addition to key factors that cause a lack of trustfound in the literature, we found two further factorsby analysing our data:

Table 2. The main effects of lacking trust found in the projects

The main effects of lacking trust Projects

A B C D

Competition and non-cooperation√ √

Individual goals over group goals√ √ √

Relationship conflict√ √

Implementation of self-protectivemeasures

√ √

Doubting the veracity of negativefeedback from manager

√ √ √

Reduction in information exchangeand feedback

√ √ √

Team fails to self-correct√ √

Workload not shifted amongteam members.

√

Decrease in productivity and quality√ √ √ √

Increased monitoring√ √ √

Undermined morale of the employees√ √ √ √

Threat of project cancellation√ √

• Lack of language skills (projects A and B) – leadsto poor socialization and communication prob-lems, because employees with poor languageskills need to get e-mails and documentationtranslated, and tend to be afraid to speak overthe telephone. A lack of language skills may alsoresult in delays when written documentationneeds to be translated.

• Disparities in work practices – may lead to a lossof cognitive-based trust, create misunderstand-ings, make it difficult to cooperate, and increasemonitoring.

In Table 3, we present the key factors that causeda lack of trust in the four projects that were studied.

Table 3. Key factors causing lack of trust found in the projects

Reason for lacking trust Projects

A B C D

Poor socialization√ √ √ √

Missing face-to-face meetings√ √ √ √

Too little communication√ √ √ √

Unpredictability in communication√ √ √

Increased monitoring√ √ √

Lack of cognitive-based trust√ √ √

No conflict handling√ √ √

Poor socio-cultural fit√ √ √ √

Lack of language skills√ √

Disparities in work practices√ √ √


226 DOI: 10.1002/spip


5. DISCUSSION

We have described the effects of, and reasons for,a lack of trust, and presented a study on this topic.We now discuss our findings.

5.1. Effects of Lacking Trust

The projects were chosen because they all reportedproblems with trust in their GSD contexts. LikeBandow (2001), Dirks and Ferrin (2001) we foundthat when virtual teams lack trust, there may besignificant problems with the performance andbehaviour of the team members. All the projectsreported a decrease in productivity and quality,and that team morale was undermined, as a resultof an absence of trust. This confirms the importanceof trust for overall project performance. In projectsA, B, and D, we also found that there was a decreasein information exchange and feedback because of alack of trust. These findings were probably relatedto team members doubting negative feedback fromtheir manager. When this occurs, it is also likelythey will not respond to the negative feedback.Teams that have problems with communication andnegative feedback find it difficult to self-correct.

An absence of trust is the reason that individualgoals appear to be more important than groupgoals, which reduces the desire to cooperate andincreases the desire to self-protect. We found thatthe managers often responded to a fall-off incooperation by increasing the monitoring of theremote team, because they felt that they were losingcontrol and needed to find out what was really goingon in the remote team. This increased monitoringcaused the level of trust to fall even more, resultingin a negative feedback loop. Some managers usedthe threat of cancelling the project and introducingcompetitors in an attempt to induce the remote teamto work harder. The Germans did this in project A,but contrary to the expected result, morale wasundermined even further. The productivity andquality did not increase and perhaps even decreasedbecause of the threat of cancellation.

Only team D had problems with shifting theirworkload. There could be two reasons for thisfinding: (a) there were no problems in shifting theworkload among the other teams, or (b) shiftingthe workload was never considered in the otherprojects. Several teams reported big time delays intheir project. This situation could probably have

been improved by allowing teams to shift theworkload, but this never occurred probably dueto the problems with information exchange andfeedback, self-protection, competition, and lack ofcooperation.

Our findings demonstrate that a lack of trustcan be devastating for a GSD project and thatthe ensuing problems both create new ones andexacerbate those that already exist.

5.2. Key Factors Causing Lacking Trust

From our study we found that poor socialization,lack of face-to-face meetings, too little communica-tion, and poor socio-cultural fit were reported byall the projects. Lack of face-to-face meetings andpoor socialization are probably related, because itis difficult to socialize if you meet seldom or never.The lack of both face-to-face meetings and poorsocialization reduced the level of communicationand made it unpredictable (projects A, B, and D).On the basis of our results, we believe that theproblem with poor socio-cultural fit may have beenexacerbated by a lack of face-to-face interaction andtoo little socialization. An example, of this is theGerman partner in project A, who waited 10 yearsbefore they visited their Latvian partner and thenwere surprised because they had assumed that theLatvians worked in old-fashioned offices and had afar lower level of security and technical equipmentthan the Germans.

A lack of language skills (projects A and B)resulted in communication problems, because mostof the written documentation and e-mails needed tobe translated. We also found that employees withpoor language skills tend to be afraid of speakingover the telephone. This also made it more difficultto socialize.

Infrequent meetings, if there are any at all,and primarily asynchronous communication arestumbling blocks for dispersed teams. This canbe explained by companies’ intentions to reducetheir costs by all means available (Carmel 1999).The paradox is that most of the clients expect globalteams to be cheap and fast, despite the fact that theirmethods of communicating make the teams slower(Carmel 1999). Misinterpreting the reasons behindlow productivity creates another negative loop andresults in a decrease in cognitive-based trust.

Inconsistency in work practices (projects A, B,and C) may reduce cognitive-based trust because


DOI: 10.1002/spip 227


partners solve tasks in a manner different fromthat which was expected, which results in misun-derstandings. Disparities in work practices and toolittle communication lead to increased monitoring,because the outsourcing partner wants to find outabout and control what is going on when proxim-ity is lacking and they are not fully informed of theproject’s status. A lack of conflict handling (reportedby projects B, C, and D) and too little communica-tion also made it difficult to improve the overalllevel of trust.

LatSoftware is certified according to the ISO9001 : 2000 standards and have received severalnational quality awards. Such certification andrecognition helps to generate what has been termedinitial trust by projecting credibility, convincingclients to trust in one’s capabilities (Ali-Babar et al.2006). However, the effect of initial trust will soonvanish if the projects do not deliver the expectedsoftware on time. In project C, the Swedish partnerselected their GSD partner because of high initialtrust (certificates and quality awards). However,when the results did not meet expectations, theproject was cancelled.

Traditional development models, such as thequality management system used by LatSoftware,are often referred to as plan-driven (Boehm andTurner 2003). Such models are rooted in the ratio-nalistic paradigm, which promotes a product-lineapproach to software development using a stan-dardized, controllable, and predictable softwareengineering process (Dyba 2000). From this per-spective, the standardization of work processes ismore important than mutual adjustment when coor-dinating work in such an organization (Mintzberg1989). Following the plans and specification weremore important than people talking to each otherfrom the perspective of LatSoftware, and this madeit difficult to be flexible and respond to new ideas,as shown by the failure to meet the expectationsof the German partner in project A. We argue thatthe focus on plan-driven development model overmutual adjustment is a further reason for lackingtrust. Fortunately, LatSoftware changed their workpractices and started to work in a more agile wayby basing their communication on mutual adjust-ment. This affected trust positively and the Germansstopped looking for other suppliers. Team perfor-mance also improved and the effort overruns werereduced.

5.3. Recommendations

The reason for the failure of global projects is notthe lack of capability, but a lack of awareness ofthe issues, problems, and barriers associated withglobal work (DeLone et al. 2005). There are severalways in which a high level of trust can be improvedand maintained in global teams. On the basis ofour study, we recommend that a GSD team shoulddiscuss the ‘key factors’ and ‘main effects’ of lackingtrust at an early stage in the collaboration, identifyactions to meet the potential problems and alsoconsider the following measures:

• Invest in several face-to face meetings (Karo-lak 1998, Carmel 1999, Bandow 2001, Bhatet al. 2006, Piccoli and Ives 2003). To increasecognitive-based trust, it is important to presentthe technical standard of the remote part-ner, such as technical equipment, offices, andsecurity routines (Ali-Babar et al. 2006). Social-ization activities for the whole team are alsoimportant (Rocco 1998, Jarvenpaa and Leidner1999, Kanawattanachai and Yoo 2002). This willimprove cultural understanding and make iteasier to create personal relationships, whichare a prerequisite for using mutual adjustmentas a coordinating mechanism.

• Communicate expectations early and establishinitial rules for handling conflicts. This couldbe in the form of a contract or trust structure(Bandow 2001).

• Ensure that the team possesses the expecteddevelopment competence and language skills.This is important for high cognitive trust andbetter communication. The team should bemotivated for the project, and no one should fearlosing their job as a result of the cooperation.

• Consider a software development method thatprovides both flexibility and adaptability, andthat uses frequent communication to make itpossible to coordinate the work by constantfeedback. An iterative method will make itpossible to demonstrate a completed portionof the system several times over (Sabherwal1999), and this will strengthen cognitive-basedtrust. In addition, trust will grow because theteam members will be constantly aware of thestatus of the project (Humphrey 1989). Thedesire for obsessive monitoring will therebydecrease. One possible way of implementing theabove recommendations is to use agile methods


228 DOI: 10.1002/spip


(Agerfalk and Fitzgerald 2006). However, dueto the physical separation of development teamsin GSD, many of the key concepts within agiledevelopment (Dyba and Dingsøyr 2008), suchas pair-programming, face-to-face interaction,and onsite customers, are difficult to implement.Therefore, the software development methodshould probably balance both the agile and plan-driven approach (Ramesh et al. 2006). Make surethat you have a common understanding of thecommon work process. This can be achievedby holding a process workshop (Dingsøyr et al.2004).

• Invest in groupware packages and team intranetto provide effective means of communicationand to compensate for the lack of personalcontact during the project (Karolak 1998, Carmel1999). However, be aware that this will notreplace the value of face-to-face meetings.

6. CONCLUSION AND FUTURE WORK

GSD has grown substantially richer as a disciplineover the past decade. However, for it to mature,much work remains to be done: understandingmust be deepened, methods and techniques must bedeveloped, and practices must evolve and improve(Sahay et al. 2003, Damian and Moitra 2006). Trustis a recurring problem in GSD teams, becauseof geographical, temporal, organizational, cultural,and political differences among the team members.Face-to-face meetings, active communication, andsocialization, which are commonly used for build-ing trust in in-house software teams, are a hardrecipe to follow for global teams, because cost-saving strategies reduce the opportunity to meet.

Drawing upon the related literature, and bystudying four projects that were distributed bet-ween different locations and that had problemsconcerning trust, we were able to identify thekey factors that cause a lack of trust as follows:poor socialization and socio-cultural fit, lack offace-to-face meetings and language skills, absenceof conflict handling and lack of cognitive-basedtrust, increased monitoring, inconsistency in workpractices, and both decrease and unpredictability incommunication.

A lack of trust resulted in a decrease in produc-tivity, quality, information exchange, feedback, andmorale among the employees, and an increase in

relationship conflicts. In addition, the employeestended to self-protect, prioritize individual goalsover group goals, and doubt negative feedback fromthe manager. The subteams also competed insteadof cooperating, and did not shift workload or self-correct. The loss of trust resulted in the managersincreasing monitoring and threatening to cancel theproject, which reduced the level of trust even more.

These and other findings lead to the conclusionthat a company should consider the pros and consof cross-border collaboration and never start adistributed collaboration unprepared. It is not easyfor globally distributed teams to work effectively.An awareness of the importance of trust, the reasonsfor a lack of trust, and the effect of lacking trust willhelp to avoid many problems of joint collaboration.However, it is not a simple matter to achieve a highlevel of trust in GSD teams.

Accordingly, further work should focus on inves-tigating which methods can be applied for buildingand maintaining trust in GSD.

ACKNOWLEDGEMENTS

We appreciate the input received from projectmanagers and other members of the investigatedprojects in LatSoftware. We thank Chris Wright forproofreading and Torgeir Dingsøyr and Tore Dybafor valuable feedback.

This research is supported by the ResearchCouncil of Norway under Grant 181658/I30, theEuropean Social Fund and the Latvian Council ofScience within project Nr. 02.2002.

REFERENCES

Agerfalk PJ, Fitzgerald B. 2006. Flexible and distributedsoftware processes: old petunias in new bowls?Communications of the ACM 49(10): 26–34.

Ali-Babar M, Verner JM, Nguyen PT. 2006. Establishingand maintaining trust in software outsourcingrelationships: an empirical investigation. Journal ofSystems and Software 80(9): 1438–1449.

Bandow D. 2001. Time to create sound teamwork. Journalfor Quality and Participation 24(2): 41.

Bhat JM, Gupta M, Murthy SN. 2006. Overcomingrequirements engineering challenges: lessons fromoffshore outsourcing. IEEE Software 23(5): 38–44.


DOI: 10.1002/spip 229


Birk A, Dingsøyr T, Stalhane T. 2002. Postmortem: neverleave a project without it. IEEE Software, Special Issueon Knowledge Management in Software Engineering 19(3):43–45.

Boehm BW, Turner R. 2003. Balancing Agility andDiscipline: A Guide for the Perplexed. Addison Wesley:Boston.

Carmel E. 1999. Global Software Teams: Collaborating AcrossBorders and Time Zones. Prentice-Hall: Upper Saddle River,NJ, USA.

Damian D, Moitra D. 2006. Global software development:How far have we come? IEEE Software 23(5): 17–19.

Davidson EJ, Tay ASM. 2003. Studying teamwork in globalIT support.

DeLone W, Alberto Espinosa J, Lee G, Carmel E. 2005.Bridging global boundaries for IS project success. 38thHawaii International Conference on System Science. BigIsland, HI, United States: Institute of Electrical andElectronics Engineers Computer Society: Piscataway, NJ;08855–1331.

Dingsøyr T, Moe NB, Dyba T, Conradi R. 2004. Aworkshop-oriented approach for defining electronicprocess guides – A case study. In Software ProcessModelling, Acuna ST, Juristo N (eds). Kluwer AcademicPublishers: Boston, MA; 187–205.

Dirks KT, Ferrin DL. 2001. The role of trust inorganizational settings. Organization Science 12(4):450–467.

Duarte DL, Snyder LT. 2001. In Mastering Virtual Teams:Strategies, Tools, and Techniques that Succeed, 2nd edn, A.W.Company (ed.). Jossey-Bass: San Francisco.

Dyba T. 2000. Improvisation in small softwareorganizations. IEEE Software 17(5): 82–87.

Dyba T, Dingsøyr T. 2008. Empirical studies of AgileSoftware Development: A Systematic Review, Informa-tion and Software Technology, DOI: 10.1016/j.infsof.2008.01.006.

Edwards HK, Sridhar V. 2003. Analysis of the effectivenessof global virtual teams in software engineering projects.

Grabowski M, Roberts KH. 1999. Risk mitigation invirtual organizations. Organization Science 10(6): 704–721.

Groth L. 1999. Future Organizational Design: The Scope forthe IT-based Enterprise. John Wiley and Sons: New York.

Guzzo RA, Dickson MW. 1996. Teams in organizations:recent research on performance and effectiveness. AnnualReview of Psychology 47: 307–338.

Herbsleb JD, Moitra D. 2001. Global softwaredevelopment. IEEE Software 18(2): 16–20.

Humphrey WS. 1989. Managing the Software Process.Addison-Wesley: Reading, MA, XVIII, 494 s.

Jarvenpaa SL, Leidner DE. 1999. Communication andtrust in global virtual teams. Organization Science 10(6):791–815.

Jarvenpaa SL, Knoll K, Leidner DE. 1998. Is anybody outthere? Antecedents of trust in global virtual teams. Journalof Management Information Systems 14(4): 29–64.

Jarvenpaa SL, Shaw TR, Staples DS. 2004. Towardcontextualized theories of trust: the role of trust in globalvirtual teams. Information Systems Research 15(3): 250–267.

Kanawattanachai P, Yoo Y. 2002. Dynamic nature of trustin virtual teams. Journal of Strategic Information Systems11(3–4): 187–213.

Karolak DWJ. 1998. Global Software Development. Wiley:United States – IEEE Computer Society; 172.

Martins LL, Gilson LL, Maynard MT. 2004. Virtual teams:what do we know and where do we go from here? Journalof Management 30(6): 805–835.

Mayer RC, Davis JH, Schoorman FD. 1995. An integrativemodel of organizational trust. Academy of ManagementReview 20(3): 709.

Minevich M, Richter F-J. 2005. Global Outsourcing Report2005. Going Global Ventures and HORASIS: New York,Geneva.

Mintzberg H. 1989. Mintzberg on Management: InsideOur Strange World of Organizations.

Piccoli G, Ives B. 2003. Trust and the unintended effectsof behavior control in virtual teams. Mis Quarterly 27(3):365–395.

Ramesh B, Cao L, Mohan K, Xu P. 2006. Can distributedsoftware development be agile? Communications of theACM 49(10): 41–46.

Rocco E. 1998. Trust Breaks Down in Electronic Contexts butCan be Repaired by Some Initial Face-to-face Contact. ACM:Los Angeles, CA, New York.

Sabherwal R. 1999. The role of trust in outsourced ISdevelopment projects. Communications of the ACM 42(2):80–86.

Sahay S, Nicholson B, Krishna S. 2003. Global ITOutsourcing: Software Development Across Borders.Cambridge University Press: Cambridge.


230 DOI: 10.1002/spip


Salas E, Sims DE, Burke CS. 2005. Is there a ‘‘big five’’ inteamwork? Small Group Research 36(5): 555–599.

Smite D, Borzovs J. 2006. A framework for overcomingsupplier related threats in global projects. EuropeanSoftware Process Improvement (EuroSPI), Proceedings.Springer Verlag: Joensuu, Finland.

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

Takeuchi H, Nonaka I. 1986. The new productdevelopment game. Harvard Business Review 64: 137–146.

Vanzin M, Ribeiro MB, Prikladnicki R, Ceccato I,Antunes D. 2005. Global Software Processes Definition ina Distributed Environment. United States: Institute ofElectrical and Electronics Engineers Computer Society:Greenbelt, MD, Piscataway, NJ; 08855–1331.

Yin RK. 2003. Case Study Research: Design and Methods,3rd edn, Vol. 5. Sage Publications: Thousand Oaks,CA.


DOI: 10.1002/spip 231

understanding a lack of trust in global software teams: a multiple-case study

Documents