Project managers in global software development teams: astudy of the effects on productivity and performance
Ricardo Colomo-Palacios
Cristina Casado-Lumbreras
Pedro Soto-Acosta
Francisco José García-Peñalvo
Edmundo Tovar

Abstract:
Globalization is having a deep impact on today’s world economy. One of the most affected industries is thesoftware industry. Recently Global Software Development (GSD) has gained a lot of attention. This new trend of
producing software is influencing all software processes, including human resource management. The aim of thisstudy is to provide an overview of the implications of GSD for software project managers by analyzing project
performance from different perspectives such as the 360-degree feedback evaluation. Results show that
performance of GSD projects is lower than in-house projects, but apart from that, this study reveals that there arealso negative consequences for Software Project Managers, which need to be taken into account. For instance,
the experiment revealed a lack of attention to tasks by software project managers and, as a consequence of this,performance losses. The main conclusions of this research may be valuable for software development
organizations.

Introduction
Project Management can be defined as the implementation of a collection of tools and techniques to manage theuse of diverse resources for the accomplishment of a unique and complex task, which is subject to time, cost andquality constraints, among others (Olsen, 1971). The project management team is responsible for the project’s
outputs and, hence, must ensure that the project goal and its purposes are fulfilled. To achieve these objectives,internal measures of performance are usually implemented (Dweiri & Kablan, 2006). However, within theliterature, there are no universally agreed measures of project performance. Atkinson (1999) stated that assessing
project processes is essential. Jiang & Klein (2000) suggested that project operations performance must be
calculated in terms of costs, time, and productivity.
Regarding the software industry, effective and efficient management of information technology (IT) projects has
been suggested as a critical factor for software development companies (Disterer, 2002). Boehm and Ross (1989)
considered that software project management is not easy, but an art, and defined it as the skillful integration ofsoftware technology, economics and human relations in the specific context of a software project. What makes
software project management so complex is the need to deal with personal, team and organizational resources(Rose, Pedersen, Hosbond, & Kræmmergaard, 2007). Software projects measures of performance include
whether the project is implemented on time and to budget (Kunda & Brooks, 2000).
Today, the development of software has evolved from its traditional manner (in-house development) to so called
Global Software Development (GSD). In this scenario, software project managers’ skills are more crucial for the
success of software development projects, since GSD adds problems and complexities to an already complex
process: software development (García-Guzmán et al., 2010, García-Guzmán et al., 2011). In spite of theimportance of this topic, to date no study has evaluated the effect of GSD practices on the performance ofsoftware project managers. In an effort to fill this research gap, this paper studies the effects of GSD setups on
the performance of the software project manager. In addition, it analyzes the productivity differences between
software development projects applying in-house software development and those applying GSD. The remainderof this manuscript is structured as follows. Next, the relevant literature in the research area of GSD and its
implications for productivity and performance are outlined. Then, the characteristics and results of the study
conducted are described and, finally, conclusions and future research proposals are offered.

Related literature
Distributed software development (DSD) is nowadays a common practice within the software industry(Hernández-López et al., 2010b). GSD is now as popular as project management or requirements engineering forthe software and IT industries (Ebert, 2012). GSD involves the development of software applications through theinteraction of people, organizations and technology across nations with different backgrounds, languages andworking styles (Herbsleb & Mockus, 2003). GSD is a particular type of DSD in which teams are distributed
beyond the limits of a nation (Herbsleb & Moitra, 2001). In this sense, GSD teams can be considered as a

specification of virtual teams (Martins et al., 2004). There are many similar terms reported in the literature thatdeal with this issue, such as offshore software development (e.g. Carmel & Tija, 2005; Khan, Niazi & Ahmad,
2011; Nicholson & Sahay, 2004; Robinson & Kalakota, 2004), global software engineering (Ebert, 2012), global
software work (e.g. D’Mello & Sahay, 2007; Damian & Moitra, 2006; Smite & Wohlin, 2011), 24-hourdevelopment teams (Gupta et al., 2009; Gupta & Seshasai, 2007; Jalote & Jain, 2006; Sooraj & Mohapatra,
2008), follow the sun and round the clock (e.g. Carmel & Agarwal, 2001; Colazo & Fang, 2010; Gupta, 2009)
and GSD.
GSD implies that software engineers collaborate over geographic, temporal, cultural and linguistic distances.
These characteristics are usually termed as “global distance” (Noll, Beecham & Richardson, 2010). The
literature has reported several benefits associated with GSD adoption such as: greater availability of humanresources and multi-skilled workforce (e.g. Conchuir et al., 2009; Kommeren & Parviainen, 2007; Milewski etal., 2008), lower costs (e.g., Crow & Muthuswamy, 2003; Krishna et al., 2004; Ramasubbu et al., 2005; Smite etal., 2010) and shorter time-to-market cycles (e.g. Clott, 2004; Jalote & Jain, 2006; Kommeren & Parviainen,
2007, Sooraj & Mohapatra, 2008). However, the literature has also found that companies implementing GSD
face many challenges. The most important challenges are related to: communication, coordination, and control(e.g. Avritzer et al., 2010; Casey & Richardson, 2009; Conchuir et al., 2009; Cusumano, 2008; García-Crespo etal., 2010), efficiency (e.g. Kommeren & Parviainen, 2007, Milewski et al., 2008, Rogers & Lea, 2005), trust (e.g.
Barczak et al., 2006, Hernández-López et al., 2010a; Oza et al., 2006) and socio-cultural distance (e.g. Ali
Barbar et al., 2007; Layman et al., 2006, Prikladnicki et al., 2003), among others. In sum, and in the words ofMilewski et al. (2008), GSD poses something of a paradox: some stated that GSD is highly productive whileothers assert that GSD teams perform sub-optimallyWith regard to GSD productivity and performance, which is the main focus of this paper, there is still no recipe
for successful and efficient performance in globally distributed software engineering (Smite et al., 2010).
According to Kormeren and Parvianen (2007), the productivity of globally distributed team members decreases
by up to 50% compared to that of co-located team members. Moreover, the delivery of software products
developed in globally distributed environments take two and a half times as long as in a co-located environment(Hersleb & Mockus, 2005). These and other studies (e.g. Conchuir et al., 2009; Casey & Richardson, 2009)
report differences on productivity aspects among GSD project members. However, authors are not aware of any

study that has analyzed the effect of GSD practices on the performance of software project managers. Thus, ourresearch question is:
What effect does GSD have on software project managers' performance?

A study on the effects of GSD on software project managers' performance
DesignAs stated above, many of the productivity metrics related to software development projects are based on code
generation. However, the main responsibility of software project managers is not related to code generation.
Therefore, productivity metrics must be based not only on group productivity, but also on other factors related to
managers’ performance. To address these issues, this study uses conventional productivity metrics for software
projects, more specifically, function points (Albrecht & Gaffney, 1983). Function points measures are gathered
together with other project measures like planned project duration, actual duration, total personnel, required
effort, productivity (function points per effort unit) and defects per function point.
Apart from this, authors selected 360-degree feedback to get some feedback about the performance of project
managers. The latter comprises a process in which peers, supervisors and other external sources provide
anonymous feedback (Atwater & Brett, 2005). This tool provides reports from multiple sources and has becomea fundamental tool for human resource management (Massingham et al., 2011). The 360-degree feedback
provides comprehensive performance evaluations by considering all those individuals that may reasonably
comment on the individual evaluated, and these include self-assessment, assessment from below(subordinates/staff), assessment from peers or co-workers and assessment from external agents (Church, 2000).
Here, the authors selected this evaluation method because of its widely recognized importance andappropriateness in assessing managers’ performance. This technique presents significant relationships withperformance predictors (Beehr et al., 2001) and has been shown to be a reliable and valid measure of managerial
performance (Brutus et al., 1998).
Data was collected from a sample of software project managers. Two projects were considered for each software
project manager. This setup permits the comparison between the two projects. All the projects included a local
team and an offshore team.

Sample Description

The study presents two different samples. The first is the sample of project managers assessed and the second is
the sample of project managers’ assessors that perform the 360-degree feedback.
The first consisted of eight software project managers in charge of managing GSD projects from four different
companies (three Spanish and one French IT companies). Two different projects were considered for eachindividual. All the projects (sixteen) included two subprojects, one applying in-house software development andother using offshore software development. Two participants were women (25%) and six were men (75%). The
average age of the managers was 39.38 years. Participants were obtained from those who responded positively toa personal invitation sent by the authors to contacts working in Spanish and French IT companies. Regarding
partners, up to six different partners developed these sixteen projects, from Argentina, Brazil, Canada, Chile,
Costa Rica and India. The relationship among companies is contractual and the distribution of work among
partners is ruled by work package assignation. The aim of six of the sixteen projects was to develop a software
product or an evolution of it and the remainder aimed to develop bespoke software.
To perform the 360-degree feedback, eight teams of five members each were formed (the manager’s supervisor,
one peer, two local team members working on the projects and one local customer). This setup does not include a
member of the offshore teams, as was intended, because authors were not able to get an affirmative answer froma significant set of offshore teams. Overall, forty participants were interviewed (eight supervisors, eight peers,
sixteen local team members and eight customers), of which thirty-one were men (77.5%) and nine were women(22.5%). The average age of the stakeholders was 38.35.

Data Collection
Data collection was conducted through a questionnaire that gathered information from two groups of measures:software project productivity measures and 360-degree feedback applied to measure software project managers’
performance. The former referred to measures concerning software productivity from two different andconsecutive projects for each software project manager, including metrics for in-house and offshore teams. In allcases, an offshore company participated in both projects. These data were available in post-mortem documents
related to these projects, which were facilitated by participating companies and were included in both projects
questionnaires. Data included planned duration, actual duration, personnel, effort required, function points,
productivity (function points per unit of time) and quality conformance (number of defects per function point).
The last, the 360-degree feedback, considered questions regarding a set of five different stakeholders (themanager’s supervisor, one peer, two local team members working on the projects and one customer) who
assessed the software project manager’s performance. Responses were codified using a 1-5 Likert-type scale(1=Strongly disagree; 2= Disagree; 3=Neither agree nor disagree; 4= Agree; 5=Strongly agree). The statements
were devised to address all project managers’ tasks, including a final question to assess the performance as awhole. The statements included in the questionnaire were:
1. I found the software project manager more accessible and open during the GSD project time than inprevious non GSD projects
2. The coordination of the project team was corrected by actions of the software project manager
3. The software project manager controlled the whole project in a proper way
4. The software project manager provided positive and negative feedback to team members during the
project
5. The software project manager solved conflicts during the development of the project
6. The software project manager assumed his or her responsibilities during project time
7. The software project manager’s decisions were adequate
8. The software project manager’s attitudes and decisions provided the means for a proper knowledgetransfer during the project
9. The project setup caused the software project manager to neglect other aspects of his/her work
10. GSD approach affected the software project manager ’s performance in a negative way
Printed questionnaires were designed to be completed by the participants (software project managers and the fivestakeholders), who were assisted on site by a researcher who gave the respondents all the instructions they needto fill out the questionnaire. Subsequently, responses were codified using a statistical analysis software tool.
Threats to Validity
With respect to internal validity, the threat comes from the fact that the respondents may not have comparable
levels of knowledge or expertise. Given that respondents were in all cases chosen because of their expertise andexperience, the authors made sure that both project managers possessed a comparable level of knowledge andexpertise. Concerning external validity, the authors assumed two possible threats. The first threat is theundeniable limited number of respondents and organizations; this fact complicates the generalization of theresults obtained in the study. The second threat is the fact that the sample was not taken randomly. Even thoughthese threats exist, the sampling method and the number of respondents may be acceptable given the exploratory
nature of the study.
Finally, regarding construct validity, a pilot questionnaire was made prior to the final implementation of theconstruct. The sample for this pilot implementation was composed of two software development project
management experts. The objective of this pilot study was the improvement and assurance of the associateddocumentation. This resulted in several changes in the wording of some texts.

Resultsa) Productivity Metrics
Results related to software engineering with regard to the first and the second consecutive projects for the eightproject managers are presented in Table 1. As stated before, each project has two teams: in-house and offshore.
Duration was measured in months, effort was assessed in units of time (months) per human resource, productivity
was computed by function points per effort unit and quality was measured as defects per function point.
Differences between in-house and offshore teams for each project and for each analyzed variable are shown in
Table 1. Each variable is analyzed in detail in what follows:Table 1. Project 1& 2 outputs for In-house and Offshore teams.

P
R
O
J
E
C
T
1

P
R
O
J
E
C
T
2

IN-HOUSE
Planned duration
Actual duration
Personnel
Required effort
Function points
Productivity
Defects per Function PointOFFSHORE
Planned duration
Actual duration
Personnel
Required effort
Function points
Productivity
Defects per Function Point
IN-HOUSE
Planned duration
Actual duration
Personnel
Required effort
Function points
Productivity
Defects per Function PointOFFSHORE
Planned duration
Actual duration
Personnel
Required effort
Function points
Productivity
Defects per Function Point

PM1

PM2

PM3

PM4

PM5

PM6

PM7

PM8

14
16
7
85.5
376
4.40
4.52

16
17
6
85.2
387
4.54
3.75

12
14
9
108.4
499
4.60
3.73

20
21
9
157.3
532
3.38
4.77

13
17
5
73.2
301
4.11
3.99

23
31
8
181.2
643
3.55
3.88

9
11
6
50.7
209
4.12
5.20

7
8
7
34.2
161
4.71
3.53

13
16
7
103.2
352
3.41
6.66

14
18
7
124.2
401
3.23
3.74

12
16
9
144.9
453
3.13
4.73

17
21
9
157.3
432
2.75
5.44

15
20
5
83.5
289
3.46
5.90

18
26
8
169.2
601
3.55
4.97

8
12
6
61.7
172
2.79
6.26

7
8
7
43.8
155
3.54
4.22

12
13
6
72.1
323
4.48
4.18

12
12
7
76.9
346
4.50
4.11

12
15
8
126
476
3.78
3.37

15
18
8
134.8
459
3.41
4.69

14
16
6
80.9
323
3.99
3.84

37
42
6
191.4
761
3.98
3.94

10
12
6
54.5
228
4.18
5.21

7
7
6
31.3
150
4.79
3.72

12
14
7
89.9
306
3.40
6.54

12
14
7
94.1
319
3.39
3.78

12
16
9
143.9
449
3.12
4.90

14
19
9
156
451
2.89
5.21

12
15
5
62.1
220
3.54
5.92

29
33
7
210.7
687
3.26
4.51

9
12
6
58.1
180
3.10
6.14

6
7
6
38.4
137
3.57
4.25

Duration
Results indicate that the gap between planned duration and actual duration is greater in offshore teams than in inhouse teams for both projects. These results suggest that the difficulties for managing GSD teams and its intrinsic
complexity affect compliance with deadlines.
Required effort
Results presented in table 1 suggest that, in general, offshore teams require more effort than in-house teams forboth projects, except for: 1) project manager 4, who presents the same effort for in-house and offshore teams inproject 1; 2) project manager 6, who devotes less effort to offshore teams than in-house teams in project 1; 3) andproject manager 5, who dedicates more effort to in-house teams than offshore teams in project 2. However,despite these exceptions, in general terms, results indicate that offshore teams require more effort than in-houseteams.
With regard to comparisons among project managers required effort in projects 1 and 2, project managers 7 and
8 present less required effort than the rest both for in-house and offshore teams. These results suggest that project
managers’ skills play an important role for the management of teams. In fact, though the required effort fromproject manager 7 and project manager 8 is greater for in-house teams than for offshore teams, the required effort
of both project managers is significantly lower than the required effort from the rest of the project managers.
Productivity
In terms of productivity, data report that offshore teams present lower productivity metrics than in-house teams,
except for the teams managed by project manager 6, which have similar productivity for in-house and offshore
teams in project 1. However, in project 2, the productivity of the offshore team managed by project manager 6 islower than that of the in-house team as it is the case for the rest of the project managers. This can be explained
because of the more effort required in offshore projects. The greater effort required seems to affect productivity
negatively. Thus, results suggest that in-house teams, despite facing more complex projects, are managed timely,
which lead to high productivity levels. This finding indicates that the offshore teams’ lower productivity may be
more related to management issues than to difficulties in communication and coordination.
Defects
With regard to defects, the data show that offshore teams present a greater number of defects than in-houseteams. The number of defects is because offshore teams tackle projects with fewer function points, which affects
software quality. Again, this finding suggests that, in addition to traditional challenges faced by GSD teams, thedifficulties in managing offshore teams lead to lower levels of quality and productivity.

Table 2. Descriptive statistics for Project 1 and Project 2.
Project 1
In-house
AV

SD

Project 2

Offshore
AV

SD

Total
AV

In-houseSD

AVG

Offshore

SD

AV

Total

SD

AV

SD

Plannedduration

14.25

5.34

13.00

3.93

13.63

4.57

14.88

9.26

13.25

6.82

14.06

7.90

Actualduration

16.88

6.96

17.13

5.54

17.00

6.08

16.88

10.67

16.25

7.59

16.56

8.95

Personnel

7.13

1.46

7.25

1.39

7.19

1.38

6.63

0.92

7.00

1.41

6.81

1.17

Requiredeffort

96.96

50.40

110.9
8

45.70

103.9
7

47.03

95.99

51.52

106.6
5

58.66

101.3
2

53.62

Function
points

388.5
0

164.4
7

356.8
8

149.2
8

372.6
9

152.6
1

383.2
5

186.7
7

343.6
3

180.2
0

363.4
4

178.4
7

Productivity

4.18

0.49

3.23

0.32

3.70

0.63

4.14

0.45

3.28

0.24

3.71

0.56

Defects per
Function Point

4.17

0.59

5.24

1.01

4.70

0.97

4.13

0.58

5.16

0.98

4.65

0.94

To further analyze the results, the means (AV) and standard deviation (SV) for partial measures (in-house andoffshore) and the global measure (project 1 and project 2) are presented in Table 2. Data for both projects,
considered jointly, are shown in table 3.
Table 3. Descriptive statistics for both projects with regard to location.
In house

Planned duration
Actual duration

Offshore

Global

AV

SD

AV

SD

AV

SD

14.56
16.88

7.31
8.70

13.13
16.69

5.38
6.44

13.84
16.78

6.36
7.53

Personnel

6.88

1.20

7.13

1.36

7.00

1.27

Required effort

96.48

49.24

108.8150.85

102.64

49.63

Function points

385.88170.03350.25160.00368.06163.41

Productivity

4.16

0.45

3.26

0.27

3.71

0.59

Defects per Function Point

4.15

0.57

5.20

0.96

4.67

0.94

Descriptive statistics show that, in general, figures are similar for both projects, suggesting that the projects arecomparable. In this sense, productivity (function point per unit of time) and quality (defects per function point)
metrics present similar results for both projects. However, differences appear when considering productivity forin-house and offshore teams. More specifically, for the first project, the values are 4.18 and 3.23 function points
per effort unit for in-house and offshore teams, respectively, whereas for the second project, values are 4.14 and
3.28, respectively. Differences are also found regarding defect rates for in-house and offshore teams in bothprojects. In conclusion, in-house teams present better values than offshore teams.

In order to verify whether the results presented statistically significant differences, the statistical t-test was used toanalyze if differences between the two groups (offshore and in-house teams) existed for productivity and quality
measures. The level of statistical significance was set at 5%. Results showed statistically significant differences
between the groups when data from both projects were considered simultaneously: Productivity (t(30)=6.799,
p<0.05) and Defects per Function Point (t(30)=-3.476, p<0.05). Differences were found when projects wereanalyzed separately: project 1 (Productivity (t(14)=4.563, p<0.05) and Defects per Function Point (t(14)=-2.575,
p<0.05); and project 2 (Productivity (t(14)=4.788, p<0.05) and Defects per Function Point (t(14)=-2.547,
p<0.05). In addition, results in Table 2 show that, regarding offshore teams, there is little difference in bothproductivity and quality metrics between the two projects. Statistical analyses showed that, as expected, thesedifferences are not significant: Productivity (t(14)=-0.374, p>0.05) and Defects per Function Point (t(14)=-0.163,
p>0.05).
b) 360º assessment.
The second source of data of our study came from the 360-degree feedback. Table 4 presents means (AV) andstandard deviation (SD) of scores per respondent regarding 360-degree feedbacks.
Table 4. 360º feedback descriptive statistics per respondent

Supervisor(AV)

Accessible
Coordination
Control
Feedback
Conflicts
Responsibility
Decisions
Attitudes
Neglected
Bad Performance

2.56
3.44
4.22
3.89
4.44
4.44
4.44
4.22
1.11
1.44

(SD)

1.01
1.59
1.64
1.76
1.67
1.67
1.67
1.64
0.60
0.73

Peer
(AV)

2.11
3.11
3.56
3.67
3.89
4.44
4.11
3.67
1.22
2.00

Team members
(SD)

0.93
1.36
1.59
1.58
1.69
1.67
1.62
1.50
0.83
1.12

(AV)

2.13
2.44
2.06
2.31
2.13
2.50
2.06
2.69
2.06
3.63

(SD)

0.72
0.63
0.77
0.87
0.81
1.10
0.85
0.79
0.57
0.72

Customer
(AV)

2.56
3.22
3.56
3.33
3.11
2.78
3.11
3.22
1.44
2.00

(SD)

1.01
1.39
1.59
1.41
1.45
1.48
1.36
1.39
0.73
1.22

Results show disparities between subject groups. Supervisors give higher marks to project managers, followed
usually by peers and customers. To analyze whether differences among groups existed, the ANOVA analysis wasused. Results confirm that statistically significant differences between respondents exist for all items measuring
aspects from the software project manager: Accessibility (F(39)=4.853, p<.05); Coordination (F(39)=8.752,
p<.05); Project control (F(39)=26.173, p<.05); Feedback to team members (F(39)=17.734, p<.05); Conflictresolution (F(39)=30.049, p<.05); Responsibility (F(39)=23.442, p<.05); Adequate decisions (F(39)=43.601,
p<.05); Attitudes for transferring knowledge (F(39)=17.699, p<.05); Tasks neglected (F(39)=4.517, p<.05); andGSD affects his/her performance negatively (F(39)=13.870, p<.05). These results suggest that althoughsupervisors, peers and customers give higher rates than team members, these scores are not a homogenous orconsensual perception of the different aspects analyzed.
Futher analysis of specific figures shows that supervisors give higher values to project managers than to the restof the groups. In fact, several statistically significant differences between supervisors and the rest of the subjects
are found. More specifically, statistical differences exist: between supervisors and peers for accesibility [t(14)=2,256, p<0,05] and attitudes [t(14)=2,236, p<0,05]; between supervisors and team members for all theanalyzed variables (see table 5); and between supervisors and customers for conflicts: t(14)=4,583, p<0,05;
responsability: t(14)=4,710, p<0,05; decisions: t(14)=5,612, p<0,05 and attitudes: t(14)=3,631, p<0,05].
Results indicate that supervisors present fewer differences with peers and custormers. Supervisors present moredifferences with team members who give the lowest scores to project managers. To find out if statisticaldifferences existed between team members and the rest of the groups, the statistical t-test was applied. As shownin Table 5, for almost all cases, except for the three marked in bold, significant differences do exist.
Table 5. T-test analyses between Team Members and the rest of the groups
Team members Vs.
Supervisors

Accessibility
Coordination
Control
Feedback
Conflict resolution
Responsibility
Adequate decisions
Attitudes
Neglected
Negative Performancet(22)= 2.766, p<0.05
t(22)=4.350 , p<0.05
t(22)=9.011 , p<0.05
t(22)=5.084 , p<0.05
t(22)=9.973 , p<0.05
t(22)=6.383 , p<0.05
t(22)=9.621 , p<0.05
t(22)=6.755 , p<0.05
t(22)=-3.469 , p<0.05
t(22)=-6.983 , p<0.05

Team members Vs. Peerst(22)=0.873 , p>0.05
t(22)=3.651 , p<0.05
t(22)=5.430 , p<0.05
t(22)=4.861 , p<0.05
t(22)=6.166 , p<0.05
t(22)=6.383 , p<0.05
t(22)=7.755 , p<0.05
t(22)=4.438 , p<0.05
t(22)=-2.509 , p<0.05
t(22)=-4092 , p<0.05

Team members Vs.
Customerst(22)=2.766 , p<0.05
t(22)=4.106 , p<0.05
t(22)=5.430 , p<0.05
t(22)=4.029 , p<0.05
t(22)=3.753 , p<0.05
t(22)=1.306 , p>0.05
t(22)=4.029 , p<0.05
t(22)=2.783 , p<0.05
t(22)=-1.816 , p>0.05
t(22)=-3.814 , p<0.05

The differences between team members and other professionals suggest that they have distinct perceptions about
the software project manager’s management activities. The perception of team members seem to be more"demanding" than that of other professionals, for almost all the variables analyzed. The exceptions are:accesibility and responsibility. Team members’ perception of accessibility is comparable to that of peers, theirperception of responsibility coincides with that of customers, while differences exist with supervisors for bothvariables.
Several questions from the results arise: Of all the professionals, why have team members assessed project
managers most negatively? Why are supervisors the subjects who evaluate project managers most positively? Is
there any negative and positive response bias regarding these two type of professionals? Are team members
tougher than supervisors when judging project managers? A disscussion with regard to these issues is offered in
the next section.

Discussion
Recent empirical literature has suggested that geographic distance can have negative effects on productivity andthat allocation has a direct impact on the overall project performance (e.g. Avritzer et al., 2010; Casey &Richardson, 2008; Casey & Richardson, 2009, Milewski et al., 2009). The same conclusion has been offered for
efficiency (e.g. Bosch & Bosch-Sijtsema, 2010; Smite et al., 2010). This paper confirms previous research.
Differences in productivity and defects are around 20% and in line with existing literature (e.g. Muhairat,
Aldaajeh & Al-Qutaish, 2010; Ramasubbu & Balan, R.K., 2007), which has revealed that productivity andquality differences arise due to various circumstances and sources. However, despite productivity losses, thesubstantially lower labor costs that offshoring software development offers still provides incentives to implement
this practice (e.g. Gefen & Carmel, 2008), even if total costs are balanced.
Results confirm the literature on GSD and indicate that differences in performance between both teams (offshore
and in-house) are presented in all the variables analyzed: GSD teams present higher differences between planned
duration and actual duration. As a result, the required effort in offshore teams is higher, while performance islower. Although the differences between the teams are not overwhelming, statistically significant differenceswere found. Despite the differences (in favor of the in-house teams) a slight improvement in the productivity ofoffshore teams is found, especially in the second project. This may be because of the limited project size, thegradual adoption of the corporate culture or the increasing trust between teams and organizations. However, it isdifficult to know whether this improvement is due to random factors or to a real favorable trend. In future
research, it would be interesting to analyze a larger number of projects in order to shed light on this issue.
With regard to the 360-degree feedback, results show that supervisors are the group which assessed software
project managers most positively. In this sense, is there a response bias from supervisors? That is, are they

systematically more benevolent than the other professionals when judging software project managers? The sourceof these differences may be found in GSD itself, since implementing GSD is usually seen as a strategic decision(Bosch & Bosch-Sijtsema, 2010; Prikladnicki & Audy, 2010) and also because supervisors (normally membersof the board of directors) tend to make the decision to implement these practices, so initially they are morepositive about their outcomes. The same rationale can be used for peers because they present similar results. In
contrast, customers’ evaluation differs because of the intrinsic nature of their role: customers are more aware of
the project outcomes, including several artifacts like documentation and software deliverables.
In contrast, team members are less generous in their judgments. In fact, as mentioned earlier, statisticallysignificant differences between team members and supervisors were found for all the variables.
Furthermore, significant differences in almost all variables comparing team members’ opinions with the othergroups are obtained, except for the three cases in which no such differences exist. The first case is software
projects managers’ accessibility. In this case, the supervisor and customers consider that software projects
managers’ accessibility during GSD projects is greater than that reported by peers and team members. Thisdifference may be explained because of the priority that communication with customers and supervisors has overcommunication with peers and team members. This circumstance reveals that there truly is a lack of accessibility
to software projects managers, although this accessibility is not perceived by customers and supervisors because
their priority is communication. The second and the third cases are the responsibility and the neglect of theirwork. In both cases, figures are very similar among supervisors, peers and customers, but scores from teammembers are lower. Once again, the real effects of GSD are a loss of control of responsibilities, due to the extra
amount of work that GSD implies. This is reflected in a slight disregard of the Software Projects Managers’
duties.
Although evaluations between team members and peers (and between team members) are not statisticallysignificant for accessibility (and for responsibility and neglect), the truth is the team members are theprofessionals who assess software project managers most negatively. Team members give less puntuations toproject managers in coordination, control, feedback, conflict resolution, decision making and attitudes, while they
offer a high score in negative performance. What reasons may explain these results? Is it the constant interaction
between team members and project managers what “wears out” their relationship and, as a consequence, leads
them to an unfavorable opinion or is it possible that the management of in-house and offshore teams has anegative influence on project managers’ performance? Results from this study suggest that a possible interaction

between the two may be happening. On the one hand, team members interact with project managers on a daily
basis and know their responsibilities well. On the other hand, the high demands which result from managing inhouse and offshore teams may cause project managers to “neglect” their in-house management activities.

Implications, limitations, and future research
At this point, we are ready to answer the research question, what effect does GSD have on software project
managers' performance? Results show that GSD teams report lower productivity figures than in-house teams.
However, could it be concluded that GSD negatively influences software project managers? This work shows thatthe management of offshore projects affects project managers’ performance in a negative way. This fact is
supported by the discovery of lesser performance of in a set of activities, namely, coordination, control, feedback
and conflict resolution. Coordination, control and communication are known the 3 C’s of GSD. The effects of
GSD on these variables are devastating, even in local teams.
Evaluations from offshore team members were not available for this study. Having these evaluations would haveallowed us to analyze the differences in project managers’ performance by type of project (in-house andoffshore). Nonetheless, evaluations from in-house teams provide indirect knowledge on the way in which a twotype project influences project managers’ activities. The results suggest that project managers do not attend toimportant management activities such as coordination, control, feedback or decision making. Therefore, it may
be that managing in-house and offshore teams simultaneously influences the primary responsible person’s
performance of the projects negatively.
Furthermore, on looking at the results in greater depth, offshore teams take more time to complete their projects,
the real effort is greater and their productivity and quality are lower. However, the authors found that someoffshore teams have shown a real effort comparable to that of in-house teams. In this sense, it is inevitable toconsider that other factors may be influencing project performance, such as the managers’ management skills andtheir ability to select the most suitable team. Offshore team management requires management skills rooted incommunication, negotiation and time management. Software project managers must develop these kinds of skills
if they want to increase their performance in offshore projects in comparison to in-house projects. In fact, resultsfrom the 360-degree feedback suggest that team members judge project managers in a more demanding way thanother professionals do. One possible explanation may be that team members consider managers’ leadership as animportant issue, since project managers must be available to coordinate, provide feedback, resolve conflicts,
assume responsibilities, make good decisions, etc.
On the other hand, the authors understand that managers must make a major effort when selecting and recruiting
their offshore team members, since these professionals will be part of a large-scale, international project. These
projects are complex and require workers that are able to fit into a picture with novel cultural parameters. Results
show that, despite the difficulties, some offshore teams maintain good levels in terms of effort and productivity
ratios. These teams probably possess characteristics or abilities that have allowed them to obtain similar results to
those of their in-house colleagues. In short, if managers are able to combine proper management through strong
leadership, and recruitment adapted to the requirements of the projects, GSD projects will obtain better
performance that may be comparable to that of in-house projects.
As the influence of GSD on software personnel is a broad and multidisciplinary research area, there are many
opportunities for future research in this field.
Indeed, the authors wish to note that although this study provides interesting insights into the effects of GSD on
software projects managers’ performance, the intrinsic exploratory nature of this paper requires further efforts inorder to clarify how the identified factors affect software projects managers and other software personnel.
Future research may adopt a broader scope to include qualitative and quantitative methodologies and a wider
range of organizations and projects. Future studies could also consider analyzing the impact of GSD on softwaredevelopers. A longitudinal study on the repercussions of GSD for in-site personnel could also be of interest.
Finally, it is intended to expand the scope of the study by including offshore team members in the study.

Acknowledgements
We thank Fundación Cajamurcia for the financial support provided.

References.
Albrecht, A.J., & Gaffney, J.E. (1983). Software function, source lines of code, and development effort
prediction: a software science validation. IEEE Transactions on Software Engineering, 9(6), 639–648.
Ali Barbar, M., Verner, J. M., & Nguyen, P. T. (2007) Establishing and maintaining trust in software
outsourcing relationships: An empirical investigation. Journal of Systems and Software, 80 (9), 1438-1449.
Atkinson, R. (1999). Project management: cost, time and quality, two best guesses and a phenomenon, its timeto accept other success criteria. International Journal of Project Management, 17(6), 337-342.
Atwater, L.E., & Brett, J.F. (2005). Antecedents and consequences of reactions to developmental 360°
feedback. Journal of Vocational Behavior, 66(3), 532-548.
Avritzer, A., Paulish, D., Cai, Y., Sethi, K. (2010). Coordination implications of software architecture in a
global software development project. Journal of Systems and Software, 83(10), 1881-1895.
Barczak, G., McDonough, E., & Athanassiou, N. (2006). So you want to be a global project leader?. ResearchTechnology Management, 49(3), 28-35.
Beehr, T. A., Ivanitskaya, L., Hansen, C. P., Erofeev, D., & Gudanowski, D. M. (2001). Evaluation of 360
degree feedback ratings: relationships with each other and with performance and selection predictors. Journal of
Organizational Behavior, 22(7), 775–788.
Boehm, B.W., & Ross, R. (1989). Theory-W Software Project Management Principles and Examples. IEEE
Transactions on Software Engineering. 15(7), 902-916.
Bosch, J., & Bosch-Sijtsema, P. (2010). From integration to composition: On the impact of software productlines, global development and ecosystems. Journal of Systems and Software, 83(1), 67-76.
Brutus, S., Fleenor, J. W., & London, M. (1998). Does 360-degree feedback work in different industries?: A
between-industry comparison of the reliability and validity of multi-source performance ratings. Journal ofManagement Development, 17(3), 177–190.
Carmel, E., & Agarwal, R. (2001). Tactical approaches for alleviating distance in global software development.
IEEE Software, 18(2), 22-29.
Carmel, E., & Tjia, P. (2005). Offshoring Information Technology: Sourcing and Outsourcing to a Global

Workforce. UK: Cambridge.
Casey, V., & Richardson, I. (2008). Virtual Teams: Understanding the Impact of Fear. Software Process:Improvement and Practice, 13(6), 511–526.
Casey, V., & Richardson, I. (2009). Implementation of Global Software Development: A Structured Approach.
Software Process Improvement and Practice, 14(5), 247–26.
Church, A.H. (2000). Do higher performing managers actually receive better ratings? A validation of multirater
assessment methodology. Consulting Psychology Journal: Practice and Research, 52(2), 99-116.
Clott, C.B. (2004) Perspectives on global outsourcing and the changing nature of work. Business and Society
Review, 109(2), 153–170.
Colazo, J.A., & Fang, J. (2010). Following the Sun: Temporal Dispersion and Performance in Open Source
Software Project Teams. Journal of the Association for Information Systems, 11(11), 684-707.
Conchuir, E.O., Holmstrom-Olson, H., Agerfalk, P.J., & Fitzgerald, B. (2009). Benefits of Global Software
Development: Exploring the Unexplored. Software Process Improvement and Practice, 14(4), 201–212.
Crow, G.B., & Muthuswamy, B. (2003). International outsourcing in the information technology industry:
Trends and implications. Communications of the International Information Management Association, 3(1), 2534.
Cusumano, M. A. (2008). Managing Software Development in Globally Distributed Teams. Communications of
the ACM, 51(2), 15-17.
D’Mello, M., & Sahay, S. (2007). “I am kind of a nomad where I have to go places and places”…
Understanding mobility, place and identity in global software work from India. Information and Organization,
17(3), 162-192.
Damian, D., & Moitra, D. (2006). Global software development: How far have we come? IEEE Software, 23(5),17–19.
Disterer, G. (2002). Management of project knowledge and experiences. Journal of Knowledge Management,
6(5), 512-520.
Dweiri, F.T., & Kablan, M.M. (2006). Using fuzzy decision making for the evaluation of the projectmanagement internal efficiency. Decision Support Systems, 42(2), 712-726.
Ebert, C. (2012). Global Software and IT: A Guide to Distributed Development, Projects, and Outsourcing.
Wiley-IEEE Computer Society Press.
Ebert, C., & De Neve, P. (2001). Surviving Global Software Development. IEEE Software, 18(2), 62–69
García-Crespo, Á., Colomo-Palacios, R., Soto-Acosta, P., & Ruano-Mayoral, M. (2010). A Qualitative Study ofHard Decision Making in Managing Global Software Development Teams. Information Systems Management,27(3), 247-252.
García-Guzmán, J., Saldaña-Ramos, J., Amescua-Seco, A., & Sanz-Esteban, A. (2010). How to get mature
global virtual teams: a framework to improve team process management in distributed software teams. Software
Quality Journal, 18(4), 409-435.
García-Guzmán, J., Saldaña-Ramos, J., Amescua-Seco, A., & Sanz-Esteban, A. (2011). Success Factors for theManagement of Global Virtual Teams for Software Development. International Journal of Human Capital andInformation Technology Professionals, 2(2), 48-59.
Gefen, D., & Carmel, E. (2008). Is the World Really Flat? A Look at Offshoring at an Online Programming
Marketplace. Management Information Systems Quarterly, 32(2), 367-384.
Gupta, A. (2009). Deriving mutual benefits from offshore outsourcing. Communications of the ACM, 52(6),122-126.
Gupta, A., & Seshasai, S. (2007). 24-hour knowledge factory: using internet technology to leverage spatial andtemporal separations. ACM Transactions on Internet Technology, 7(3), 1-22.
Gupta, A., Mattarelli, E., Seshasai, S., & Broschak, J. (2009). Use of collaborative technologies and knowledge
sharing in co-located and distributed teams: Towards the 24-h knowledge factory. The Journal of Strategic
Information Systems, 18(3), 147-161.
Herbsleb, J.D., & Mockus, A. (2003). An empirical study of speed and communication in globally distributed
software development. IEEE Transactions on Software Engineering, 29(9), 481-494.
Herbsleb, J.D., & Moitra, D. (2001). Global software development. IEEE Software, 18(2), 16–20.
Hernández-López, A., Colomo Palacios, R., García Crespo, A., & Soto-Acosta, P. (2010a). Trust BuildingProcess for Global Software Development Teams. A review from the Literature. International Journal of
Knowledge Society Research, 1(1), 65-82.
Hernández-López, A., Colomo-Palacios, R., García-Crespo, Á., & Soto-Acosta, P. (2010b). Team Software
Process in GSD Teams: A study of new work practices and models. International Journal of Human Capital andInformation Technology Professionals, 1(3), 32-53.
Jalote, P., & Jain, G. (2006). Assigning tasks in a 24-hour software development model. Journal of Systems andSoftware, 79(7), 904-911.
Jiang, J., & Klein, G. (2000). Software development risks to project effectiveness. Journal of Systems andSoftware, 52(1), 3-10.
Khan, S.U., Niazi, M., & Ahmad, R. (2011). Factors influencing clients in the selection of offshore software
outsourcing vendors: an exploratory study using a systematic literature review. Journal of Systems and Software,
84(4), 686-699.
Kitchenham, B., & Mendes, E. (2004). Software productivity measurement using multiple size measures. IEEE
Transactions on Software Engineering, 30(12), 1023–1035.
Kommeren, R., & Parviainen, P. (2007). Philips experiences in global distributed software development,
Empirical Software Engineering, 12(6), 647-660.
Krishna, S., Sahay, S., & Walsham, G. (2004). Managing cross-cultural issues in global software outsourcing.
Communications of the ACM, 47(4), 62–66.
Kunda, D., & Brooks, L. (2000). Assessing organizational obstacles to component-based development: a casestudy approach. Information and Software Technology, 42(10), 715-725.
Layman, L., Williams, L., Damian, D., & Bures, H. (2006). Essential communication practices for extreme
programming in a global software development team. Information and Software Technology, 48(9), 781-794.
Martins, L. L., Gilson, L. L., & Maynard, M. T. (2004).Virtual Teams: What Do We Know and Where Do We
Go From Here?. Journal of Management, 30(6), 805-835.
Massingham, P., Nguyen, T.N.Q., & Massingham, R. (2011). Using 360 degree peer review to validate selfreporting in human capital measurement. Journal of Intellectual Capital, 12(1), 43 – 74.

Milewski, A. E., Tremaine, M., Köbler, F., Egan, R., Zhang, S., & O'Sullivan, P. (2008). Guidelines for
Effective Bridging in Global Software Engineering. Software Process: Improvement and Practice, 13(6), 477–
492.
Muhairat, M., Aldaajeh, S., & Al-Qutaish, R.E. (2010). The Impact of Global Software Development Factors on
Effort Estimation Methods. European Journal of Scientific Research, 46(2), 221-232.
Noll, J., Beecham, S., & Richardson, I. (2010). Global software development and collaboration: barriers andsolutions. ACM Inroads, 1(3), 66-78.
Olsen, R.P. (1971). Can project management be defined?. Project Management Quarterly, 2(1), 12–14.
Oza, N. V., Hall, T., Rainer, A., & Grey, S. (2006). Trust in software outsourcing relationships: An empiricalinvestigation of Indian software companies, Information and Software Technology, 48(5), 345-354.
Prikladnicki, R., & Audy, J.L.N. (2010). Process models in the practice of distributed software development: A
systematic review of the literature. Information and Software Technology, 52(8), 779-791.
Prikladnicki, R., Audy, J. L. N., & Evaristo, R. (2003). Global Software Development in Practice Lessons
Learned, Software Process: Improvement and Practice, 8(4), 267-281.
Ramasubbu, N., & Balan, R.K. (2007). Globally distributed software development project performance: anempirical analysis. Proceedings of the 6th joint meeting of the European software engineering conference andthe ACM SIGSOFT symposium on the foundations of software engineering: pp. 125-134.
Ramasubbu, N., Krishnan, M. S., & Kompalli, P. (2005). Leveraging global resources: A process maturity
framework for managing distributed development. IEEE Software, 22(3), 80-86.
Robinson, M., & Kalakota, R. (2004). Offshore Outsourcing: Business Models, ROI and Best Practices. Mivar
Press.
Rogers, P., & Lea, M. (2005). Social presence in distributed group environments: the role of social identity.
Behaviour & Information Technology, 24(2), 151-158.
Rose, J., Pedersen, K., Hosbond, J. H., & Kræmmergaard, P. (2007). Management competences, not tools andtechniques: A grounded examination of software project management at WM-data. Information and Software
Technology, 49(6), 605-624.

Smite, D., & Wohlin, C. (2011). Strategies Facilitating Software Product Transfers. IEEE Software, 28(5), 6066.
Smite, D., Wohlin, C., Gorschek, T., & Feldt, R. (2010). Empirical evidence in global software engineering: asystematic review. Empirical Software Engineering, 15(1), 91-118.
Sooraj, P., & Mohapatra, P.K.J. (2008). Modeling the 24-h software development process. Strategic
Outsourcing: An International Journal, 1(2), 122-141.