prr.hec.gov.pkprr.hec.gov.pk/jspui/bitstream/123456789/11464/1/Salma Imtiaz_Co… · Task Allocation in Global Software Development 2018 Salma Imtiaz Page 2 RIPHAH INTERNATIONAL UNIVERSITY,

Task Allocation in Global Software Development 2018

Salma Imtiaz Page 1

`

Salma Imtiaz

CMS No 9062

Supervised by

Dr. Naveed Ikram

A thesis submitted in partial fulfillment of the requirements for the degree of

Doctor of Philosophy

In

Computing

at

Riphah International University,

Islamabad, Pakistan

December, 2018

TASK ALLOCATION IN GLOBAL

SOFTWARE DEVELOMENT


Salma Imtiaz Page 2

RIPHAH INTERNATIONAL UNIVERSITY, ISLAMABAD

APPROVAL SHEET

SUBMISSION OF HIGHER RESEARCH DEGREE THESIS

The following statement is to be signed by the candidates ‘supervisor (s), Dean/ HOD and

must be received by the COE, prior to the dispatch of the thesis to the approved examiners.

Candidate’s Name & Reg#: Salma Imtiaz, S12C04P01001.

Program Title: PhD

Faculty/Department: Faculty of Computing

Thesis Title: Task Allocation in Global Software Development

I hereby certify that the above candidate’s work, including the thesis, has been completed to

my satisfaction and that the thesis is in a format and of an editorial standard recognized by

the faculty/department as appropriate for examination. The Thesis has been checked through

Turnitin for plagiarism (test report attached).

Signature (s):

Principal Supervisor: __________

Date: _______________________

Co-Supervisor –I ______________

(if any) ______________________

Date: _______________________

The undersigned certify that:

1. The candidate presented at a pre-completion seminar, an overview and synthesis of major

findings of the thesis, and that the research is of a standard and extent appropriate for

submission as a thesis.

2. I have checked the candidate’s thesis and its scope, format, and editorial standards are

recognized by the faculty/department as appropriate.

3. The plagiarism check has been performed. Report is attached

Signature (s):

Dean/Head of Faculty/Department: ____________

Date: ____________________________________


Salma Imtiaz Page 3

DECLARATION OF AUTHENTICATION

I certify that the research work presented in this thesis is to the best of my knowledge my own.

All sources used and any help received in the preparation of this dissertation have been

acknowledged. I hereby declare that I have not submitted this material, either in whole or in

part, for any other degree at this or any other institution.

Signature……………


Salma Imtiaz Page 4

ACCEPTANCE CERTIFICATE

TASK ALLOCATION IN GLOBAL SOFTWARE DEVELOPMENT

By

SALMA IMTIAZ,

A thesis submitted in partial fulfillments of the requirements for the degree of

Doctor of Philosophy

In

Computing

We accept this thesis as conforming to the required standard

Supervisor: _____________________(Name & Sig)____________________

External Examiner-1: _____________(Name & Sig)______________________

External Examiner-2: _____________(Name & Sig)______________________

HOD/Incharge: __________________(Name & Sig)_______________________

Dean: __________________________(Name & Sig)_______________________


Salma Imtiaz Page 5

DEDICATION

“Read1 in the name of your Lord2Who created, Created man from a clot of congealed blood. Read

and your Lord is Most Generous. Who taught knowledge by the pen, taught man what he did not

know” Surah Al Alaq 96:1-5

All praise is to Almighty Allah. I am grateful to my Creator for giving me the mind,

opportunity, strength and support to acquire knowledge. I am thankful to the Creator who

bestowed his countless blessings on me and enabled me to pursue my passion for learning. No

words can explain the extent of gratitude I feel for standing where I am today. I feel extremely

blessed that I am one of the very few who are able to achieve what they dream for.

This endeavour was not possible without the support of family, friends and colleagues whom I

would like to thank one by one.

The unwavering determination to acquire knowledge became my inspiration to pursue this

challenging degree. The persistent support of my parents helped me to cope with the most

difficult times during my PhD. Their dream of seeing me complete my PhD motivated me

when I lost hope. To the world it is a degree and a title that comes with it, however it is more

of an experience than a piece of paper or the title. An experience of consistently and patiently

struggling, all the while developing innovative ways to overcome the hurdles that comes in

the way. I am highly indebted to my parents for helping me achieve this dream.

This venture was not possible without the guidance and supervision of Dr. Naveed Ikram,

who is more than just a teacher and a supervisor. He is a brilliant mentor who rightly

recognized my potential which I never knew existed. He has always demanded the best and

gave his unfailing support throughout my academic career. My interest in the field of

software engineering started with his lectures. He helped me to polish my skills and made me

able to contribute to the society. He has always been a source of guidance and provided

positive criticism that refined my work.

http://englishtafsir.com/Quran/96/index.html#sdfootnote1sym


Salma Imtiaz Page 6

I am deeply grateful to all my family members including my brothers, sisters, husband and in-

laws who have always been there for me when I needed their support. Their support and

motivation is what kept me going through periods of stagnation. My sister Saima Imtiaz

always helped me to focus on the goal and removed my doubts. My husband Faisal Hayat

who supported me and helped me to concentrate on studies. I am extremely grateful to my son

Muhammad Shahzeb Hayat who gave up on his family time to let me do research and

complete my studies. My little daughter Airaah, who cheered me up during final changes and

updates. My friends Maria Fazal and Falak Khan who always encouraged me and advised not

to lose hope.

I am thankful to all the participants of the Survey, Interview and Focus Group Study without

whom; it was not possible to complete this research. Their feedback improved the task

allocation process and helped me to fill the identified research gap. I would also like to

acknowledge the reviewers of conferences and journals where this work was published, since

their valuable feedback helped in the refinement process. I am thankful to all my friends and

colleagues who have provided their feedback and valuable suggestions throughout this

research.

A special thanks to Ms. Maria Khalid for editing and proof reading the final thesis. Without

the support of any one of the contributors, this research would not have been possible.

SALMA IMTIAZ


Salma Imtiaz Page 7

PUBLICATIONS

The thesis includes some parts of the below given publications, that are already published or

in process of publication as part of this research.

1. Salma Imtiaz, Naveed Ikram, “A Framework for Task Allocation in Global Software

Development: Results of a Computer Mediated Focus Group”, Submitted in Journal of

Computer Information Systems.

2. Salma Imtiaz, Naveed Ikram, “Dynamics of Task Allocation in Global Software

Development”, Journal of Software: Evolution and Process, volume 29, issue 1, 2017.

3. Salma Imtiaz “Architectural Task Allocation in Distributed Environment: A

Traceability Perspective”, International Conference on Software Engineering, pp.

1515-1518, Switzerland,2012.

4. Salma Imtiaz, Naveed Ikram, “Effective Task Allocation in Distributed Environment:

A Traceability Perspective”, International Conference on Software Engineering

Advances, pp. 563-569, Barcelona, Spain, October 2011.


Salma Imtiaz Page 8

TABLE OF CONTENTS

Contents

LIST OF FIGURES ........................................................................................................................ 11

LIST OF TABLES ......................................................................................................................... 12

LIST OF ACRONYMS AND ABBREVIATION ......................................................................... 13

CHAPTER 1 ................................................................................................................................... 16

Introduction .................................................................................................................................... 16

1.1 Context and Background ......................................................................................................... 17

1.2 Problem Statement .................................................................................................................. 19

1.3 Research Aim ................................................................................................................... 21

1.3.1 Research Objectives ...................................................................................................... 21

1.3.2 Research Questions ....................................................................................................... 21

1.4 Research Methodology ............................................................................................................ 22

1.5 Thesis Contribution ................................................................................................................. 24

1.6 Thesis Structure ....................................................................................................................... 25

CHAPTER 2 ................................................................................................................................... 27

Background and Literature Review ................................................................................................ 27

2.1 Background ............................................................................................................................. 28

2.1.1Task Allocation Problem in GSD ................................................................................... 29

2.1.2 The Triangle .................................................................................................................. 32

2.2 Literature Review .................................................................................................................... 34

2.2.1 Finalized Factors for Task Allocation ........................................................................... 42

CHAPTER 3 ................................................................................................................................... 46

Research Design ............................................................................................................................. 46

3.1 Research Design ...................................................................................................................... 47

3.2 Research Process .............................................................................................................. 47

3.2.1 Industrial Questionnaire Based Survey ......................................................................... 48

3.2.2 Interview Study ............................................................................................................. 51

3.2.3 Online Focus Group ...................................................................................................... 52

CHAPTER 4 ................................................................................................................................... 54

Results and Analysis ...................................................................................................................... 54

4.1 Survey Execution .................................................................................................................... 55

4.2 Survey Results and Analysis ................................................................................................... 56


Salma Imtiaz Page 9

4.2.1 Ranking of Factors for Task Allocation Decision ......................................................... 57

4.2.2 Importance of Architectural Relationships for Task Allocation in GSD ...................... 58

4.2.3 Ranking of Communication and Coordination Dependency Links ............................... 60

4.2.4 Statistical Analysis ............................................................................................................ 61

4.3 Result and Analysis of Interview Study .................................................................................. 73

4.3.1 Situation 1: Type of GSD (Off-shoring Versus Off-shore outsourcing) ....................... 75

4.3.2 Situation 2: Nature of the Project/Task ......................................................................... 76

4.3.3 Situation 3: GSD Involving Multiple Vendors .............................................................. 77

4.3.4 Situation 4: Number of Sites ......................................................................................... 78

4.3.5 Situation 5: Objective to carry GSD .............................................................................. 78

4.3.6 Situation 6: GSD involving large and small company(s) .............................................. 78

CHAPTER 5 ................................................................................................................................... 82

Findings and Discussion ................................................................................................................. 82

5.1 Findings and Discussion .................................................................................................... 83

5.1.2 Correlations ................................................................................................................... 87

5.2 Threats to Validity ................................................................................................................... 90

5.2.1 Threats to Survey Study ................................................................................................ 90

5.2.2 Threats to Interview Study ............................................................................................ 91

CHAPTER 6 ................................................................................................................................... 92

Proposed Task Allocation Framework/Validation ......................................................................... 92

6.1 Task Allocation Framework .................................................................................................... 93

6.2 Comparison with Literature ..................................................................................................... 96

6.3 Validation via Online Focus Group ......................................................................................... 97

6.3.1 Limitations of Online Focus Group ............................................................................. 107

6.4 Revisions in the Framework .................................................................................................. 108

CHAPTER 7 ................................................................................................................................. 113

Conclusion and Future Work ....................................................................................................... 113

7.1 Conclusion and Contributions ............................................................................................... 114

7.2 Implication on Research ........................................................................................................ 118

7.3 Implications on Industry ........................................................................................................ 118

7.4 Personal Reflections, Lessons learnt ..................................................................................... 119

7.5 Research Ethics ..................................................................................................................... 119

7.6 Future Work .......................................................................................................................... 120

7.6 Publication and Research Objectives .................................................................................... 121

References .................................................................................................................................... 121


Salma Imtiaz Page 10

Appendix A: Industrial Questionnaire ......................................................................................... 136

Appendix B: Probing Method Cognitive Stage Questions ........................................................... 142

Appendix C: Interview Protocol................................................................................................... 148

Appendix D: Interview Transcripts of All Interviewees .............................................................. 153

Appendix E: Detailed Spearman Rho Test ................................................................................... 195

Appendix F: Focus Group Protocol.............................................................................................. 199

Appendix G: Task Allocation Framework Given to Participants and Focus Group Discussion ......... 201



LIST OF FIGURES

FIGURE 3.1: RESEARCH DESIGN .................................................................................................................. 47

FIGURE 4.1: RANKING OF TASK ALLOCATION FACTORS BY GSD PRACTITIONERS ......................................... 57

FIGURE 4.2: IMPORTANCE GIVEN TO ARCHITECTURAL VIEWS FOR TASK ALLOCATION DECISION ................ 58

FIGURE 4.3: ARCHITECTURAL RELATIONSHIPS CONSIDERED FOR TASK ALLOCATION DECISIONS ................ 59

FIGURE 4.4: IMPORTANCE OF COMMUNICATION AND COORDINATION DEPENDENCY LINKS .......................... 60

FIGURE 4.5 : CONTINENTS WISE RESPONSES OF INDUSTRIAL SURVEY .......................................................... 62

FIGURE 4.6: SURVEY RESPONSE ROLE WISE .................................................................................................. 62

FIGURE 4.7: BUBBLE CHART DEPICTING CORRELATION OF FACTORS IDENTIFIED VIA SPEARMAN RHO TEST 73

FIGURE 6.1: REPRESENTATION OF REVISED STS ............................................................................................ 94

FIGURE 6.2: PROPOSED TASK ALLOCATION FRAMEWORK (ORGANIZED IN PLANES) ...................................... 95

FIGURE 6.3: PROPOSED TASK ALLOCATION FRAMEWORK (ORGANIZED IN PLANES) ...................................... 96



LIST OF TABLES

TABLE 2.1: COMPARISON OF IDENTIFIED FACTORS WITH THOSE OF SLR .................................................................. 43

TABLE 4.1 :LEVEL OF DISTRIBUTION ........................................................................................................................ 65

TABLE 4.2: CATEGORIES OF EXPERIENCE OF INDIVIDUAL WORKING IN GSD ........................................................... 65

TABLE 4.3: RECENTNESS OF GSD EXPERIENCE ........................................................................................................ 66

TABLE 4.4: SIGNIFICANT CORRELATIONS BETWEEN TASK ALLOCATION FACTORS .................................................. 68

TABLE 4.5: NUMBER OF RESPONSES IN EACH LIKERT SCALE OPTION ....................................................................... 71

TABLE 4.6: TASK ALLOCATION FACTORS IN DESCENDING ORDER ........................................................................... 72

TABLE 6.1: MAIN FEEDBACK FROM PARTICIPANTS OF FOCUS GROUP SESSION ........................................................ 99

TABLE 7.1: OBJECTIVE MAPPED WITH PUBLICATIONS ............................................................................................. 121



LIST OF ACRONYMS AND ABBREVIATION

GSD Global Software Development

TA Task Allocation

SPSS Statistical Package for Social Sciences

DSM Design Structure Matrix

CMC Computer Mediated Communication

FTF Face to Face

STS Socio -Technical Systems



Abstract Context: Global software development (GSD) promises high quality software at low cost.

GSD enables around-the-clock development to achieve maximum production in a short period

of time by utilizing expertise around the globe. GSD is only possible if tasks are effectively

distributed among sites to ensure smooth development. Therefore, one of the key challenges of

GSD is to design a Task Allocation (TA) strategy.

Objective: The main objective of this research is to develop a framework that takes into

account important factors while allocating tasks to the distributed sites involved in GSD. The

framework facilitates decision makers in allocation of the tasks in a manner which controls

delay and re-allocation.

Method:We used an empirical research method to acquire data. A mixed qualitative as well

as quantitative research methods were used to identify task allocation factors and their

relative importance. The research process consisted of an industrial survey followed by an

interview study. The task allocation framework is validated with help of an online focus group

session. A web-based survey of 54 GSD practitioners from around the globe was conducted to

identify the factors and their relative importance for TA decision. The selection of the sample

was performed via the snowball sampling technique. To increase the sample size, the survey

was also posted on social media, i.e., Facebook, LinkedIn and Twitter. Non-parametric

statistical tests were applied on the response data to identify correlations and significance.

Interviews were conducted from 10 project managers having 10 to 30 years GSD experience

to gain insight into the dynamics of task allocation process. Finally the developed TA

framework is validated with help of an online focus group. A total of 7 project managers

participated in the session. The feedback helped improve and refine the final TA framework.

Results: The survey results highlight 'expertise', 'site characteristics' and 'task-site

dependency' as the most important factors for a TA decision. The interview study has

highlighted the importance of situation specific decision making during task allocation. The

significance of factors varies with the characteristics of task, characteristics of organization,

type of GSD and objective of doing GSD. The culture and time differences between distributed

sites have been assigned a low priority by the majority of the practitioners. The most common

way of distributing task is functional area of expertise and phase based division, where



detailed architecture is not considered. Interdependent modules are not allocated to

distributed sites due to communication and coordination overhead. Our results also

demonstrate a correlation between various factors and support Conway’s law. The focus

group session helped in refining the framework. The participants approved of the framework

and its role in aware and informed task allocation during GSD. The framework promises

effective and informed task allocation by considering all the important factors and variations

to TA decision.

Conclusions: The proposed TA framework helps in work assignment based on critical

factors and variant situation which depends on characteristics of task, organization and type

of GSD etc. The ability of the framework to be applicable in real world scenarios is assessed

with help of an online focus group of industry practitioners. The practitioners have

highlighted the usefulness of the framework to both the practitioners involved in task

allocation decision in GSD as well as researchers working in this area.

We suggest the validation of the framework in real world GSD scenarios as part of future

work to this research. Further research is required to automate the task allocation process

based on the framework. Moreover the integration of TA framework with the existing software

development methodologies can be detailed and customization for agile methodology can also

be researched.

.



CHAPTER 1

Introduction



1.1 Context and Background

lobal Software Development (GSD) is a special type of distributed development

where the teams are separated by geographical distance, national boundaries,

organizational culture and time zones. These distances introduce the difficulty of

realizing the many benefits associated with GSD such as making use of the most

efficient expertise, reduced labour cost, around the clock development and reduced

time to market (Conway, 1968)(Lamersdorf, Munch, &Rombach, 2009)(Ralyté, Lamielle,

Arni-Bloch, & Léonard, 2008). These benefits are the reason that GSD is becoming a strategic

decision of many software development organizations with the advancement in

communication and coordination technologies. In order to realize the benefits, the geographic,

temporal and cultural distance present between the distributed sites needs to be reduced with

the help of multiple management strategies. Where the geographic, temporal and cultural

distances have complex dimensions and cannot be measured easily. The multifaceted

information that is required to measure the temporal, cultural and geographic distance

between GSD sites is detailed.

The geographic, temporal, and cultural dimension to distributed development is not a direct

measure of the difference between these dimensions; it depends on overlapping work hours,

visa processing procedure and time, organizational culture and many other impacting factors

etc. Geographic distance between two countries having direct flight and easy visa processing

is low even if they are present in different regions. Similarly two countries in the same region

having less geographic distance are considered very far due to the lack of transport

infrastructure and intervening borders (Ågerfalk et al., 2005). Geographic distance can also be

due to national boundaries and organizational boundaries where proper mechanisms to reduce

both are required (Nguyen-Duc& Cruzes, 2013). The different types of outsourcing based on

geographic distance i.e. onshore outsourcing, near-shore outsourcing and offshore outsourcing

(Khan, Niazi, & Ikram, 2009), where offshore outsourcing can also be termed as Global

Software Development. The categorization of offshore outsourcing relationship based on

number of clients and vendors involved in a relationship are simple dyadic relationship, micro

sourcing, multi-vendor outsourcing relationship, co-sourcing and complex outsourcing

relationship (Khan, Niazi, & Ikram, 2009) . The number of clients and vendors can vary in a

GSD setting. Therefore all of the relationships will come within the scope of global software

development except micro sourcing, since it is on individual level.

G



Temporal distance maybe due to different time zones and time shifting work patterns

(Holmstrom, Conchúir, Agerfalk, & Fitzgerald, 2006). The different working hours along

with different time zones may result in less temporal coverage. Hence the time zone

difference and time shift pattern can be aligned in a manner to increase overlap of working

hours. (Ågerfalk et al.,2005). A famous allocation strategy follow the sun makes use of

different time zones to achieve 24/7 development (Jalote & Jain, 2006, p. 7). Detail on 24/7

configuration is discussed in detail in chapter 2.

Cultural distance also known as socio-cultural distance comprises of national and

organizational culture (Ågerfalk et al., 2005). Socio-cultural distance can increase even if

geographic distance is not that much and vice versa. Different organizational culture can

result in increase of socio-cultural distance even with same national culture. Religion also

impacts the cultural distance increasing it in case of different religions and beliefs.

Global software development is a special kind of off shoring partnership where the client(s)

and vendor(s) are located in different regions separated by geographic, temporal and cultural

distance. Therefore onsite outsourcing and near shore outsourcing are not part of GSD. The

off shoring partnership if successful can help in generating revenue and improving

competences (Ali, Li, Khan, & Zhao, 2018).

Task allocation is an activity in which work is allocated to individuals or development teams.

Co-located task allocation can easily be performed on the basis of the known skills of team

members sharing the same space, time zone and culture. The same task allocation can easily

be updated or change in case of an issue or change in architecture. In global software

development, the activity of task allocation inherits complexity due to inadequate information

of distributed sites, different time zones and different national and organizational culture

(Bass, Mikulovic, Bass, James, & Marcelo, 2007)(Componation& Byrd Jr, 2000)(Salger,

2009)(Ralyté et al., 2008)(Clerc, Lago, & Van Vliet, 2007). The GSD scenario is further

complicated due to minimal informal communication opportunities and the cost associated

with it (Ralyté et al., 2008)(Grinter, Herbsleb, & Perry, 1999)(Herbsleb&Moitra,

2001)(Herbsleb, Mockus, Finholt, &Grinter, 2000)(Ye, Nakakoji, & Yamamoto, 2007).

Therefore on one hand task allocation suffers from lack of knowledge of distributed sites and

on the other it is very difficult to establish appropriate level of communication due to

complexity of coordination among distributed sites and the cost associated with it.

The distributed sites depend on each other due to component, resource, temporal and phase-

based dependencies. These dependencies have varying communication and coordination



needs, making them important dimensions of the task allocation scenario. The absence of this

rich interaction can lead to a lack of team spirit, misalignment and a need for rework

(Herbsleb&Moitra, 2001)(Grinter et al., 1999)(Herbsleb&Grinter, 1999b)(Herbsleb&Mockus,

2003)(Battin, Crocker, Kreidler, & Subramanian, 2001). Many communication and

coordination problems have been reported as a result of these differences (Bass et al.,

2007)(Lamersdorf et al., 2009)(Herbsleb&Grinter, 1999a)(Jiménez, Piattini, &Vizcaíno,

2009)(Herbsleb, 2007)(Lane &Agerfalk, 2008). The lack of informal communication

enhances the significance of a planned task allocation in GSD which will reduce the need for

communication and coordination across sites.

This issue is expressed by Conway’s law, which states that a product architecture is the mirror

image of the communication and coordination needs of the organization (Conway, 1968).

Parnas (Parnas, 1972) also states that component dependencies present in a product

architecture give rise to communication and coordination needs. A well-designed task

allocation strategy can make use of the above mentioned laws and reduce the communication

and coordination requirements among distributed sites by allocating independent or loosely

coupled tasks to distributed sites, as evident from literature (Bass et al., 2007)(O’Conchuir,

Holmstrom, Agerfalk, & Fitzgerald, 2006)(Bass, 2006)(Mockus&Herbsleb,

2001)(Lamersdorf et al., 2009). However, the problem is not that simple, as evidence suggests

that architectural mechanisms other than module or component dependencies also give rise to

coordination requirements (Bass et al., 2007). The change in communication and coordination

needs and product architecture further complicates the scenario, where the task allocation may

also need to be updated. Therefore, ensuring an organizational and architectural fit is still a

challenge (Herbsleb, 2007). Apart from communication and coordination problems, GSD also

suffers from problems inherited due to the very nature of distributed development, which

result in decreased productivity, lower project success rates and a loss of motivation

(Herbsleb, Mockus, Finholt, &Grinter, 2001)(Fabriek, Brand, Brinkkemper, Harmsen, &

Helms, 2008)(Casey & Richardson, 2006). These problems highlight the need for the

effective management of global distributed projects (Casey & Richardson, 2006).

1.2 Problem Statement

Global software development suffers from many challenges due to the complexities that are

essential to distributed development. The difficulty of managing project, communication and

coordination overhead and decrease in team cohesion are some of the major issues that need



to be resolved in order to gain benefit from GSD. These issues are inherent in the very nature

of distributed development and can have severe consequences such as delays and cost overrun

etc.

Therefore managing a distributed development especially a GSD is a challenging task. The

GSD challenges or risks can be minimized with help of an effective task allocation decision

(Richardson, Casey, Burton, &McCaffery, 2010). There is inconsistent information on what

information actually goes into making a task allocation decision of a GSD project. The

literature that motivates the need of a well-informed task allocation decision advocates the

importance of many factors some of which are highlighted here, however the strategies or

approaches used for task allocation(both in literature and industry) do not consider these

factors.The organizations often only consider labour costs or expertise as a task allocation

criterion (Keil, Paulish, &Sangwan, 2006)(Moe &Šmite, 2008), resulting in project failure, as

reported by practitioners (Lamersdorf et al., 2009). This confusion adds to the complexity of

task allocation decision. The lack of information on what are the critical factors that are

important and should be considered for an effective allocation decision make the practitioners

revert to ad-hoc task allocation decision. This ad-hoc task allocation is inefficient and unable

to handle the management issues leading to frequent changes in allocation decision and issues,

all of which delay the project.

Therefore the need of a well-defined and informed task allocation is critical to a GSD project

success.

Some of the factors highlighted as important for site selection are time differences

(Herbsleb&Moitra, 2001)(O’Conchuir et al., 2006)(Espinosa & Carmel, 2003)(Lings,

Lundell, Agerfalk, & Fitzgerald, 2007), cultural differences (Herbsleb&Moitra,

2001)(O’Conchuir et al., 2006)(Lings et al., 2007), the experience of individuals

(Herbsleb&Moitra, 2001), expertise (Herbsleb&Mockus, 2003)(O’Conchuir et al., 2006),

proximity to customers (Herbsleb&Moitra, 2001), costs of development (Herbsleb&Moitra,

2001) and coupling between tasks (Herbsleb et al., 2000)(Ye et al., 2007)(O’Conchuir et al.,

2006)(Lings et al., 2007) .

The strategies present in literature performs allocation based on a single or limited criteria

such as development phase dependency, labour cost or expertise only (Mockus& Weiss,

2001)(Keil et al., 2006)(Edwards, Kim, Park, & Al-Ani, 2008).



The huge gap between what should be considered and what is actually considered as

important factors to a task allocation decision results in issues and problems during the

development. The focus of this research is ineffective/problematic and ad-hoc task allocation

that results in GSD failure. Therefore we aim to bridge this gap via researching what are the

factors that should be considered, their importance and correlation and finally a well-defined

TA framework. The research aim, objectives and questions that this research tries to answer

are given below.

1.3 Research Aim

The aim of the research is to improve the task allocation process in GSD by facilitating the

practitioners in making informed and effective task allocation decisions. An effective task

allocation decision would be one which would remove the problems and issues currently

faced by the GSD task allocation industry e.g. re-allocation, delay and communication and

coordination overhead. To achieve the main goal of this research multiple objectives are

identified, which are achieved with the help of different research methods.

1.3.1 Research Objectives

The objectives of the research to achieve the goal mentioned above are given below.

Objective 1: To identify the critical factors and their relative importance during task allocation

decision by GSD practitioners’. To check the role of architecture, and applicability of

Conway’s law during task allocation decision.

Objective 2: To understand the dynamics of task allocation decision in GSD.

A survey is designed and executed to achieve objective 1 whereas an interview study is

conducted to gain in-depth knowledge of the process and dynamics of GSD (objective 2).

A TA framework is developed based on the information obtained from the above studies.

Therefore the third objective of the study is

Objective 3: To design an effective way to allocate tasks to distributed teams in GSD.

1.3.2 Research Questions

The objectives were achieved with help of the following research questions.



RQ1: What are the criteria for an effective Task Allocation decision in GSD?

RQ2: What is the relative importance and correlation among factors critical for an effective

Task Allocation decision making?

RQ3: What are the trade-offs that are performed during Task Allocation in GSD?

RQ4: How to effectively allocate and automate task assignment to distributed teams in GSD?

1.4 Research Methodology

We used a mixed method approach to analyse the problem consisting of survey, interview and

focus group session. Each study was designed and conducted to achieve different objectives.

Therefore we have used selective explanatory strategy of mixed method approaches to collect

and analyse data during the research process (Easterbrook, Singer, Storey, & Damian, 2008).

Quantitative data is collected and analysed followed by qualitative data which is analysed and

added to the results of the survey.

Initially the literature of GSD was studied in detail and the factors which are considered as

important for a task allocation decision were extracted. The literature related to factors,

strategies, approaches, models and algorithms for task allocation in a GSD environment was

surveyed and studied in detail. Back and Forth citation was scanned to identify related

articles. The literature provided us with the comprehensive dimensions of the problem and its

complexities that call for a meticulous planning process. The planning process can benefit

from industrial experience. Therefore, the first step to this research was an industrial survey

about the factors that influence the task allocation decision and their relative importance to the

practitioners, followed by interviews with GSD practitioners. The questionnaire used during

the survey largely consisted of closed ended questions therefore the responses were analysed

as quantitative data. Some of the findings of the survey were not aligned with the literature

such as low importance given to temporal and cultural distance. The findings of the survey

required further explanation along with understanding the dynamics of task allocation

decision, therefore an interview study was carried out to elaborate on the trade-offs and

situation specific variations. The interviews helped us in gaining detailed insight into the tacit

knowledge of task allocation process. The impact of these factors on project success or

productivity was not in the scope of this study.



The data from the survey and interview helped in developing a framework for task allocation

for GSD projects. The validation of the framework was carried via online focus group. The

framework was also compared with other strategies present in literature to highlight its

usefulness. Focus groups are suitable to acquire practitioners’ feedback in a cost effective

manner. The research method gives rich qualitative information and is very fast (Kontio,

Lehtola, &Bragge, 2004).

We performed the focus group to acquire practitioners’ feedback on the applicability of the

proposed TA framework. The focus group is used for analytical research questions where the

comprehension and applicability of the framework/model is questioned. We have used the

focus group for this purpose where the problems and gaps in the framework were identified.

The focus of survey and interview was different, whereas online focus group aimed to

determine the applicability of framework for real world GSD task allocation scenario.

Qualitative data regarding the utility and applicability of the framework was collected from

GSD practitioners. The focus group consisted of open ended questions.

The research process is divided into six main steps which are represented diagrammatically in

figure 3.1 in chapter 3.

The web based survey conducted via questionnaire from 54 GSD practitioners helped to

identify factors that influence task allocation and their relative importance as per their

experience. The correlations that exist between the factors are also identified via Spearman

Rho test. The need for a congruent mapping between product architecture and communication

and coordination needs is stressed in the literature (Conway’s Law)(Bass et al.,

2007)(Herbsleb & Grinter, 1999a)(Manuel E. Sosa,Steven D. Eppinger,Craig M. Rowles,

2004). The survey also helped to determine the applicability of Conway’s law in actual task

allocation performed by industry practitioners.

The interview study helped in comprehending the detail of task allocation decision. It added

detail to the already collected knowledge by providing information related to trade-off

between factors and the variance in relative importance of factors with respect to different

situations. The interviews were conducted via Skype, phone call and face to face meeting

from 10 GSD practitioners. The interviews were recorded and later transcribed into textual

data.



The data collected from the literature, survey, and interview helped in creation of a TA

framework for a GSD environment. The details of the framework are discussed in chapter 7.

The framework was validated and its applicability on real world was checked with the help of

an online focus group session from GSD practitioners throughout the world.

1.5 Thesis Contribution

The contribution of this research is manifold; we have gathered industry’s feedback on the

importance of task allocation factors, their correlations and the importance of architecture and

communication and coordination needs for a task allocation decision. The research is

beneficial to both the researchers and practitioners of GSD industry. The work has built

foundations of task allocation decision making, which can be extended by the researchers.

The practitioners can use the framework for informed task allocation decision in GSD

scenario. All the roles in a GSD organization involved in the task allocation decision making

process can benefit from the proposed TA framework.

1. Literature highlights many factors which are as important for task allocation decision

but it does not present a comprehensive list of factors validated by GSD practitioners.

Therefore all the factors explicitly or implicitly present in the task allocation literature

for GSD were extracted and presented to practitioners for ranking. A study also

identifies important attributes of a task allocation decision in a distributed environment

but the limitation of the study is the sample size (Lamersdorf et al., 2009). The survey

was conducted from 10 practitioners who were not given any list of factors identified

from the literature of task allocation. This led to the identification of new factors along

with validation of the already identified ones. It ensured the incorporation of the

researchers’ point of view which was later validated from practitioners via

questionnaire.

2. The dynamics of task allocation decision are identified with the help of an interview

study from GSD practitioners. The interviews from practitioners also helped to

identify the trade-off situations with respect to variations in GSD scenario. Therefore

the thesis highlights the relative importance of factors necessary for task allocation

decision along with the variations to task allocation decision. The variations are

related to task, expertise, organization and site. The study helped to understand the

tacit knowledge related to the task allocation activity. The interviews were recorded



and listened repeatedly to ensure that all related information was transcribed and

saved. The variations to the GSD scenarios, based on different types of tasks,

expertise, organization and sites helped to develop the framework.

3. The research has utilized the output of the survey and interview study to develop a TA

framework for GSD. The framework is based on the factors identified from literature

and survey and validated via global survey. It incorporates the variations that can

impact the task allocation decision and helps in effective allocation via careful

evaluation of the factors. The variations are depicted by the four planes in the

framework i.e. Task, Expertise, Organization and Site. The framework is also

validated from GSD practitioners with help of an online focus group session. The

feedback of the GSD practitioners is used to improve the TA framework.

1.6 Thesis Structure

The thesis has been organized with respect to the research methodology.

Chapter 2 details the back ground and literature review, explaining the problem of task

allocation in GSD and importance of Conway’s law along with highlighting the criteria or

attributes that are considered important by the research community for allocating task between

distributed sites during GSD. This criterion is extracted from research in form of factors either

reported by researchers as being important or considered while allocating task in a task

allocation strategy. The gap between what attributes should be considered and what are

actually considered during task allocation strategies is highlighted.

Chapter 3 describes the research process and details the design and execution of the industrial

survey and interview carried to identify the important factors that are considered during task

allocation by the practitioners. Input on the importance of architecture and communication

and coordination needs between distributed sites as a task allocation criterion is also taken

from practitioners. The survey instrument, sampling, survey execution and the objective of

interview, design and execution of interview study is discussed in detail. The interview study

has provided us with the detail to task allocation process including the trade-off decisions,

roles involved in task allocation the variation to GSD scenario and its impact on factors. An

online focus group was conducted to validate the proposed TA framework and check its

applicability for real work GSD scenarios.



Chapter 4 presents analysis of survey and interview data. The statistical tests applied on the

data and significance and correlations identified in the survey data are presented in detail. The

chapter also analyses the interview data and presents findings of the empirical studies. Threats

to Validity of both the survey and interview study are discussed in detail.

Chapter 5 highlights the findings and presents discussion around the major findings which are

compared and supported by literature. The findings of survey and interview are evaluated

together. The findings are compared and supported by literature.

Chapter 6 presents the proposed framework. The framework is built on the data gathered

from the empirical studies conducted in this research. The framework is composed of planes

which comprise of factors that are necessary for task allocation. The planes are the variations

to a GSD scenario, whereas the attributes present on each plane are the factors identified as

important for a task allocation scenario. Validation of the framework via online focus group

session is also given in chapter 6. Focus groups are suitable for validation of framework from

practitioners in less time and cost effective manner. It provides with rich qualitative results

from participants whose opinions and experience is valuable. However since GSD

practitioners are distributed globally we were unable to conduct a face to face focus group

session due to temporally distant sites, we created an online session on

“www.focusgroupit.com” and send invitations to participants who had already agreed to

participate. The discussion of the focus group participants is presented in Appendix F. The

improvements to the framework are also highlighted in the same chapter and presented under

revised framework section.

Chapter 7 concludes the research and presents future directions to the research. The

limitations of the research are also highlighted.

http://www.focusgroupit.com/



CHAPTER 2

Background and Literature

Review



G

2.1 Background

lobal Software Development is a special kind of distributed development

that suffers from many problems and difficulties. The geographical,

temporal, and cultural separation introduces communication and

coordination difficulties, lack of trust, rework due to misunderstandings

and time delay. However besides the challenges, the benefits of GSD

such as around the clock development, low development cost and vast

pool of expertise along with increased creativity attracts the software industry. The

advancement in communication and coordination technology makes GSD realizable. The

problems and challenges of GSD are due to the very nature and essence of globally distributed

projects that consist of geographic, temporal, and cultural distance. These distances manifest

themselves in form of difficulties and problems in executing the activities and processes of

GSD. Simple activities which are achieved with little effort in co-located development take

more time and effort in case of GSD. Task allocation also known as work assignment is one

such activity. It assumes complexity due to the very nature of GSD projects. The information

that task allocation activity depends on or requires is missing in case of GSD.

The distributed teams are called distributed due to their geographic separation only whereas in

virtual teams, the tasks distributed at multiple sites are also dependent on each other. Thus it is

possible for a team to be distributed but not virtual (Noll, Beecham, & Richardson, 2010a).

However distributed and virtual team is mostly used interchangeably in GSD context. The

virtual team distributed globally accomplishes GSD via (Noll et al., 2010a) determining team

and organizational structure between locations and determining the approach to task

allocation between locations. Therefore the importance of task allocation activity increases in

case of GSD.

The virtual team in case of GSD is also separated via time zone(s) and culture(s) due to which

they suffer from language barrier, fear and trust problems. These problems also materialize

due to difference in organizational structure, process issues, barriers deriving from

infrastructure and barriers due to product architecture(Noll, Beecham, & Richardson, 2010b).

The complexity factors (Keil et al., 2006)arising from just the geographic distribution known

as product, personnel and project factors give rise to communication and coordination

difficulties. Literature identifies communication and coordination (C&C) as one of the biggest

challenges for GSD teams (Kommeren&Parviainen, 2007). The cultural and temporal

distance in GSD also adds to communication and coordination difficulty (Ågerfalk et al.,



2005)(Bass, 2006)(Willcocks, Oshri, Kotlarsky, &Rottman, 2011). It also lacks the formal as

well as informal rich interaction between team members (Ågerfalk et al., 2005). The scenario

is further complicated when the tools, processes and information/ communication technology

(ICT) infrastructures vary across different remote locations (Willcocks et al., 2011). The

difficulties manifest in form of information sharing constraints, lack of shared understanding

and cultural fit etc. All of these issues contribute towards making GSD a challenge and also

gives rise to difficulties during task allocation activity. However many issues such as

communication and coordination overhead, difficulty to coordinate, cost overrun and time

delay can be reduced with the help of an informed task allocation decision.

2.1.1Task Allocation Problem in GSD

The task of assigning work to sites, teams or people is known as task allocation. This work

assignment is done between individuals and teams in case of co-located development whereas

tasks are allocated to distributed sites in case of GSD. The difference between both is that the

sites in GSD are distributed among different geographic, temporal and cultural zones.

Moreover they also have knowledge gap with respect to expertise, culture and norms etc of

remote sites. The sites can be multiple different organizations present in different countries

working together to accomplish GSD (offshore outsourcing), or they can be site offices of the

same organization distributed globally to accomplish software development (offshore in-

sourcing). In case of offshore outsourcing the different sites have their own organizational and

national culture, norms and ways of working, beliefs, languages and time zones. However in

case of offshore in-sourcing the organizational culture and ways of working would be same

whereas all the other things are different. Project Managers/Product Managers and other roles

involved in allocating tasks to these remote sites have little or no knowledge of the remote

sites making task allocation a challenging task. The remote team members do not know each

other and belong to different cultures (Bass, 2006). They also do not know the domain which

adds to the complexity to the task allocation problem. The number of sites also impacts the

allocation decision. Therefore lack of information of all these sites lead to ad hoc task

allocation based on superficial available evidence. A task allocation performed without much

thought given to the experience and expertise of team members, development cost, staff

turnover, communication and coordination infrastructure and cost etc. would result in

problems and issues during development of software leading to project delay.



One of the biggest challenges to a GSD project is coordination among distributed sites. Where

coordination as defined by management theory is the “management of dependencies among

task activities” (J. Alberto Espinosa1 et al, 2007). Coordination is also understood as

“activities to manage dependencies between tasks and task holders essential for orchestrating

large software project”. (Nguyen-Duc& Cruzes, 2013).

Coordination has many types/dimensions based on the following dependencies namely; (J.

Alberto Espinosa1et al,2007)(Begel, Nagappan, Poile, & Layman, 2009)(Nguyen-Duc&

Cruzes, 2013)(Wiredu, 2006) Technical Coordination (different parts of software work well

together or not)(J. Alberto Espinosa1 et al, 2007) also knows as Feature Coordination or code

coordination or application coordination (Begel et al., 2009)(Nguyen-Duc& Cruzes, 2013),

People Coordination (distributed developers, due to which conflicts arise)(Wiredu, 2006),

Temporal Coordination (dependencies in schedule) (J. Alberto Espinosa1 et al,

2007)(Nguyen-Duc& Cruzes, 2013) or release date coordination (Begel et al., 2009), Process

Coordination (dependencies between different software development steps) (J. Alberto

Espinosa1 et al, 2007)(Nguyen-Duc& Cruzes, 2013)(Wiredu, 2006), Resource Coordination

(team needed business domain knowledge from other team)(Nguyen-Duc& Cruzes, 2013),

Information Coordination (distributed information, due to which there are uncertainties and

equivocalitys’) (Wiredu, 2006) and Technology Coordination (distributed technology, due to

which there are different technology representations) (Wiredu, 2006).

It is reported that different roles in a project are in need of one type of coordination or another

e.g. managers mostly experience process and temporal coordination, whereas technical people

such as developers are in need of technical coordination. These coordination types also

influence one another (Nguyen-Duc& Cruzes, 2013). Some of the reported coordination

related problems of GSD are (Ågerfalk et al., 2005), problems due to different time zones

(increased cost of rework due to misunderstandings since you are working on off timings of

other), Synchronous team meetings difficulty, Reduced hours of collaboration, Coordination

complexity (not to rely on one person if he is not available then problem), Coordination

difficulty (due to geographic distance where the geographic distance can be due to national or

organizational boundaries (Nguyen-Duc& Cruzes, 2013) and as a result of lack of awareness

of what others are doing (Damian, Izquierdo, Singer, & Kwan, 2007)). The organizational

boundaries can be on firm level or department level. However the organizational distance can

be reduced with help of synchronization of collaboration policy, team organization,

engineering process and development practices (Nguyen-Duc& Cruzes, 2013).



An important factor which impacts the task allocation decision is the communication and

coordination difficulty in case of GSD. Communication is stated to be the largest source of

GSD problems due to difference in experience, type of projects, processes, training, cultures

and language of participants (Mockus&Herbsleb, 2001).

Formal as well as informal communications both are necessary for a successful GSD. GSD

needs planned communication patterns and higher flexibility and adaptability of processes

(Keil et al., 2006).

The teams either co-located or distributed communicate to coordinate on schedule, bugs, tests

and design reviews (Begel et al., 2009). Different types of communication used for

coordination in projects are (Morelli, Eppinger, & Gulati, 1995), Coordination type

communication (used for technical information transfer, for task coordination), Knowledge

type communication (used for consultation and instruction and skill development) and

Inspiration type communication (used for motivation of individuals).

The communication in case of distributed development especially GSD assumes complexity

due to difference in national and organizational culture (Al-Ani & Edwards, 2008) and

geographic distance. The increase in geographic distance decreases the amount of

communication even if the distance is 30 meters (Morelli et al., 1995). It is evident from a

trial system being developed at Motorola by globally distributed offices. The experience show

that distance makes communication difficult (Battin et al., 2001).

The reasons that contribute to communication difficulty are difference in organizational

structures, incentive systems, geographical locations, leadership styles and project

management practices (Morelli et al., 1995). The communication issues generated by different

working hours are often addressed through intranet connectivity, conference calls and

travelling.Difference in language proficiency also creates barriers to communication between

distributed teams, and time zone difference limits possibility of synchronous communication

(Noll et al., 2010a). Loss of communication richness is referred as one of the main problems

of distributed development (Battin et al., 2001).

Other communication related problems reported in literature are (Ågerfalk et al.,

2005)(Mockus&Herbsleb, 2001), Lack of informal communication, dependency on

communication technologies, lack of awareness of who to contact and increased effort to

initiate contact (thus most people work without communicating to the person who has

knowledge of a specific part of a system), asynchronous communication preferred by non-



native speakers due to language problems and different working hours, misunderstandings due

to language problems and lack of trust etc.

The importance of communication and coordination between sites also known as the

information flow requirement between teams) and product architecture for TA decision is

highlighted by many (Tripathy, A. ; Eppinger, S.D., 2010). Conway and Parnas have

identified the relationship between the communication and coordination needs and product

architecture. To modularize work such that they have little technical dependency between

modules results in reduced communication and coordination overhead between distributed

sites/teams (O’Conchuir et al., 2006). One way to reduce coordination need is to make a

simple and understandable architecture with well-defined interfaces and concise semantics of

network elements (Battin et al., 2001). The next section details the work done keeping in view

Conway’s law.

2.1.2 The Triangle

The literature on task allocation in GSD relates communication and coordination needs, task

allocation and the architecture of the system. Task allocation literature along with evidence on

communication and coordination in GSD emphasize the importance of architecture as a major

artefact for effective and efficient development (Manuel E. Sosa,Steven D. Eppinger,Craig M.

Rowles, 2004). The architecture divides the system into independent modules resulting in

modularity. If task allocation to distributed sites is performed keeping in view the modular

aspect, it results in less communication and coordination overhead and thus reduced time

delay, however all depends on a well-defined and modular architecture. Architecture that

requires involvement of multiple sites to implement a change effects productivity. Moreover

if the architecture is unstable and changes within the course of the project, it creates confusion

between teams on their responsibilities (Noll et al., 2010a). Interdependent modules also

create coordination problems (Mockus&Herbsleb, 2001).

Since the architecture is of three types (Tripathy, A. ; Eppinger, S.D., 2010), synchronization

between the three is also necessary to handle the interdependence.

1. Product architecture (functionality allocated to physical component)

2. Process architecture (set of tasks and information flow between the tasks that sum up

to produce the final product)

3. Organization architecture (organizes sub teams in a project involving the development

of system/product and the information flow between them).



2.1.2.1 Conway’s Law

The relationship between system modules and organizational structure is highlighted in

Conway’s law which states that communication and coordination takes place keeping in view

the technical dependencies between system modules and vice versa. This law is being used for

various purposes, one of which is to facilitate task allocation decision. It is also being used for

the identification of communication and coordination requirements, defect identification,

reverse engineering and task allocation.

How to reduce the management overhead via the use of Conway’s law with the help of the

identification of socio-technical clashes in agile development is found with the help of a

single case study (Amrit&Hillegersberg, 2007). The study used the social network analysis to

identify the communication and coordination and technical dependency mismatches. Software

repositories are used to extract the technical dependency between tasks using the coordination

between people working on different artefacts. This information will help to identify the

socio-technical congruence essential for smooth software development (Valetto et al., 2007).

Mailing list, bulletin boards can be used to extract information of collaboration among people

whereas source code static review can be used to extract code dependency. Modifications

done by people on a specific artefact can be used to extract relationship between people and

artefacts. It is found that more defects are found when congruence is low whereas fewer

defects are found when congruence is high.

The communication requirements are identified based on the architecture of the product

(Avritzer et al., 2010), which can only be done if the architecture is developed early. Such an

approach will result in reduction of communication and coordination with the stability of

architecture. Design Structure Matrix (DSM) is used to model communication and

coordination among team members and architectural dependencies (Avritzer et al., 2010).

Similarly Conway’s law has been used to identify candidate chucks that can be distributed

(Mockus& Weiss, 2001). The study is based on modification requests that span multiple

locations.

The communication linkages from technical dependencies are identified and then compares

them with actual communication undertaken to identify the difference between the two

(Morelli et al., 1995). It is seen that 81% of the communication is predicted in advance

keeping in view the technical dependencies depicted in product architecture. Thus architecture

of the product can also derive task allocation. A similar work(de Souza, Quirk, Trainer,

&Redmiles, 2007) determines social dependencies between people based on code



dependencies visible in architecture of the product . A tool Ariadne was specifically used on

three real world scenarios to determine the code dependencies using call graphs and derive

social dependencies from it. The social information is in the form of “who depends on your

code and who you depend on”. The tool also displays information in visual format to increase

comprehension.

The concept of ownership architecture is used to perform reverse engineering and create

architecture for projects with no design and architecture such as Linux etc.(Bowman & Holt,

1998).The ownership architecture is extracted by the people who worked on two subsystems

therefore creating a dependency between the subsystems. Conceptual architecture is made

from available documentation. Concrete architecture is extracted from actual system

implementation.

Research has also identified that teams communicate apart from the technical dependencies

present in architecture and sometimes do not communicate where technical dependencies are

present(Manuel E. Sosa,Steven D. Eppinger,Craig M. Rowles, 2004). The stability of the

architecture is required to understand the task interdependence for task allocation (Mullick,

Bass, Houda, Paulish, &Cataldo, 2006). Moreover, the research is still fresh and has not been

validated on a large scale. It also aims to identify the applicability of Conway’s law in actual

practice from industry practitioners.

2.2 Literature Review

We are interested in the task allocation literature that specify allocation strategies or motivates

the use of certain criteria for globally distributed projects. The literature survey includes TA

strategies, models, frameworks and guidelines. The literature review also consists of studies

that motivate the use of important factors necessary for effective task allocation decision. We

used a traditional approach of searching the relevant literature. The literature was searched

with help of the terms “task allocation in GSD” or “work assignment in GSD” in main

databases of computer science and software engineering. We also performed scanning of back

and forth citation to identify the relevant literature. A Systematic Literature Review (SLR)

was not performed; however the results of a SLR and an industrial survey performed in 2017

(Mahmood, Anwer, Niazi, Alshayeb, & Richardson, 2017) are compared with the result of

this research discussed in detail later on.



The focus of the literature survey was to identify the important factors for task allocation

decision in GSD. Therefore all the literature on task allocation strategies/approaches/factors

and coordination strategies between distributed sites, and team structuring approaches in a

distributed setting is included. The factors have been identified from strategies/ approaches

where they have been implicitly considered for allocation and from the literature of factors

where they have been explicitly highlighted as important for task allocation decisions.

The literature review shows that the task allocation strategies are mostly based on single or

limited criteria, where expertise, software development phases, time difference and product

architecture along with communication and coordination needs are the most common ones.

Some researchers have proposed strategies that are based on multiple factors and also evaluate

the correlation between the factors (Lamersdorf & Münch, 2010b)(Sooraj&Mohapatra, 2008),

however they suffer from limited sample size.The list of factors identified from literature is

presented one by one with supporting evidence.

Labour costs motivate organizations to pursue distributed development and hence play a vital

role in the task allocation decision (Lamersdorf& Munch, 2009)(Lings et al., 2007)(Narendra,

Ponnalagu, Zhou, & Gifford, 2012)(Fernandez &Basavaraju, 2012)(Ruano-Mayoral, Colomo-

Palacios, Fernández-González, &García-Crespo, 2011)(Wickramaarachchi& Lai,

2013)(Marques et al., 2013)(Alsri, Almuhammadi, & Mahmood, 2014), (SimãoFilho,

Pinheiro, & Albuquerque, 2017). It is one of the most commonly used criteria for task

allocation, and a major allocation criteria (Mahmood, Anwer, Niazi, Alshayeb, & Richardson,

2017).

Expertise and knowledgealso play an important role in the task allocation decision

(Lamersdorf& Munch, 2009)(Edwards et al., 2008)(Lings et al., 2007)(Grinter et al.,

1999)(Ruano-Mayoral et al., 2011)It is the most important deciding factor when the goal of

off-shoring decision is finding specific expertise or skill set (Fernandez &Basavaraju,

2012)(Wickramaarachchi& Lai, 2013)(Marques et al., 2013)(SimãoFilho et al., 2017). Big

organizations have specialized teams for different areas of expertise (Lamersdorf et al., 2009).

The competence level approach works by finding and allocating tasks to the required

expertise (Avritzer et al., 2010). Technical and domain expertise both play their part during

site selection (Avritzer et al., 2010). Technical expertise is also highlighted as an important

allocation factor by industry experts (Mahmood et al., 2017). Time-displaced expertise can

also be utilized in the case of the follow the sun configuration known as a consultative group

(Gorton &Motwani, 1996). Expertise is a major deciding factor in the case of virtual teams



(Tran &Latapie, 2006). Many approaches allocate tasks keeping in view the expertise of

teams such as transfer by functionality (Mockus& Weiss, 2001), functional area of expertise

(Grinter et al., 1999) and competence centre organizational approach (Avritzer et al., 2010).

These approaches ensure that each site works on what is it trained for. It also ensures better

load balancing as team works on multiple projects from its own expert domain (Grinter et al.,

1999). This approach also helps in training of novices as they work with experienced

professionals in a team (Grinter et al., 1999). The disadvantage of such an approach is that

multiple sites are involved in case of change (Mockus& Weiss, 2001). Problems can also arise

when there is confusion regarding who is responsible for a specific task or piece of work

(Grinter et al., 1999).

Site Characteristics including analyst capability, programmer capability, language and tool

experience, personnel continuity and customer proximity, are a variable factor in the task

allocation decision (Münch&Lamersdorf, 2009). These factors affect the task allocation

decision by impacting the evaluation criteria such as effort and quality (Münch&Lamersdorf,

2009). Proximity to customer also affects the decision of task allocation (Lamersdorf&

Munch, 2009)(Ruano-Mayoral et al., 2011)(Wickramaarachchi& Lai, 2013)(Marques et al.,

2013)(Alsri et al., 2014)(SimãoFilho et al., 2017)and basis for many allocation approaches

such as transfer by localization (Mockus& Weiss, 2001) and customization (Grinter et al.,

1999). Transfer by localization transfers work of modification for local market to the site

nearest to it. It demands presence of all required expertise at that local site. The customization

approach distributes work by keeping all the core code at one site where as other distributed

sites are involved in enhancement and customization for local market. The approach requires

the core and custom code to be clearly separated which is also a good design. Delay can come

if expertise of the core code site is required by the custom code site (Grinter et al., 1999).

Technical experience is another important attribute considered in the task allocation decision

(Lamersdorf & Münch, 2010b). Team capability is observed as a deciding factor in the case

of product phase model, where the initial development is done by a capable team and given to

a less capable team once the product is stable enough (Mockus& Weiss, 2001)(Tran

&Latapie, 2006). The capability of the team is also highlighted as an important factor along

with development quality by practitioners (Lamersdorf et al., 2009).The attrition

rate/turnover rate should also be verified before finalizing a site for distributed work (Lings

et al., 2007)(Lamersdorf et al., 2009)(SimãoFilho et al., 2017).



Task-Site Dependency including application experience and platform experience, are also

considered during task allocation (Münch&Lamersdorf, 2009).

Process Ownership is also considered by the task allocation literature as an important

attribute in task allocation (Edwards et al., 2008). It is defined as placing ownership with

those who are closest to the process, who experience its bottlenecks and inefficiencies

(Fitzgerald & O’Kane, 1999). Literature of software process improvement associate process

ownership as an improvement strategy, one that has a profound impact (Rainer & Hall, 2002).

Process owners are responsible for getting the work done by workers who may not be in the

same organizational unit. They are accountable for the process and are responsible for

designing it, ensuring the execution and high performance of the process (Larsen

&Klischewski, 2004).

Task Characteristics such as the size of the task, should also be considered in the task

allocation approach (Münch&Lamersdorf, 2009)(Mahmood et al., 2017)(Ruano-Mayoral et

al., 2011).

Product Architecture is considered as the deciding factor for allocation to distributed sites

by many (Setamanit et al., 2007)(Avritzer et al., 2010)(Clerc et al., 2007)(Componation&

Byrd Jr, 2000)(Lings et al., 2007)(Tran &Latapie, 2006)(Amrit& van Hillegersberg,

n.d.)(Amrit&Hillegersberg, 2007)(Lamersdorf et al., 2009)(Mahmood et al., 2017), especially

when using a module-based strategy or product structure or component integration model.

Independent or loosely coupled modules are assigned to distributed sites. The metric of work

coupling is same as the product architecture as task dependencies are measured as coupling

between work (Münch&Lamersdorf, 2009)(Lamersdorf & Münch, 2010b)(Lamersdorf&

Munch, 2009)(Mockus& Weiss, 2001)(Grinter et al., 1999)(Fernandez &Basavaraju,

2012)(Marques et al., 2013). Team structuring approaches such as the framework integration

model (Tran &Latapie, 2006) and platform based model (Avritzer et al., 2010) develop the

core at one site, whereas applications and enhancements are built at others, hence they also

use the product architecture as a criterion for task allocation.

An algorithm is developed which (Mockus& Weiss, 2001) identifies candidate chunks (chunk

of code that needs to be changed). The algorithm works on three principals which are:

Modification request that modify the candidate and also other parts of the system should be

reduced, Modification request that involves participants from multiple sites to modify the

candidate should be maximized and the effort required for modification request should match



the sites resource capability. Therefore the three factors that impact the choice of suitable

location for transfer of work are work coupling, amount of effort and learning curve.

Communication and Coordination (C&C) requirement between distributed teams or sites

is an important factor for work assignment (Herbsleb&Moitra, 2001)(Amrit&Hillegersberg,

2007)(Avritzer et al., 2010)(Lamersdorf& Munch, 2009)(Lings et al., 2007)(Componation&

Byrd Jr, 2000). The cost of communication and coordination should be low in an effective

allocation (Narendra et al., 2012). Work based on Conway’s law has specifically highlighted

the need for considering C&C need and mapping the product architecture for smooth

distributed development (Bass et al., 2007)(Mockus& Weiss, 2001)(Manuel E. Sosa,Steven

D. Eppinger,Craig M. Rowles, 2004). Literature consists of work focused on identifying the

suitable site keeping the communication and coordination requirement low (Mockus& Weiss,

2001).This allocation strategy is aligned with Conway’s Law which states that the “product

structure is the mirror image of the organization that designed it”. Empirical evidence also

supports that this law holds in practice (Avritzer et al., 2010). Social network analysis has

been used to identify the actual communication requirements. Design structure matrix is used

to identify the explicit design decisions or coupling between modules/components.

Communication and coordination needs can also arise due to state management, schedule

synchronization and resource utilization, resulting in task interdependence (Bass et al., 2007).

Such dependencies considered along with module dependencies should be considered for

effective allocation (Bass et al., 2007). Communication cost is used as criteria for allocation

where it depends on geographical, cultural, temporal, language and social differences

(Vathsavayi, Sievi-Korte, Koskimies, &Systä, 2013).

Personnel Availability should also be considered, as the personnel maybe assigned to other

tasks or absent (Edwards et al., 2008)(Lamersdorf et al., 2009)(Fernandez &Basavaraju,

2012)(Wickramaarachchi& Lai, 2013)(Marques et al., 2013)(SimãoFilho et al., 2017).

Workload of the team is also highlighted as important during GSD (Lings et al., 2007). Both

factors that are personnel availability and workload of the team member is included in the

final list of factors. Personnel availability accounts for holidays or unavailability of personnel

due to other project obligations whereas the workload defines an accommodating but busy

schedule. Therefore, even if the required expertise is available at a distributed site but it has a

high workload due to other commitments, urgent tasks with firm schedules cannot be assigned

to that site.



Site dependencies composed of cultural and temporal differences are identified as a variation

factor during task allocation (Münch&Lamersdorf, 2009)(Narendra et al., 2012)(Ruano-

Mayoral et al., 2011)(Wickramaarachchi& Lai, 2013), (Marques et al., 2013), (Alsri et al.,

2014), (SimãoFilho et al., 2017). Difference in organizational as well as national culture

impacts the task allocation decision(Fernandez &Basavaraju, 2012). Tasks that require close

collaboration should not be assigned to culturally distant sites; doing so would result in

misunderstandings, rework and delay. Language difference is highlighted as an impacting

factor by some researchers whereas incorporated in cultural difference by others. The

temporal distance or time zone difference is also a deciding factor in the follow the sun task

allocation strategy (Espinosa & Carmel, 2003)(Setamanit et al., 2007)(Gorton &Motwani,

1996)(Lings et al., 2007)(Tran &Latapie, 2006)(Mahmood, Anwer, Niazi, Alshayeb, &

Richardson, 2017)(Kroll, Friboim, &Hemmati, 2017)(Doma, Gottschalk, Uehara, & Liu,

2009). The strategy is chosen to reduce the time to market by ensuring 24-hour development

by making use of the overnight gain effect (Gorton &Motwani, 1996)(Gupta, Crk, &Bondade,

2011) . There is a need for effective coordination for the success of 24 hour development.

Temporal distance is computed on the basis of time zone differences along with workday

differences, i.e., the start and end of the workday, weekend differences, holiday differences

and different lunch and other break hours (Espinosa & Carmel, 2003). Considering time

difference, cultural difference along with language difference between distributed sites is

stressed by a major work on task allocation in GSD (Lamersdorf&Münch,

2010b)(Lamersdorf& Munch, 2009). Cultural difference and time zone difference impacts the

work distribution decision (Tran &Latapie, 2006)(Clerc et al., 2007)(Münch&Lamersdorf,

2009). Virtual teams also make use of the time zone difference(Tran &Latapie, 2006).The

virtual teams can be organized in different models with variant project management and

interaction structure. The models for organizing virtual teams are cooperative, delegation and

consultative. The cooperative distributed teams cooperate with each other to accomplish

software development tasks via utilizing the overnight gain effect. The involvement of all

groups is required in the decision making concerning management of project e.g. schedules,

estimation etc., however the main project management responsibility is with one group only.

The delegation group has a supervisor group and a worker group, where the supervisor group

makes the project management decisions. The worker group provides services to the

supervisor group and helps it by achieving overnight gain effect. The supervisor group is

more experienced than the worker group. The consultative model exists when services of an

expert group are engaged usually for a short duration. The deadline is negotiated and the



expert group is responsible for achieving the time line. One expert group may work on

different projects providing services in the expert domain via utilizing overnight gain effect in

case of different time zone sites. The work is also allocated to distributed teams in different

time zones keeping in view operational and resource constraints (Jalote& Jain, 2006).Some

organizations prefer variant culture from the centre to make use of different ideas (Carmel &

Agarwal, 2001).

The implicit dependency present between different phases of software is the only criterion

used in phase-based task allocation (Setamanit et al., 2007)(Avritzer et al., 2010)(Lings et al.,

2007)(Grinter et al., 1999)(Mockus& Weiss, 2001) also known as task dependency

(Mahmood et al., 2017).Transfer by development stage, also known as phase based allocation

assigns different stages of software development to different sites e.g. testing is done at one

site whereas development is done at another (Grinter et al., 1999)(Setamanit et al., 2007).The

product phase model also outsources the maintenance stage to the distributed site(Tran

&Latapie, 2006). The testing phase is usually outsourced to time-displaced sites in case of

follow the sun (Gorton &Motwani, 1996).This approach is also known as process steps

(Grinter et al., 1999)(Avritzer et al., 2010) where different software development steps are

used as hands off between sites. The approach is beneficial as specific software development

phase such as requirement engineering can be placed at the site which is near to the local

market. The communication and coordination overhead increases in such configurations since

each site is expert only in one domain and requires information about the activity done at the

other site (Mockus & Weiss, 2001). Problems can also arise due to delay of a software

development phase (Grinter et al., 1999). The product phase model is similar to this approach

where the ownership of the product is taken by distributed teams during its life time (Tran &

Latapie, 2006). Proper hands-off procedures are employed, and the team which hands over the

work and takes on a new responsibility. The quality of the product depends on the team’s

capability and can result in loss of tacit information during transition between teams. Transfer

by maintenance also transfers the work related to maintenance to a secondary site,

communication and coordination will again increase in case if the expertise of primary site is

required during maintenance (Mockus& Weiss, 2001). However the phase dependency is

more important for project decomposition than the allocation strategy (Edwards et al., 2008),

therefore is not included in the final list of factors.

The goal of the TA strategies varies across the literature. The module-based, phase-based and

follow the sun approaches are evaluated for project duration (Espinosa & Carmel,



2003)(Setamanit et al., 2007). Effort and risk models are proposed to improve the task

allocation decision by evaluating the impact of task allocation factors on productivity (Keil et

al., 2006). The clustering approach is evaluated for project duration and total risk

(Componation& Byrd Jr, 2000). The amount of effort, work coupling and learning curve are

determined for each candidate site identified via an algorithm based on modification requests

for task distribution (Mockus& Weiss, 2001).

We have not included strategies such as the open source structure (Avritzer et al., 2010) as the

product is developed via independent contributions, and no specific allocation activity is

performed. We have also not included factors that have a low occurrence as reported by the

literature (Lamersdorf et al., 2009). Therefore, willingness at site, development quality, trust

or vendor reliability, maturity of site or vendor, strategic planning and personnel, local

government regulations, requirement stability, intellectual property ownership, geographic

distance and political reasons are not part of the final list. Release based allocation is also one

such factor where every site is responsible for a different release (Avritzer et al., 2010). The

distributed sites may work in parallel to meet the time to market in release based allocation.

A detailed TA model also proposed which is based on multiple influencing factors, it

identifies the best task allocation assignment (Lamersdorf&Münch, 2010b). The factors are

evaluated for achievement of certain goals such as productivity, communication and

coordination problems, trust and effort. The characteristics which are evaluated for the

selection of the best assignment are related to task, site, task-site dependency, site-site

dependency and task-task dependency. These factors are task complexity, time zone

difference, cultural difference, language difference, personal relationship, technical

experience, technical infrastructure, application experience and work coupling. The inter-

relationship between factors is also determined for effective allocation. The model is also

implemented via tool and validated via case study. However the data is collected from limited

number of interviews. The literature survey of both the strategies and approaches and

important factors for TA highlight the lack of standard criteria for TA decision. The goal of

GSD impacts the value of the factors however the deciding criteria should be same. Therefore

we have proposed a list of 10 important factors important for a task allocation decision in

GSD.



2.2.1 Finalized Factors for Task Allocation

The detailed literature survey has highlighted the use of single or limited criteria used by the

task allocation strategies/ approaches, models and algorithms ignoring the many important

factors during the decision making process. The lack of any standard task allocation decision

making in GSD motivated us to perform an industrial survey to understand the task allocation

decision making process by the practitioners. Moreover, the literature highlights the use of

Conway’s law during allocation decision but is not evident in many strategies and approaches.

The complex and multifaceted GSD environment require a sound task allocation strategy

based on important factors where a standard set of information should be considered by all the

GSD projects. Trade-off between factors can take place based on different situation and

project type. The factors identified from the literature survey have a profound effect on the

task allocation decision. The final list of factors is given below which consists of 12 factors.

1. Labour Cost

2. Expertise

3. Site Characteristics (Analyst Capability, Programmer Capability, Language and Tool

Experience, Personnel Continuity and Customer Proximity)

4. Task Site Dependency (Application Experience, Platform Experience)

5. Task Size

6. Process Ownership

7. Personnel Availability

8. Work Load at Distributed Sites

9. Component Dependency

10. Communication and Coordination Overhead

11. Time Difference

12. Cultural Difference

A systematic literature review to identify the factors necessary for task allocation published in

2015 (Mahmood, Anwer, Niazi, Alshayeb, & Richardson, 2015) identifies site technical

expertise, time zone differences, resource costs, task dependencies, vendor reliability, task

size, vendor maturity level, local government regulations, requirement stability and product

architecture and intellectual property ownership in the empirical literature of GSD. The results

of the SLR on the factors for task allocation are almost the same as those presented in this



section. Mapping of the factors identified as part of this research is done with the factors

identified via SLR Table 2.1 below.

Table 2.1: Comparison of Identified Factors with those of SLR (Study published in 2015)

Initial Factors Identified in this

Research

Factors from

SLR

Comparison with Factors present in Final Framework

Labour Cost Resource Cost We later changed this factor to Development Cost incorporating

resource cost as well

Expertise Site Technical

Expertise

Expertise is a variation in our framework with attributes of its

own.

Site Characteristics (Analyst Capability,

Programmer Capability, Language and

Tool Experience, Personnel Continuity and

Customer Proximity)

Task Site Dependency (Application

Experience, Platform Experience)

Task Size Task Size

Process Ownership

Personnel Availability

Work Load at Distributed Sites

Component Dependency Task Dependency,

Product

Architecture

Component dependency incorporates the dependency between

task due to architecture, there may be other dependencies due to

software development phase etc. however we feel it is more of a

project decomposition strategy than a factor for allocation.

Communication and Coordination

Overhead

Time Difference Time Zone

Difference

Time difference is calculated on the basis of different time zone,

different holidays and lunch/coffee breaks etc.

Cultural Difference

Vendor Reliability We later incorporated a factor of Trust which is measured on the

basis of prior experience.

Intellectual

Property

Ownership

Incorporated in the final framework under the factor Legal

Issues (Identified from Focus Group Discussion)

Requirement

Stability

Volatility of the task handles the stable nature of the task which

will be based on requirement stability, Volatility is incorporated

as an attribute of task in the final framework.

Local Government

Regulations

Legal issues incorporate the issues related to development of

software at a particular site which may incorporate government

regulations etc. It is defined as an attribute of the site in the final

framework



Vendor Maturity

Level

Maturity is identified as an attribute of organization based on the

CMM level the organization has acquired (present in the final

framework).

The comparison shows that the literature studied as part of this research is more detailed,

Moreover the missing factors are already part of the proposed framework described in detail

in Chapter 6 as a result of the data obtained from Survey, Interview and Focus Group Study.

The search performed to update the literature review has identified local government, process

maturity and IP security as influencing factors to task allocation decision (Lamersdorf,

Munch, Fern, & Rebate, 2011). Risk to project quality, impact of late delivery, team priorities

and training operations along with strategic fit and days saved are highlighted as important

attributes that effect the final transfer decision. Detailed work of Ansger et al. have identified

factors that impact the effort required to develop the software at a particular site (Lamersdorf,

Munch, Fernandez-del Viso Torre, Sánchez, &Rombach, 2010). The factors considered are

process maturity, communication infrastructure, formality of task description, requirement

stability, common experiences, extend of disciplined project management, coupling between

tasks, task criticality, task complexity, number of sites, technical knowledge and project

experience (Lamersdorf&Münch, 2010a)(Marques et al., 2013). Skill set required for the task,

Complexity and criticality and budget of task is highlighted as important characteristic , time

line of the project is also highlighted as important(Marques et al., 2013). Performance rating

of the human resource as well as location is highlighted as an important factor to task

allocation (Vathsavayi et al., 2013). Development time, Temporal difference, Geographic

distance, Economic situation, Collaboration history, Strategic Considerations, Software

development maturity and Human Resource Management maturity, Trust are highlighted as

important for GSD task allocation decision (Ruano-Mayoral et al., 2011)(Ruano‐Mayoral,

Casado‐Lumbreras, Garbarino‐Alberti, &Misra, 2014). Geographic distance is highlighted as

important inside site dependency matrix category (Wickramaarachchi& Lai, 2013),

collaboration maturity and political relationship. Economic and political stability are

identified under site specific characteristics (Wickramaarachchi& Lai, 2013). Features and

related artefacts is also highlighted as important for task allocation (Marques et al., 2013).

Collaboration maturity is also highlighted as important (Alsri et al., 2014). Reliability and

quality is associated with site as its attribute by (Alsri et al., 2014). Knowledge of business,

maturity of project manager, maturity of team, trust, willingness at site, maturity in process,

good communication infrastructure and language fluency (SimãoFilho et al., 2017).



The literature clearly emphasizes the ambiguity with reference to the factors necessary for a

task allocation decision in GSD. Multiple important factors and their need for explicit

consideration during a task allocation decision is advocated, but are absent in the task

allocation approaches and strategies. This highlights a huge knowledge gap, which can only

be filled with help of practitioners’ feedback. The rest of the research is designed and

executed keeping in view this knowledge gap. The main objective was to fill this gap with

help of feedback from industry practitioners’.

The chapter presents the related work highlighting the factors important to a task allocation

decision in GSD. The final list of factors identified as important to a task allocation decision

is given. Comparison of the final list of factors with another related and recent is also

provided in tabular format. The comparison highlights the coverage of the literature review

performed as part of this research work, the differences is highlighted and comments

incorporated specifying the inclusion or exclusion of the factor in the final factors of

important factors obtained via multiple industrial studies. The next chapter details the research

process followed to carry out this research. It presents the design of the industrial survey,

interview and focus group study. The research methods are mapped to the objectives, which

are to be achieved as a result of that particular study.



CHAPTER 3

Research Design



T

3.1 Research Design

He research used a mixed method approach to perform field research. We

were interested in identifying the practitioners’ way of performing task

allocation in GSD projects. Survey and Interview both were used to acquire

quantitative as well as qualitative information regarding task allocation

decision. The use of both quantitative and qualitative method facilitates the

collection of enriched data(Kothari, 2004).A framework for task allocation

was developed using the qualitative and quantitative data acquired from practitioners of GSD

projects. Survey study helped us in covering the breadth of the GSD industry whereas the

interview study helped in acquiring in-depth detailed knowledge of the task allocation

decision. Both these approaches complement each other and helped in acquiring enriched

data. The framework is then validated with the help of a focus group study. The research

process is elaborated in section 3.2. The pictorial representation is given in figure 3.1 below.

Figure 3.1: Research Design

3.2 Research Process

The research process chosen for this thesis consists of a detailed literature review, followed by

an industrial survey. The focus of both these studies was to identify the factors necessary for

task allocation. However the industrial survey was aimed to identify the important factors

along with their ranking by the practitioners. It also aimed to identify the role of product

architecture and communication and coordination needs for task allocation decision while



keeping in view the Conway’s Law. An interview study was conducted after the survey to

understand the task allocation dynamics in detail. The study focused on understanding how

trade-offs are performed in practice; does the importance of task allocation factors change

with situation. The focus of the study is a design question (how to effectively distribute tasks

among distributed teams in GSD?), where we wanted to identify an effective way of

allocating tasks to GSD teams (Easterbrook, Singer, Storey, & Damian, 2008). However the

design question is answered with help of knowledge questions; frequency and occurrence

question as well as relationship question. We are interested in finding the factors important to

a task allocation decision as well as the correlation between them (Easterbrook et al., 2008).

Survey and interview study were suitable for this research due to population being distributed

around the globe and need for detailed knowledge respectively.

The research followed a sequential explanatory strategy (Easterbrook et al., 2008) where the

survey provided quantitative data and interview study was used to acquire detailed qualitative

data. The literature survey is discussed in detail in Chapter 2. The factors were identified from

the task allocation strategies/approaches/algorithms/models and literature which only lists or

presents important factors in task allocation decision in GSD. We surveyed the literature using

the traditional method of snowballing i.e. reviewing references of a research publication and

reading the interested ones only. The process continues until you get material one has already

studied. We did not perform a systematic search, which is one of the limitations of this

research, however we have compared the results of our study with that of an Systematic

Literature Review published in 2015 (Mahmood et al., 2015). An industrial survey was

conducted to identify the factors which are considered important for a task allocation decision

by the practitioners of GSD industry along with the importance assigned to them. The survey

also focused on identifying the role of architecture and communication and coordination

needs during task allocation. The survey design is presented in detail in the following section.

3.2.1 Industrial Questionnaire Based Survey

Web survey is an effective methodology to answer the research questions mentioned earlier. It

has the ability to reach and gather the opinions and experience of GSD practitioners around

Objective: To identify the factors considered as important for task allocation in

GSD projects by the practitioners. Also to understand the role played by

architecture of the system. To check the applicability of (Conway’s Law) during

task allocation of GSD projects.



the globe (Schmidt, 1997)(Wright, 2005). The survey can also measure multiple variables at a

time.

The Survey was conducted to answer the following questions

RQ1: What are the criteria for an effective Task Allocation in GSD?

RQ2: What is the relative importance and correlation of factors important for an effective

Task Allocation?

The survey type was “Cross Sectional” where the focus was to acquire opinion of the people

working in GSD industry at a single point in time (Kothari, 2004). The population of the

survey was Project Managers and Architects of Global Software Development (GSD) Projects

along with other roles involved in task allocation decision during GSD. The major role

involved in such decisions is that of the project manager or product manager; however we did

not limit the survey to only these roles since other roles may be involved in the task allocation

decision. We excluded researchers from the population since we were only interested in

practitioners’ feedback.

The type of sampling chosen is non probability sampling and snow balling technique for data

collections due to lack of knowledge regarding GSD organizations. Exponential Non-

Discriminative Snowball Sampling used as the first chosen subject refers to multiple subjects,

and all of these multiple subjects are chosen as the next subject (Patrick, Pruchno, & Rose,

1998). The initial organizations are the seed organizations which helped in determining more

contacts for the next wave. The total number of waves decided was 5.

We divided the GSD population region wise that is we choose the following main continents:

Europe, Asia, Australia, North America, South America, and Africa. Countries from each

region active in GSD were finalized based on availability of contact. The initial list of

countries selected from each continent included Europe (Sweden, Finland, Luxemburg,

Ireland, UK, Norway, Switzerland), North America (United States, Canada), South America

(Brazil), Australia (Australia), Asia (China, India, Pakistan, UAE) and Africa (South Africa).

Questionnaire was used as an instrument for acquiring practitioners’ response. It consisted of

a mix of structured (closed ended), unstructured (open ended questions) and partially

structured questions. Open ended and partially structured questions were used to gather new

task allocation factors or information unknown to us, whereas closed ended questions were

used for ranking of already known factors. Closed ended questions consisted of rating and



ranking questions and dichotomous questions. The survey questions measured data on

nominal and ordinal scales, where a 5 point Likert scale from (very important to unimportant)

was used for ordinal data. The “Do not know” option was added to reduce the noise in the

response data (AlexenderDobronte,2014.). The final questionnaire uploaded for acquiring

practitioners response is given in Appendix A.

The Survey was administered via email and hosted on web due to vast population of GSD

organizations as well as inability to reach all in person. The seed organizations are required to

forward the link to their contact organizations in next wave or provide contact information of

new GSD organizations. To increase the sample size, we also took help of social media and

email for posting the survey on GSD groups and organizations. The social sites Facebook,

LinkedIn and Twitter were used for increasing the sample size. The questionnaire was

designed and piloted before finally posting it online

The constituents of the questionnaire were derived from the literature and then piloted for

comprehension, un-ambiguity and completeness. The survey questions were mapped to the

objective of the study. The questionnaire consisted of four main sections including general

information questions, ranking of factors for task allocation, relationship between architecture

and communication/coordination, and task allocation. The survey also consisted of a cover

letter informing the participants about the objective and benefit of the survey and undertaking

to ensure the confidentiality and anonymity of the respondents.

The pilot testing was carried out as a two-stage process. During the first phase, the

questionnaire was sent to research experts in the field. Minor changes were recommended

during this phase. The updated questionnaire was sent to a project manager of a mature

Finnish GSD organization during the second phase of pilot testing. The organization is ISO

9001 certified and specializes in web-based systems for international clients. It has company

offices in Germany, the USA, and Finland and many partners across the globe. Founded in

2000, the organization has 200 + employees. The survey was also tested cognitively by the

same organization to verify the comprehension and correctness of the survey. The probing

method of cognitive testing was used questions (Fabriek et al., 2008), and questions related to

comprehension, retrieval, judgement and response were asked; no major changes were

required after the feedback. The feedback did require us to add detail to some questions for

comprehension. The questionnaire employed the probing method which was used for



checking the effectiveness of the final questionnaire presented in Appendix B. The filled

response of pilot testing is also attached for reference in Appendix B.

3.2.2 Interview Study

The survey was followed by interviews with industry practitioners to obtain in-depth

knowledge of the task allocation process. It used a qualitative mechanism to explore or

acquire detailed knowledge from the interviewee (Easterbrook et al., 2008). The interview

was designed by providing flexibility in structured interviews. The interview protocol is

attached in Appendix C. The questions and follow up questions were formulated but since our

focus was to understand and elicit experience, we listened to the interviewee and asked

additional questions where were not planned (Myers, 1997).

The interviews were designed and executed to answer the following research questions:

RQ 3: What are the trade-offs that are performed during task allocation in GSD?

The interview was conducted as a sequential explanatory strategy (Easterbrook et al., 2008) to

add to the quantitative data acquired through survey. Therefore we have used both

quantitative and qualitative data to explain the phenomenon of task allocation in GSD.

Invitation to participate was sent via email and LinkedIn. The remaining social websites were

not used for interview study keeping in view the small number of responses received during

the survey. The practitioners were selected on voluntary basis. A total of 10 interviews were

conducted, where all of the practitioners had GSD experience of about 10 to 30 years and

belonged to Pakistan, United States, United Kingdom, and Qatar. The interviews were

conducted via face-to-face meetings, phone call and Skype voice calls. The practitioners

belonged to different type and size of GSD organizations ranging from organizations

developing software solutions for business, telecom, finance, health, entertainment,

automation technologies and petroleum industry, etc. All the organizations were mature GSD

organizations which had distributed offices in multiple regions or perform GSD by

outsourcing. The practitioners held different roles in the organization and all of them were not

project managers/ product managers however they were involved in task allocation decision.

All the interviews were recorded and carefully transcribed to avoid loss of information and to

keep the focus on the interview process rather than on writing notes. The transcribed

Interviews are given in Appendix D.

Objective: The objective of the interview study was to understand the dynamics and

process of task allocation decision during GSD.



3.2.3 Online Focus Group

We conducted a focus group session to check the validity and applicability of the framework

in actual GSD task allocation scenario. Focus group is used in social sciences as well as

software engineering to obtain insightful information on the topic under discussion (Kontio et

al., 2004). The rationale of why experiments, case study, ethnographic technique as well as

action research was not chosen to validate the framework are given below (Easterbrook et al.,

2008). Experiment was not an option since we were interested in data collection for the

framework. Later we were unable to check the intervention in a controlled environment since

the TA framework (intervention) is not operationalized. Moreover the task allocation decision

cannot be separated from its context therefore experiments are ruled out as a research method.

Case study could have been performed to check the effectiveness of the proposed TA

framework; however we were unable to acquire consent of a GSD organization. It can also

suffer from researcher bias. Task allocation is usually done by Europe, America and Australia

where Asia is at the receiving end and not involved in task allocation decision. It is difficult

to find a site which is involved in task allocation decision in Pakistan, one of the limitations of

this research. Moreover the framework is not operationalzed in form of a tool or detailed

guideline. Therefore focus group was chosen as an initial empirical method to acquire

practitioner’s feedback on the validity of the proposed framework. We were unable to carry

ethnographic study as well as action research due to limited time and lack of a GSD task

allocating site available in Pakistan.

A protocol of focus group was designed. It consisted of the objective of the focus group,

agenda, participants’ inclusion and exclusion criteria, moderator of the group, and time

required to conduct the session. The protocol is attached in Appendix

F which consists of Introduction Warm Up, Writing, Questions and Answer and Wrap Up

sessions (Bader & Rossi, 1998). The focus group was guided by the moderator where

participants had to respond to questions in a sequence.

An online focus group also known as Computer Mediated Communication (CMC) was

conducted to obtain practitioners feedback while at the same time ensuring discussion among

the participants. Since we required feedback of globally distributed practitioners, a situation

where population is not easily accessible online focus group was a suitable option

Objective: The objective of the focus group was to validate the framework from GSD

Practitioners and also check it applicability in real world task allocation scenarios.



(Turney&Pocknee, 2005). Keeping in view the temporal distances between sites, video/audio

conferencing was also not possible. The CMC focus group also has several advantages over

FTF focus group session (Reid & Reid, 2005). They support generation of new and more

ideas and is preferred due to anonymity (Reid & Reid, 2005).

Therefore an online focus group portal with the name of focusgroupit.com was used to upload

the focus group questions. The volunteers were sent the link to participate in the focus group.

The effectiveness of the focus group session requires careful planning at the start. Members

are not just picked but carefully selected who fulfil specific criteria. The members were from

GSD organizations around the globe with different designations and experience; however the

discussion via portal ensured that no one is intimidated by the other. They did not know each

other, so all of them participated equally without any reservation. The topic of the focus group

was not sensitive to gender, however only one female practitioner participated. All of the

participants were project managers at same level or senior level people who were involved in

task allocation decision. The research methodology is presented in this chapter with the

objective and design of each research method explained in detail. The literature review

provided the basic information related to the criteria used for task allocation in literature,

which was validated from the industry with help of a survey. The interview study

complimented the industrial survey by providing detail. A TA framework was made on the

basis of data obtained from the survey and interview study. The framework is validated with

help of a focus group and also revised based on the feedback obtained from the GSD

practitioners. Chapter 4 presents the execution and results of the survey and interview study.



CHAPTER 4

Results and Analysis



T

4.1 Survey Execution

he survey study was conducted to identify and validate the important

factors necessary for a TA decision in GSD from project managers and

other personnel involved in TA decision making. A total of 110

responses were received, however only 54 were complete and usable. We

excluded incomplete responses along with responses received from

researchers working in academia. The target population of the survey is

project managers/program managers and other decision makers involved in task allocation

activities in GSD. We are only interested in task allocation in a pure GSD context, so only 2

specific cases, that is, off shoring/offshore in-sourcing (different countries/continents, same

organization) and offshore outsourcing (different countries/continents, different

organizations), were considered. The population is split into different continents. The

exponential non discriminative snowball sampling technique was used because we did not

know the worldwide GSD population. The snowball sampling bias is not present in our case

because the population does not have privacy issues. The snowball sampling technique was

initiated by e‐mailing the survey link to contacts in Sweden, the United Arab Emirates,

Luxembourg, Germany, Australia, Pakistan, the United Kingdom, the United States of

America, Finland, Switzerland, Saudi Arabia, India, and Canada. The contacts were asked to

forward the survey to GSD practitioners. The first chosen subject was asked to refer more

practitioners, all of these practitioners were chosen as next subjects. Three further contacts

were requested from each respondent on a voluntary basis, and the number of waves was set

to 5. However due to lack of referral the number of waves conducted was either 1 or 2.

To increase the sample size, the snowball sampling technique was complemented by posting a

survey link on social media. The social media sites chosen were Facebook, LinkedIn, and

Twitter. GSD specific groups were targeted in case of Facebook and LinkedIn, whereas GSD

practitioners were identified on Twitter. The GSD groups correspond to both groups of GSD

experts and groups of specific GSD organizations. We are unable to calculate the response

rate as we are not aware of the sampling frame due to unknown GSD population. This is the

major reason we chose snowball sampling method during survey design. Response rate cannot

be calculated in case of snowball sampling and where the number of people to which survey is

exposed is unknown such as in case of web surveys. The focus of the research is to gain

insight therefore the value of response rate also decreases. A total number of 14 groups on



Facebook and 47 on LinkedIn were joined and their members requested to participate in the

web survey. Tweets were sent on twitter to followers of GSD and Global Software

Engineering Conferences of 2013 and 2014, along with 25 other people having interest in

GSD. A huge number of emails were also sent to people working in GSD identified from web.

A total of 14 groups were identified and joined on Facebook. The survey link along with the

cover letter was also shared on the Timeline. LinkedIn was a major contributor, as the survey

participation request was sent to 47 GSD groups. Some groups did not respond immediately

to the group joining request. In cases where the request to join group was pending for more

than 15 days, a separate message was sent to the group manager. The status of pending

requests was rechecked after 2 months, and with the exception of 2 groups, the request to join

the group was still pending, so the groups were left to create space for joining new groups.

Messages were also sent to the major contributors of the group. The official company

websites were identified from LinkedIn, and e‐mails were sent through them. On Twitter, a

total of 93 results came as a result of second connections and 0 from first connections.

Requests to connect were sent to all 93, out of which 18 responded initially and were

contacted immediately. Later, as more people accepted the invitation, more messages were

sent to second connections, and so on. Tweets were also sent to people following the GSD

conference. E‐mail was also used to further increase the response rate. E‐mails were sent

to project managers and other management roles of GSD organizations such as IBM,

Microsoft, Siemens, and Oracle.

4.2 Survey Results and Analysis

The main focus of the survey study was to identify the factors important for task allocation

decision in a GSD environment along with their importance. We also wanted to identify the

role of product architecture during task allocation decision in GSD and the impact of

Conway’s law on the task allocation decision. Therefore questions related to communication

and coordination requirement and product architecture are also a part of survey questionnaire.

The results of the survey are analysed using MS Excel and SPSS via different analysis

methods explained in this chapter.

The quantitative analysis of the survey response is presented one by one. Initial the ranking of

factors and role of architecture and communication and coordination to TA decision is

highlighted, whereas the results of statistical tests are presented after it. The results of the

interview study are presented later in the chapter.



4.2.1 Ranking of Factors for Task Allocation Decision

The survey respondents were asked to rank the factors with respect to their importance for a

Task Allocation decision as per their experience. The frequency of ranking of factors can be

seen with the help of a stacked bar chart given below in figure 4.1. The legend from very

important to unimportant represented by different colours is given on the bottom of figure. To

increase comprehensibility we have excluded the “Do Not Know” option from the bar chart.

Figure 4.1: Ranking of Task allocation Factors by GSD Practitioners

If we see the frequency chart we see that greater importance is given to expertise, site

characteristics and task site dependency. The importance can be seen by adding the responses

of very important and important, however detailed value scores are assigned based on

weightage and given in table 4.6. Site characteristics encompass (capability of analyst and

programmer etc., the language and tool experience, personnel continuity and customer

proximity) whereas task site dependencies are (experience of platform and type of application

to be developed).

Next to the above mentioned factors labour cost, personnel availability and process ownership

are considered important by the industry. Workload between distributed sites, communication

and coordination overhead and component dependency is ranked little less than the rest

whereas least importance is given to task size, time difference and cultural difference for task

allocation in distributed environment.

The overall results indicate that more importance is given to expertise and experience than

labour cost and the location of site. The architecture of the system as well as communication



and coordination requirement between sites is considered important for a task allocation

decision. This information is very important as we also wanted to identify whether Conway’s

law holds and is used for task allocation decision by the practitioners or not. The next section

presents the detail on what architectural relationships are considered as important for a task

allocation decision

4.2.2 Importance of Architectural Relationships for Task Allocation in GSD

Product architecture in the form of component dependencies is considered for task allocation

by 76% of the practitioners. To determine the exact relationships considered as important

during task allocation decision, the practitioners were asked to select the architectural

relationships they look into before allocating tasks to distributed sites. The architectural

relationships presented were categorized into three main categories of module view type,

component and connector view type and allocation view type (Boucké&Holvoet, 2006). The

pie chart in figure 4.2 highlights the importance of architectural views by GSD practitioners

for task allocation. The module view type is assigned highest percentage highlighting the

significance of static relationships between modules as more important for task allocation.

Figure 4.2: Importance given to Architectural Views for Task Allocation Decision

The detailed view presented in figure 4.3 highlights the architectural relationships and their

importance in the eyes of practitioners for task allocation decisions. The functional

dependency and contained relationship between modules are the most significant relationships



as identified by the practitioners for task allocation decisions. The request response

relationship from the component and connector view types and the deployment relationship

from the allocation view type are also considered important by almost half of the

practitioners.

Figure 4.3: Architectural Relationships Considered for Task Allocation Decisions

The survey response data also show that most of the static structural information is used

during task allocation such as functional dependency between modules and contained

relationship between modules along with deployment relationship between physical entities

and software elements from allocation view type. Dynamic relationships are also seen in case

of request response relationship between client server, read write relationship between filters

or relationship between concurrent units. Dynamic relationships are used to identify the

communication and coordination needs and therefore impact the task allocation decision

(Avritzer et al., 2010).

Moreover 70% of the practitioners claim to use the component dependencies to identify the

communication and coordination needs, and 76% also consider these communication and

coordination needs during task allocation thereby confirming use of Conway’s law during task

allocation.



4.2.3 Ranking of Communication and Coordination Dependency Links

The need for communication and coordination between distributed sites is due to the

dependency between tasks/activities, also known as technical dependency, people, resources

and time (J. Alberto Espinosa1 et al, 2007)(Nguyen-Duc& Cruzes, 2013)(Wiredu, 2006). The

success of GSD depends on the management of these coordination dependencies. We want to

identify the importance of these dependency links from the perspective of task allocation. The

ranking from very important to unimportant given by practitioners is shown in figure 4.4

below.

Figure 4.4: Importance of Communication and Coordination Dependency Links

Practitioners give more value to communication and coordination dependency, which is

present due to the dependency between tasks or activities. The dependency between people

and resources also generate communication and coordination needs and are considered

important in a task allocation scenario. The dependency between people arise when

distributed developers are working on the same code, whereas resource dependency

incorporates the dependency of hardware, human and other resources (Setamanit et al., 2007)

. The time difference between distributed sites can create synchronization problems if not

handled properly, but it is not considered very important by practitioners for task allocation.

Although temporal dependency is necessary to avoid conflicts and consumes a lot of time for

resolution (Nguyen-Duc& Cruzes, 2013).

0

5

10

15

20

25

30

Dep

en

dec

yB

etw

een

Ta

sk

s

Dep

en

den

cy

Betw

een

Peo

ple

Dep

en

den

cy

be

twee

nR

eso

urc

es

Dep

en

den

cy

be

twee

n S

ites

(Te

mp

ora

l)

28

13 14

4

12

23 23

0

4

8 810

1 1 14

0 1 1

21

1 1 14

Very Important

Important

Moderately Important

Of Little Importance

Unimportant

Don't Know



4.2.4 Statistical Analysis

The survey data was exported in Excel File from Lissom Survey Server and later imported

into SPSS (Statistical Package for Social Sciences) for analysis. SPSS is used for statistical

analysis. Man Whitney U test is used to identify significant difference between results and

Spearman Rho test for finding correlations between factors. The details of the tests performed

along with the results are presented in this chapter. Man Whitney U test is used for ordinal

data and in case of data which does not fulfil the normalization assumption.

The different statistical tests options were Linear by linear chi square and Kruskil Walis test.

However the data is ordinal therefore we have cases where more than 20% cells have value

<5. One of the assumptions of chi square is that not more than 20% cells should have a value

of less than 5, therefore chi square is not a suitable option in this case. Kruskil Walis test is

also used for identifying significance between more than 2 categories. It identifies whether

there is a significant difference or not. It does not identify the exact categories in which the

difference exists; hence it is considered inappropriate for this situation. The Mann Whitney U

Test is used for 2 categories of independent variable only. It can be applied by making

combinations of different categories of the independent variable, which is how we have

identified significance among multiple categories. The data was not normal, which was

identified with the help of Kolmogorov Smirnov test and Shapiro Wilk test using SPSS. The

significance values calculated for task allocation factors are below 0.05 showing that the data

is not normally distributed.

The survey responses are saved country wise and also aggregated in respective continents.

This was only done to ensure participation of GSD organizations from around the globe.

However after multiple iterations and efforts we were still not able to obtain any results from

African continent. figure 4.5 presents the responses to the questionnaire categorized continent

wise.



Figure 4.5 : Continents Wise Responses of Industrial Survey

The population of the survey is Project Managers, Product Manager, Architects and other

roles involved in task allocation decision of GSD organizations. More than one role is played

by a single individual in many organizations; moreover a person may have been on different

roles throughout his career. Therefore we are giving value to all software development roles

(who have been involved in task allocation decision) in identification of factors and their

correlations among them. Figure 4.6 presents the statistics with respect to the roles who

responded to the questionnaire.

Figure 4.6: Survey Response Role Wise

4.2.4.1: Difference in Ranking of Factors

To identify whether significant difference exists in the ranking of factors by different

categories of respondents, Mann Whitney U test of independence was conducted. Mann

Whitney U test is used as the dependent variable, is ordinal and independent variable, is of

nominal nature. The dependent variable being the important factors for TA decision, whereas

19

10 10

20

3 4 5 5 74

05

10152025

Pro

ject

Man

age

r/P

rod

…

Arc

hit

ect

Team

Le

ad

De

velo

per

Syst

em A

nal

yst

Bu

sin

ess

An

alys

t

Test

er

Re

qu

ire

men

tEn

gin

eer

Qu

alit

yA

ssu

ran

ce…

Oth

er

Role Wise Response



the independent variable is the organization’s experience, individual’s experience, recentness

of the individual’s GSD experience, level of distribution and type of GSD experience

respectively. The test can identify difference between two categories only, therefore different

combinations of categories were made and the test was applied to all combinations. Mann

Whitney U test was a suitable option since the data was not normally distributed and consisted

of independent observations (“Mann-Whitney U Test using SPSS Statistics, Laerd Statistics,”

n.d.). The value of U for different sample sizes is matched with the table of critical values to

show whether the results are statistically significant or not (“Graham Hole Research Skills

Mann-Whitney test handout version 1.0., 2011,”). Mann Whitney U test has some

assumptions which need to be true before the test can be applied. All of the assumptions given

below hold true, hence Mann Whitney U test was selected for identifying significance

difference between rankings of dependent variable by independent variable categories. The

assumptions are given below, along with how they are ensured.

1. The dependent variable should be measured on ordinal or continuous scale such as (a

Seven-point scale ordered from "strongly agree" to "strongly disagree") etc. We

designed a Likert scale that consisted of six values from very important to unimportant

along with a “Do Not Know” option used to remove noise from data.

2. The independent variable should consist of two categorical, independent groups such

as gender, which has two categories male and female. We applied the test by making

combinations of different categories such that only two categories are compared at a

time.

3. The observations should be independent such that there is no relationship between the

observations in each group or between the groups themselves. The respondents of the

global survey for task allocation are from different GSD organizations without any

overlap.

4. The application of Mann-Whitney U test is based on the assumption that data is not

normally distributed. We checked this assumption with the help of Kolmogorov

Smirnov test and Shapiro Wilk test using SPSS.

4.2.3.1.1 Mann Whitney U Test: Significant Difference in Ranking of Task Allocation Factors

Mann Whitney U Test is applied to determine the significant difference in ranking of task

allocation factors (dependent variable) by different categories of independent variable(“Mann-

Whitney U Test using SPSS Statistics, Laerd Statistics,” n.d.). Significance value or alpha is

taken as <0.05, depicting that there is a 5% chance of no difference between the groups



whereas 95% chance of a significant difference between the groups under analysis. The

results show that no significant difference is identified except in the cases mentioned in this

section. The Exact Significance Value (one tailed) is noted for small sample sizes(“Using

SPSS for Ordinally Scaled Data: Mann-Whitney U, Sign Test, and Wilcoxon Tests, tutorial,”

n.d.). Mann Whitney U test is used to check the difference in ranking of factors between the

categories of independent variables. The categories compared and the significance results are

given below. The dependent variable is measured on ordinal scale i.e. a 5 point Likert scale

from very important to unimportant. All of the independent variables are measured on

nominal scale i.e. one which has different categorical values without any order. The

independent variables are organization’s experience, individual’s experience, recentness of the

individual’s GSD experience, level of distribution and type of GSD experience.

The independent variables and their categorization are given in detail below:

1. Level of Distribution (Number of sites the tasks are distributed to): Measured via 4 levels

that are 2-3 sites, 4-6 sites, 7-9 sites, 9+ sites

2. Organization’s Experience: Measured via 4 levels that are <3 years, 3-5 years, 6-8 years

and 8+ years.

3. Individual’s Experience: Measured via 5 level that are <=1 year, 2-3 Years, 4-5 Years, 6-7

Years and 7+ Years.

4. Recentness of GSD experience: Measured via 5 levels that are currently working on one, 1-

2 years ago, 3-4 years ago, 4-5 years ago and more than 6 years ago.

5. Type of GSD: Measured via 3 categories namely off shoring, offshore outsourcing and

both.

The categories are compared in a manner as explained e.g. the organizational experience has 4

values <3 years, 3-5 years, 6-8 years and 8+ years. Therefore the total combinations checked

are 6 which are given below.

1. <3 years with 3-5 years

2. <3 years with 6-8 years

3. <3 years with 8+ years

4. 3-5 years with 6-8 years



5. 3-5 years with 8+ years

6. 6-8 years with 8+ years

Similar combinations were made and checked for significant difference in ranking of factors

for rest of the independent variables (individual experience, recentness of GSD experience,

type of GSD and level of distribution). The Exact Significance Value is seen as the sample

size of the groups is small. The value of U is compared with critical value of U to determine if

the results are statistically significant or not. We have not evaluated situations where the

difference between N value of two categories was large e.g. 33 and 7 or 33 and 2. In case of

huge difference between N values of two categories, the statistical power is said to decrease

and nothing can be concluded (“Mann-Whitney U test with unequal sample sizes - Cross

Validated,” 2012)(“How should one interpret the comparison of means from different sample

sizes? - Cross Validated,” 2012).

Level of Distribution:

The survey data is categorized in table 4.1 on the basis of number of sites to which the

software development work is distributed.

Table 4.1:Level of Distribution

Level of distribution

Number of Sites 9+ 7-9 4-6 2-3

Responses 6 2 7 33

Case 1: Difference in Ranking of Temporal Difference by (Group 1 = 4-6 sites and Group 2 =

9+ Sites)

Time difference is ranked differently by both groups. The significance value is p = 0.022

and the value of U = 5. The critical value of U the specified sample N1 = 7 and N2 = 6 is 6,

since the value of obtained U is less than the critical U the results are identified as statistically

significant.

Experience of Individual

The experience of individual working in GSD is categorized as given in table 4.2.

Table 4.2: Categories of Experience of Individual working in GSD

Experience of Individual

GSD Years 7+ 6-7 4-5 2-3 <1

Responses 20 3 8 11 9



Case 1: Difference in Ranking of Process Ownership and communication and Coordination

Overhead (Group 1 = <1 Year Experience and Group 2 =2-3 Year Experience)

Process ownership is ranked differently where N1 is 9 and N2 is 9 the critical value of U is

17. Since the obtained U is 15, the results are statistically significant and have not occurred by

chance. Process Ownership (U = 15, p = .024)

Recentness of GSD Experience:

The recentness of GSD experience was also taken as independent variable and its effect was

seen on factors for task allocation. The categories are given in table 4.3.

Table 4.3: Recentness of GSD Experience

Recentness of GSD Experience

Years Currently Working 1-2 years ago 3-4 years 4-5 Years 6+ Years

Responses 39 5 4 1 3

However no significant difference was found in ranking of factors by the categories of

recentness of GSD experience.

Type of GSD.

The type of global software development is categorized as

1. Off shoring (same company but offices in different countries/continents)

2. Offshore outsourcing (different companies as well as different

countries/continents)

3. Organizations that perform both (Off shoring and Off shore outsourcing)

Therefore the ranking of factors is analysed by total 3 categories; off shoring companies,

offshore outsourcing companies and companies that do both off shoring as well as offshore

outsourcing.

Case 1: Difference in Ranking of Communication and Coordination Overhead (Group 1 = Off

shoring organizations and Group 2 = Organizations that do both off shoring /offshore

outsourcing).

The values of p and U for communication and coordination overhead after applying Mann

Whitney U test are (U = 79, p = 0.014). Value for N1 = 18 and N2 = 17. The critical U value

is 93, since the obtained U is 79 which is less than 93 the result is statistically significant.



Two cases where the difference between N was large were not considered since in case of

large delta the statistical power diminishes.

4.2.4.2 Other Significant Difference Test

Mann Whitney U test was also applied to the ranking of communication and coordination

dependency links to identify any significant difference in their ranking by the same group

mentioned in section 4.3.1.1. The purpose was to identify if there is difference in the

importance assigned to these communication and coordination dependency links by different

groups. However no significant difference was found in ranking of the communication and

coordination dependency links.

4.2.4.3 Correlations

Spearman Rho test is used to identify the correlation between the factors. Spearman’s Rho test

is chosen since the data is ordinal and does not fulfil the normality and linearity criteria (Weir,

2015).We studied in detail different statistical tests to find the correlation between Task

Allocation factors. The Correlation coefficient test is used for interval data, Pearson

correlation coefficient is used for normal and linear data and for more than 100 observations,

and Gamma test is suitable for tied observations whereas we have unique ranks. Spearman

Rho and Kendal Tau test can both be applied to ordinal data but their method of finding

correlation is different. We have chosen the Spearman Rho test to find out the correlation

between task allocation factors. Spearman Rho is used to identify correlation between factors

on ordinal scale. Correlation is used to determine the degree of association between factors.

The Significance Level or Alpha/ Probability value is taken as <0.05 which is the commonly

used p value. It means that there is a 5% chance that there is no association, whereas 95%

confidence on a relationship between the two analysed variables. We have also used SPSS to

determine the frequencies of agreement and disagreement for all factors. To run a Spearman

Rho test the following assumptions must hold.

1. The two variables should be measured on an ordinal, interval or ratio scale and

should be ranked. We have ordinal data with ranks from 1-5 from very important to

unimportant. The “Do Not Know” option is removed, Pair wise deletion is the default

option in SPSS for corrections where the respective cells which have no value are

eliminated from analysis.



2. The two variables should have a monotonic relationship. A monotonic relationship

exists when either the variables increase in value together, or as one variable’s value

increases, the other variable’s value decreases. The monotonicity of the variables was

checked with help of SPSS.

The results of the Spearman Rho test are given in table 4.4 below. We have only presented the

significant values for comprehension; the full table is present in Appendix E.

As we are considering ranked data so we are removing the option number 6 which is the “Do

Not Know” Option. We used pair wise exclusion to exclude the missing values from analysis.

If we just draw a table of associations then we would get the following factors as being

associated with each other along with the p value. The value of spearman correlation

coefficient known as (ρ) or rs. The strength of the correlation is interpreted on the ranges

given below, with the value of rs closer to +- 1 indicates very strong correlation(Weir, 2015) :

1. 0.000-0.19 (Very Weak Correlation)

2. 0.20-0.39 (Weak Correlation)

3. 0.40-0.59 (Moderate Correlation)

4. 0.60-0.79 (Strong Correlation)

5. 0.80-1.0 (Very Strong Correlation)

The value of P or significance value is taken as <0.05, which indicates that there is a 5%

chance the value has occurred by change and 95% chance they are actually correlated.

Table 4.4: Significant Correlations between Task Allocation Factors

Labor Cost Correlation

Coefficient

1 .468** .292* 0.244 -0.043 0.167 0.132 .286* 0.231 0.198 0.032 0.094

Sig. (2-tailed) . 0 0.036 0.081 0.765 0.237 0.362 0.042 0.1 0.159 0.822 0.51

N 52 52 52 52 52 52 50 51 52 52 52 51

La

bo

r C

ost

Wo

rk

loa

d D

istr

ibu

ted

Sit

es

Sit

e C

haracte

rist

ics

Ta

sk_

Sit

e D

ep

en

den

cy

Ta

sk S

ize

Perso

nn

el A

vail

ab

ilit

y

Process

Ow

nersh

ip

Co

mm

un

ica

tio

n/C

oord

ina

tio

n

Ov

erh

ead

Ex

perti

se

Co

mp

on

en

t D

ep

en

den

cies

Tim

e D

iffe

ren

ce

Cu

ltu

ral

Dif

feren

ce



Workload between

Distributed

Sites

Correlation

Coefficient

.468** 1 .356** 0.255 0.008 0.179 0.234 0.171 0.253 0.167 0.177 -0.01

Sig. (2-tailed) 0 . 0.01 0.068 0.958 0.204 0.102 0.231 0.07 0.238 0.21 0.946

N 52 52 52 52 52 52 50 51 52 52 52 51

Site Characteristics Correlation

Coefficient

.292* .356** 1 .452** 0.119 0.169 0.249 0.231 .384** -0.016 0.028 -0.035

Sig. (2-tailed) 0.036 0.01 . 0.001 0.397 0.227 0.078 0.103 0.005 0.912 0.844 0.806

N 52 52 53 53 53 53 51 51 53 52 52 51

Task Site

Dependency

Correlation

Coefficient

0.244 0.255 .452** 1 0.015 -0.086 0.112 0.269 .333* -0.005 -0.042 -0.032

Sig. (2-tailed) 0.081 0.068 0.001 . 0.914 0.539 0.433 0.056 0.015 0.97 0.768 0.824

N 52 52 53 53 53 53 51 51 53 52 52 51

Task Size Correlation

Coefficient

-0.043 0.008 0.119 0.015 1 .433** .453** 0.144 0.172 .337* 0.272 0.252

Sig. (2-tailed) 0.765 0.958 0.397 0.914 . 0.001 0.001 0.315 0.219 0.014 0.051 0.074

N 52 52 53 53 53 53 51 51 53 52 52 51

Personnel

Availability

Correlation

Coefficient

0.167 0.179 0.169 -0.086 .433** 1 .380** 0.07 0.256 .318* -0.095 -0.234

Sig. (2-tailed) 0.237 0.204 0.227 0.539 0.001 . 0.005 0.623 0.062 0.02 0.497 0.094

N 52 52 53 53 53 54 52 52 54 53 53 52

Process Ownership Correlation

Coefficient

0.132 0.234 0.249 0.112 .453** .380** 1 .518** .307* .444** 0.246 0.147

Sig. (2-tailed) 0.362 0.102 0.078 0.433 0.001 0.005 . 0 0.027 0.001 0.082 0.302

N 50 50 51 51 51 52 52 50 52 51 51 51

La

bo

r C

ost

Wo

rk

loa

d D

istr

ibu

ted

Sit

es

Sit

e C

haracte

rist

ics

Ta

sk_

Sit

e D

ep

en

den

cy

Ta

sk S

ize

Perso

nn

el A

vail

ab

ilit

y

Process

Ow

nersh

ip

Co

mm

un

ica

tio

n/C

oord

ina

tio

n

Ov

erh

ead

Ex

perti

se

Co

mp

on

en

t D

ep

en

den

cies

Tim

e D

iffe

ren

ce

Cu

ltu

ral

Dif

feren

ce



Communication

Coordination

Overhead

Correlation

Coefficient

.286* 0.171 0.231 0.269 0.144 0.07 .518** 1 .480** .521**

z

.410** .448**

Sig. (2-tailed) 0.042 0.231 0.103 0.056 0.315 0.623 0 . 0 0 0.003 0.001

N 51 51 51 51 51 52 50 52 52 52 52 51

Expertise Correlation

Coefficient

0.231 0.253 .384** .333* 0.172 0.256 .307* .480** 1 .330* 0.059 0.11

Sig. (2-tailed) 0.1 0.07 0.005 0.015 0.219 0.062 0.027 0 . 0.016 0.676 0.439

N 52 52 53 53 53 54 52 52 54 53 53 52

Component_Depen

dencies

Correlation

Coefficient

0.198 0.167 -0.016 -0.005 .337* .318* .444** .521** .330* 1 .468** .361**

Sig. (2-tailed) 0.159 0.238 0.912 0.97 0.014 0.02 0.001 0 0.016 . 0 0.009

N 52 52 52 52 52 53 51 52 53 53 53 52

Time_Difference Correlation

Coefficient

0.032 0.177 0.028 -0.042 0.272 -0.095 0.246 .410** 0.059 .468** 1 .590**

Sig. (2-tailed) 0.822 0.21 0.844 0.768 0.051 0.497 0.082 0.003 0.676 0 . 0

N 52 52 52 52 52 53 51 52 53 53 53 52

Cultural_Difference Correlation

Coefficient

0.094 -0.01 -0.035 -0.032 0.252 -0.234 0.147 .448** 0.11 .361** .590** 1

Sig. (2-tailed) 0.51 0.946 0.806 0.824 0.074 0.094 0.302 0.001 0.439 0.009 0 .

N 51 51 51 51 51 52 51 51 52 52 52 52

We do not have very strong and strong correlations among factors but some of the factors

have moderate correlations which can be seen with the help of values on the edges (explained

La

bo

r C

ost

Wo

rk

loa

d D

istr

ibu

ted

Sit

es

Sit

e C

haracte

rist

ics

Ta

sk_

Sit

e D

ep

en

den

cy

Ta

sk S

ize

Perso

nn

el A

vail

ab

ilit

y

Process

Ow

nersh

ip

Co

mm

un

ica

tio

n/C

oord

ina

tio

n

Ov

erh

ead

Ex

perti

se

Co

mp

on

en

t D

ep

en

den

cies

Tim

e D

iffe

ren

ce

Cu

ltu

ral

Dif

feren

ce



before the table). The significance value highlights the confidence with which these results

can be accepted i.e. for a significance value of 0.00 there is 0% chance that the results have

occurred by chance. The significance value for all moderate correlations is 0.00, 0.001 or

0.003 showing high confidence with which results can be accepted explained before the table.

The visual representation of the correlations is shown in figure 4.7 with cluster of relationship

encased in dotted box.

To determine the relative value of each factor ranked by the participants, we have assigned

different weights, i.e., 4 to a very important factor, 3 to an important factor, 2 to a moderately

important factor, 1 to of little importance, and 0 to an unimportant factor given in table 4.5

below.

Table 4.5: Number of Responses in each Likert Scale Option

Factors/

Ranking options

Very I

mp

orta

nt

Imp

orta

nt

Mo

dera

tely

Im

po

rta

nt

Of

Lit

tle I

mp

orta

nce

Un

imp

orta

nt

1. Expertise 29 18 6 1 0

2. Site Characteristics 28 19 5 1 1

3. Task Site Dependency 19 27 6 1 1

4. Labour Cost 24 19 5 4 0

5. Personnel Availability 19 22 9 4 0

6. Communication/ Coordination Overhead 25 14 10 1 2

7. Process Ownership 16 24 9 2 1

8. Component Dependency 15 24 9 5 0

9. Work Load at Distributed Sites 11 26 12 4 0

10. Task Size 8 21 16 5 4

11. Time Difference 8 15 15 11 4

12. Cultural Difference 8 14 12 13 5

The final value given by the GSD practitioners to all the factors is given in Table 4.6 in

descending order. Each value of likert scale options (i.e. very important to unimportant) which

is the frequency of response in table 4.5 is multiplied with the respective weightage to identify



the final value given in table 4.6. The number of correlations of each factor with the others is

also listed under the "links" heading to highlight the importance of the factors.

Table 4.6: Task Allocation Factors in Descending Order

Factor

Value

Score

No. of

Correlations

1. Expertise 183 5

2. Site Characteristics 180 5

3. Task Site Dependency 170 2

4. Labour Cost 167 4

5. Personnel Availability 164 2

6. Communication and

Coordination Overhead

163 6

7. Process Ownership 156 6

8. Component Dependency 155 7

9. Workload at Distributed Sites 150 2

10. Task Size 132 3

11. Time Difference 118 3

12. Cultural Difference 111 3

The significant relationships are shown with the help of bubble chart in figure 4.7 with

nodes representing the factors and edges representing the correlations. The significant value is

given on edges. The values on edges are the spearman rho values given in table 4.4, whereas

the value of the node is the final value score given in table 4.6 with the number of links

mentioned in brackets also taken from table 4.6. The size of the bubble varies with the value,

where large sized bubbles represent more value. The nodes are aligned so that the importance

of factors decreases from left to right. The importance value is given inside the node, whereas

the value in the brackets inside the node represents the number of correlations of a factor.

Correlation only shows that a relationship exists between the two factors, it does not highlight

causal relationship, i.e. the direction of the relationship is not known. The lines connecting the

nodes are bi-directional, since the same significance value is calculated from both sides.



Expertise

183 (5)

Site

Characteristics 180

(5)

Task Site

Dependency 170

(2)

Labour Cost

167 (4)

Communication

/Coordination

Overhead 163

(6)

Personal

Availability

164(2)

Work Load

b/w remote

sites150 (2)

Component

Dependency

155(7)

Process

Ownership

156 (6)

Time

Diff.

118 (3)

Cultural

Diff. 111

(3)

Task Size

132 (3)

0.333

0.452

0.384

0.356

0.292 0.468

0.468

0.590

0.286

0.448

0.337

0.444

.410

0.521

0.453

0.433

0.380

0.307

0.480

0.330

0.518

0.318

0.361

Figure 4.7: Bubble chart depicting Correlation of Factors identified via Spearman Rho Test

The majority of the correlations are present on the right side in figure 4.7 focused with the

help of dotted lines around them. The factors inside this box are highly correlated to each

other. Most of the moderate level correlations are also present inside this dotted box.

4.3 Result and Analysis of Interview Study

The interview has given us detailed insight into the factors that the organizations consider the

task allocation process and roles involved in the allocation decision. It has also highlighted the

situation specific characteristics that impact the allocation decision in GSD. The interview

data is analysed using thematic analysis (Lichtman, 2012). General themes are identified from

interview transcripts (written in textual format after listening to recordings of the interview).

The data is categorized and organized into basic themes and then to bigger themes. The

following themes are identified after interview analysis Factors, Process of Task Allocation,

Trade-off and Variations to GSD. The themes are detailed below.

1. Nature of work which corresponds to, urgency of task at hand or how early we need to

market the product is a new factor identified during interview. It is a task characteristic, and

according to the interviewed practitioners, it holds critical so much so that the decision to

outsource depends on it. Some of the practitioners have shared their experience of choosing in



house development due to the urgent nature of the task at hand. Therefore an important

dimension to task allocation decision is to consider the nature of the task i.e. timeline and

criticality.

2. Trust or credibility of the distributed site to deliver quality work on time is another

important factor identified during interview. It was also identified as an important factor in the

open-ended question of survey questionnaire. Trust or credibility is gained by prior

experience of working with the distributed site. This factor may not be present in case of no

experience. It is also highlighted as an important factor in a survey conducted from industry

experts (Mahmood et al., 2017). The factor is critical in case of outsourcing as well as in

sourcing, since the work will be done by a third party. If the task is allocated to a regional

office of the same organization the importance of trust and credibility is minimized.

Political reasons or management recommendation is also highlighted as a reason to select a

site for a task as a result of interview response. It is more of a preference as highlighted by the

respondent therefore it would not be included in the list of factors to be considered for task

allocation. Scope of work is equivalent to task size factor which was initially identified from

literature. Many of the interview respondents highlighted scope as important for task

allocation decision which is again a task characteristic.

Experience of developing a particular kind of project or application comes in task site

dependency, a factor identified from literature and present in the initial list of factors in

survey. Organizational culture has been separately discussed in case of outsourcing

organizations whereas in survey we only listed culture as an important factor which

incorporated both the national and organizational culture. Staff turnover is also highlighted as

an impacting factor to task allocation decision; it was included in the initial list identified

from literature under the site characteristic factor.

Cost is one factor which incorporates labour cost, the cost of communication and coordination

across sites and taxes as well; where taxes for software development in some countries are

higher therefore usually software is also off shored to developing countries because of low

taxes. We only found labour cost as an influential factor during task allocation decision from

literature but after interview response, it is renamed as development cost which incorporates

the labour cost, cost of communication and coordination and taxes of developing software at

that specific distributed site.



The detailed analysis of the interview data has also emphasized the variance in situation and

its impact on the task allocation decision. Although the factors are almost the same across the

10 interviews which we will consider as separate cases, but the importance of factors varies

from situation to situation. This means that a factor of critical importance in one scenario may

be of minor significance in another. Some of the variation points as identified for the analysis

of the interview data are

1. Type of GSD i.e. off shoring or off shore outsourcing

2. Nature of project or task (Criticality and timeline of a project)

3. GSD involving multiple vendors

4. Number of distributed sites

5. Objective of carrying out GSD

6. GSD involving large and small company(s)

While they maybe some of the many variation points that may change the situation for a task

allocation decision, the supporting text from interview is given to emphasize the variance.

4.3.1 Situation 1: Type of GSD (Off-shoring Versus Off-shore outsourcing)

Organizational Culture is an important attribute, which is present only in case of off shoring to

a different organization. In case of distributed office of the same organization, organizational

culture is not at all at play. One organization has the same work policies, processes, norms

and values across distributed site offices. The organizational culture factor incorporates

methodology used, security and other policies, processes, framework, principles,

infrastructure, applications, systems, and organizational structure as mentioned in interview.

The importance of organizational culture in case of outsourcing organization can be seen from

the following excerpt from one of the interview.

“You want to work with companies where the delta is minimized. The way that you do things

the way that they do things, you want minimal differences”.

Another important factor which is affected by the type of GSD is Cost as it varies in case of

an organization with multiple regional offices or when outsourcing work.



“We do within reason as it may seem good to outsource but when we send a project offshore

we may be spending more money for quality and logistics then if developed locally”

“We look at cost, but that is only a factor when you have resources available in all regions

which may not always be the case.”

4.3.2 Situation 2: Nature of the Project/Task

It has been highlighted from interviews with 10 project managers that nature of project or task

greatly impacts the task allocation decision. The significance of factors such as Expertise

changes in case of a task with strict time line. It is also seen that in case of urgent task in

house development is preferred to avoid bigger risk of delaying the project. To avoid errors

and rework, expert site is given high priority in case of a critical task as one of the interviewee

states.

“Where time line is strict we choose a site which is expert and chances of errors are less”.

The volatile nature of the project also impacts the decision of whether to distribute it or keep

it in-house as mentioned.

“In case of changes, if high volatile project we keep it in house”

It is also seen that the domain of expertise is considered in case if the task is particular to a

domain e.g. as mentioned by an interviewee all finance related work comes to them as they

are a specialized team of financials. This is in case of a regional office that specializes in one

area whereas in case of outsourcing this factor also plays its part as an interviewee states.

“If we are looking at a specific team of people to work on a portal interfaces we may look for

experts, Indian teams have a skill set of designing portal interfaces so we give it to them”

Similarly

“Now we are making iPad of fountain drinks, like you can customize your drink, all

development work is done in India in tech Mahindra, why because India is doing a lot of work

in gadgets”

Where expertise of a particular domain or requirement of a skill set is aligned with the nature

of the task at hand, Culture and Time zone Distance is not considered important in case of

critical task.



“If it is a critical work then you have to allocate it to a location no matter what cultural

location or time zone it is in”

On the other hand Culture and Time zone does become a problem when the nature of task

requires communication and coordination as evident form the extract of interview transcripts.

“Time zone is a major factor, as it is very difficult to manage multiple time zones,

communication and coordination is a major issue. Multiple cultures, different work habits,

are very difficult to manage, Indians come after 11.30 they have tea, fun and a lot of stuff and

vanish at 5 or 6. Don’t prefer to work with them”.

Language issues have specifically been highlighted in case of outsourcing to China.

“Depends on work, if it is only transactional work it is ok, Chinese problem of English

language makes it very difficult to get work from them”.

‘Once for a project in China I talked for two hours and after two hours nobody had a clue

what I talked about”

Similarly the nature of task as well as the type of GSD affects the value given to Cost and

Prior Experience as evident.

“Usually cost remains the same for off shoring. Small differences don’t matter because

people bargain and set rates. If the project is very critical I would make sure that the project

doesn’t fail. Credibility matters a lot, whether you can deliver a project. If prior experience is

very good then project is given without much thought to cost.”

4.3.3 Situation 3: GSD Involving Multiple Vendors

An interesting insight in-to the dynamics of task allocation is with reference to getting work

done from more than one vendor. The internal politics makes things difficult especially with

respect to communication and coordination and knowledge sharing. The problems escalate

and result in overall project delay. It is therefore preferred to have one vendor. The experience

of a project manager is given below.

“We once had competitive vendor in China and India, the Indian folks were not sharing

information with China because they wanted to keep information with them, for me to give

information from India to China was very difficult. Chinese, they record information and

listen to it again and again, so time got wasted so much. Internal politics between two vendors



become very difficult. Problem of one module affecting the other module, and then no one

owns it”.

4.3.4 Situation 4: Number of Sites

The number of distributed sites impacts the value assigned to Time Difference. Different

working hours impact communication and coordination in many ways. One problem is the

difficulty to communicate due to different working hours and another being the increase in

communication and coordination and therefore the cost to solve a small issue. The impact is

so much so that it is preferred to keep the number of sites to two. The communication and

coordination overhead is the most affected factor in case of change of time difference. Most of

the practitioners have highlighted the issue; the experience of one such interviewee is shared

here.

“Never wish to work again with two regions with different time zones as it is very difficult”

4.3.5 Situation 5: Objective to carry GSD

The objective of carrying out GSD affects the task allocation factors. The most common

objective identified from interview data was to reduce development time by taking advantage

from 24/7 development cycle. It is seen that Temporal difference becomes important in case

of 24/7 development because you want to assign to temporally distant sites to achieve around

the clock development.

“Work assigned in such a way that one site delivers work to the next site for 24/7

development”

4.3.6 Situation 6: GSD involving large and small company(s)

The GSD scenario where more than one company of variant size is carrying out development,

it is seen that the Organizational Culture and working hours of the bigger company are set as

standard. Thus organizational culture is very important in case of outsourcing work as

discussed earlier, but it is adapted in case of one large company and small company(s). The

extract from one of the interview is given below.

“Big companies have made their standard so we have to adapt. Small companies adapt to

time and culture of IBM or Microsoft etc. you have to follow their working hours”



It is evident from the analysis of interview data that the factors across these interviews are

almost the same but their importance varies from situation to situation. It is also apparent that

the characteristics of the GSD such as type of GSD or the organization such as its size affects

the importance assigned to the factors. A factor considered momentous in one situation may

not be of significance in another. These observations have emphasized the need for a well

thought task allocation process where the situation needs to be analysed before the factors are

evaluated.

While these may be some of the variations, they have highlighted the need of a meticulous

process for task allocation. The data from the interviews have shown a lack of any defined

task allocation guidelines or process. Task allocation is usually performed in an ad hoc

manner. The problems with task allocation have also been reported where in some cases tasks

are also re-allocated later on resulting in delay and cost overrun. The difference in task

allocation of traditional and agile methodologies is another area that can be further explored.

The steps of task allocation may not be definable but the various dimensions that need to be

considered and the factors whose evaluation is mandatory for an effective task allocation

process needs to be laid out.

One more important aspect to the task allocation activity is the trade-off between factors since

they are related to one another and cannot be considered in isolation. One of the main

motivations to conduct interviews was to identify the tacit knowledge that goes into making

the task allocation decision which also includes trade-offs between factors. We have presented

the trade-offs as reported by the practitioners, which stress the intricacy of the task allocation

process.

Labour cost is the main reason organizations decide to go global as reported in literature, but

many other factors are given priority over it in case of task allocation. One such factor is

availability of resources since GSD can only be achieved if the required skill set is available.

Therefore we are interested in availability and that too of required skills since GSD is carried

by variant type of organizations. Some big organizations have regional offices in almost all

regions, whereas other may look for outsourcing it to other organizations similarly some may

even allocate to the available regional offices etc. Therefore the availability of resources

becomes a significant deciding factor while allocating task as stated below by one of the

interviewee.



“Global Market today is about where you have resources available. You would look for

availability. We look at cost but that is only a factor when you have resources available in all

regions which may not be the case”.

Similarly in situations where timely delivery is important, especially in case of publically held

organizations labour cost is kept in the background as quoted.

“Labour cost is why we offshore or outsource, it is the driving point but labour cost is

something which can be a trade-off, as if you have a project that you plan to release by a

certain date and if it is not released then you generate no revenue, so it gives a negative

image to your company. If you are a publically held company it would give a negative

recommendation to Wall Street since you did not meet your revenue projections”.

Prior relationship is also given priority over cost to mitigate project risk.

“Prior relationship site wins over labour cost as the grass is not always greener on the other

side.”

“If the project is very critical I would make sure project doesn’t fail. Credibility matters a lot

whether you can deliver a project. If you have prior experience then a good project is given

without much thought to cost”

Expertise is a major deciding factor as highlighted in interviews. It is also given priority over

cost as the main focus is on the required skill set and delivery.

“I am responsible for delivery; I will focus on capability, i.e the one who knows technology”

But in some situations a recommendation of a trust worthy resource is given more priority

over expertise as highlighted.

“I may choose a low calibre person if he is coming from a trust worthy reference”.

While these may be some of the trade-offs that came up as answers to direct trade off

questions or implicitly as part of follow up questions and discussion. The tradeoffs also

highlight the need of a well thought and planned task allocation activity. In practice only 2-3

hours a day is given to it, which may be due to the ad-hoc nature of the activity. The detailed

study of the task allocation factors and process have highlighted the fact that this ad hoc

nature does not suffice in many situations and experiences are reported by practitioners where

they had problems and in some cases they had to reallocate as one interviewee shared.



“Once working with Indian developers was not good, it was not easy to reallocate project but

we escalated to my manager and then we shifted to China, It took us three months after alot of

escalations”.

Therefore the overall project duration can suffer due to reallocation. We want to allocate in a

planned and well thought manner minimizing the need to reallocate.

The detailed analysis of interview data has also highlighted the problems of communication

and coordination across distributed sites. Bad experiences of allocating different

interdependent modules to different sites have been reported and practitioners have responded

by keeping all projects within 2-3 sites. The most common way of allocation is phase based or

functional area of expertise based allocation where different phases of software development

are distributed or required skill set is matched with expertise of the site. These configurations

although do require architecture of the system for allocation but do not need the detailed

module dependencies. Therefore an abstract architecture defining the layers of the system can

suffice for task allocation and the dependencies such as workflow dependencies are enough

for allocating tasks to distributed sites. Thus the in depth interviews into the task allocation

process has also revealed the fact that architecture of the system or detailed design is not

required before task allocation since modules are not allocated to separate sites. The main

reason reported for this is the communication and coordination requirements between sites

which are not manageable.

The chapter presents the results and analysis of data obtained from both survey and interview

study. The chapter details the statistical tests applied and results achieved. The choice of

statistical test is also justified. Chapter 5 discusses in detail the findings of both these studies

and presents threats to validity for both survey and interview study.



CHAPTER 5

Findings and Discussion



5.1 Findings and Discussion

he findings from both the survey and the interview study are presented along with

the discussion. The results are compared with the reported results of task allocation

studies covered in literature and similarities and differences are highlighted.

5.1.1 Factors

The findings with respect to the factors are given below whereas those with respect to

correlations are given in section 5.1.2.

5.1.1.1 Labour Cost

1. Labour cost is assigned a lesser value than expertise by GSD practitioners. The results

highlight that more importance is given to expertise, site characteristics (analyst capability,

programmer capability, language and tool experience, personnel Continuity and customer

proximity) and task site dependency (experience of plate form and application) than labour

cost during task allocation. Whereas labour cost is reported as the chief motivation of

offshoring (Olsson, Conchúir, Ågerfalk, & Fitzgerald, 2008)(Carmel & Agarwal,

2006)(Carmel, 1999), 70% of firms outsource only to save money (Carmel & Agarwal, 2006).

Surveys conducted in 2004, 2005 and 2006 report 72%, 78% and 91% agreement that labour

cost is an important factor for offshoring, whereas access to qualified personnel was reported

by 42%, 54% and 68%, respectively (Stephan & Silvia, 2008). While labour cost may be the

chief motivator when deciding to offshore or outsource, it is not given priority over expertise

when allocating tasks. The results of the interview study also support these findings that the

task allocation is more concerned with getting the work done via allocation to experienced

expertise. Task allocation is done by project managers who are accountable in the case of

success or failure, therefore, the focus is on allocating to expertise who can deliver quality

work within the specified time and budget. Literature also identifies that the GSD trend is

moving towards 24-hour development, focusing on finding the required expertise rather than

labour costs (Gupta, Seshasai, Mukherji, &Ganguly, 2007). GSD is more of a strategic

decision than economic, so organizations interested in strategic partnerships value other

factors such as skill set and experience more than labour costs. A detailed study (Aspray,

Mayadas, &Vardi, 2006) shows that different types of organizations give different importance

T



to labour costs. Therefore the nature of the organization also determines the importance given

to it, for example labour cost is highlighted as an important factor by companies that offshore

on an experimental basis or those that offshore low value-added work only (Carmel &

Agarwal, 2006). Moreover outsourcing work specifically to shorten the development cycle

may give more significance to expert and experienced site than labour cost. Therefore, the

reason why tasks are offshored or outsourced impacts the value given to labour costs and

expertise during task allocation.

5.1.1.2 Communication and Coordination needs

1. The survey results support Conway’s law, as evident from the correlation that associates

product architecture with the communication and coordination needs. The strength of the

correlation is 0.521, which is a moderate relationship. The practitioners’ response also

identifies the association, as 70% of them use product architecture to derive communication

and coordination needs. 76% of them also use these communication and coordination needs to

derive task allocation. Therefore, the relationship between the organizational structure and

product architecture is validated. The details on the type of architectural relationships

considered for task allocation highlight that static relationships are given more importance

than dynamic ones for task allocation. The topmost relationships that are considered during

task allocation are the functional dependency between modules (59%) and the contained

relationship between modules (43%). The request response relationship with a client server,

which is a dynamic relationship, is also considered by 35% of the practitioners. The

deployment relationship between the software element and physical entity from the allocation

view type is considered as important by 30% of the practitioners for task allocation. This may

be because task allocation is performed early, where only initial architectural design is

available. The insight gained via interview study has also highlighted that only initial level

architecture is required during task allocation. However the detailed interview with the

industry practitioners have highlighted that communication and coordination problems occur

in module wise distribution of tasks to remote sites. Therefore phase wise or functional area of

expertise allocation is preferred over module based allocation. Allocating different

components to globally distributed sites is not preferred, thus the need for architecture

diminishes in such case.

2. There are two types of GSD, one where tasks are off shored to company offices located at

distributed sites, also known as offshore in-sourcing, and another where work is outsourced



(different companies) to distributed locations. The type of GSD also affects the importance

assigned to the communication and coordination overhead for task allocation, as identified by

the statistical tests. One plausible explanation is the difference in organizational culture in

case of offshore outsourcing organizations. This difference adds to the communication and

coordination overhead (Gopal, Espinosa, Gosain, & Darcy, 2011). Therefore, distributed

development, where distributed offices of the same organization follow the same

communication protocol and have some prior working relationship, differs in their

communication and coordination overhead as compared to allocation between different

organizations. This observation is also supported by the correlations identified between the

factors via the Spearman Rho test. The results correlate temporal and cultural distance with

the communication and coordination overhead. The national culture and temporal distances

may also exist in case of offshore in-sourcing organizations, but organizational culture varies

in offshore outsourcing organizations only, leading to communication and coordination

difficulties. These results are supported by the interviewed practitioners where the

significance of organizational culture increases in case of outsourcing work. An interesting

observation evident from interview data is the association of communication and coordination

problems with the number of vendors in a GSD configuration, where the problems may arise

in case of competing vendors. Therefore the level of significance assigned to communication

and coordination overhead as a task allocation factor increases when work is distributed

among multiple competing vendors.

3. Communication and coordination needs also change with the software development stages.

For example, the integration phase requires high level of communication and coordination

(Nicholson & Sahay, 2001). Similarly, less communication and coordination during the

requirement engineering phase may result in incomplete and incorrect requirements (Carmel

& Agarwal, 2006). Our survey results support this observation, as 66% of practitioners agree

that communication and coordination needs change with the software development stages.

5.1.1.3 Culture and Time Difference

1. GSD practitioners have assigned lowest importance to culture and time differences for task

allocation. This observation is in contrast to the literature, which highlights the problems

reported due to time and cultural difference in a distributed setting (Damian, 2007). An

empirical study also confirms our survey results that practitioners associate less value to time

and cultural differences when allocating tasks in GSD (Edwards et al., 2008). However, a



systematic literature review highlights that temporal differences are reported by 63% of the

empirical studies as an important factor for task allocation in GSD (Mahmood et al., 2015).

The empirical literature contributing to the statistics is related to the “follow the sun strategy”

for task allocation, so the importance given to the temporal distance is explainable. The

strategy exploits the time difference and achieves around the clock development. However the

contrast between the empirical study and our survey results may point towards the fact that

the follow the sun configuration is uncommon in the industry. The temporal distance is ranked

differently by organizations that usually distribute work to 4-6 sites and those that distribute

work to 9+ sites. The significant difference is interesting as practitioners that belong to

organizations that commonly distribute work to more than 9+ sites have ranked temporal

distance on a low scale, which is opposing to the literature. The numbers of sites increases in

case of 24 hour development, therefore organizations that distribute work to more number of

sites want to take advantage of time zone difference and accomplish 24 hour development.

The literature also highlights the need to assign work to not more than 2 sites for good project

management (Holmstrom et al., 2006).The lack of importance given to temporal and cultural

distances may also be observed because the practitioners implicitly keep them in mind while

determining the communication and coordination overhead during the task allocation

decision. The literature also discusses the relationship, as temporal and cultural distances give

rise to many communication and coordination problems (Jiménez et al., 2009)(Lamersdorf et

al., 2009)(Fabriek et al., 2008)(Olsson et al., 2008)(Sakthivel, 2007)(Gopal et al.,

2011)(Kussmaul, Jack, &Sponsler, 2004)(Espinosa & Carmel, 2003) such as lack of trust, low

team spirit, and no shared vision and common knowledge between distributed members

(Fabriek et al., 2008)(Smite et al., 2011). The relationship between the communication and

coordination overhead and the temporal and cultural distances is also evident from the

identified correlations in the survey response data. Cultural distance is a deciding factor when

selecting a site to offshore or outsource(Carmel & Agarwal, 2006)(Holmstrom et al.,

2006)(Damian, 2007). 51% of CIOs state that the biggest off shoring challenge is overcoming

cultural differences (Sakthivel, 2007). In an empirical study conducted by Carmel and

Agarwal (Carmel & Agarwal, 2006), culture was reported as a de-motivating factor for the

decision to offshore and a main cause for many problems, as the employees were not used to

different accents and cultural diversities. This evidence from the literature highlights that

culture is considered while selecting a site for off shoring or outsourcing. On the other hand,

the task allocation literature also highlighted its significance irrespective of the

communication and coordination overhead or site selection (Lings et al., 2007)(Lamersdorf et



al., 2009). Therefore, the culture of the distributed site should be considered separately as an

important factor during task allocation, whereas the temporal difference is the main criterion

when performing 24-hour development. The interview data has highlighted the importance of

situation that determines the significance assigned to temporal and cultural distance. Thus

when the significance of temporal and cultural difference may diminish, as happens in case of

a critical and urgent task, they are given value when the nature of task requires extensive

communication. Interviews have also emphasized the fact that temporal and cultural

differences are commonly accommodated but special attention is given to the case of

language difference. Language problems are specifically reported in case of China therefore,

transactional work is preferred for them.

5.1.1.4 Process Ownership

1. An important observation is the significance assigned to process ownership by industry

practitioners, which is in contrast to the literature. The high number of correlations between

process ownership and other factors increases its significance. Process ownership is a way of

working where work is not accomplished by departmental units of the organization but rather

it is completed with the help of a process owner and process workers who may reside in

different countries and organizations. Process owners design and execute a process that is

focused on achieving some organizational goal (Hammer & Stanton, 1999). Because process

ownership is directly related to software process improvement and helps achieve desired

results, it is only practiced by mature organizations (Fitzgerald & O’Kane, 1999)(Rainer &

Hall, 2002). The process owner needs to be among the senior executives, who are able to

obtain work from multiple functional units. The authority can be best practiced by senior

managers (Hammer, 2007). The result of the Mann Whitney U test indicates that more

importance given to process ownership by less experienced individuals which is again

surprising. This may be due to lack of knowledge about what actually process ownership is,

since it is not a common practice. The interviewees also assigned less importance to the

process ownership highlighting the fact that it is not practiced by them. The common way of

achieving software development globally is by getting work done from distributed functional

units.

5.1.2 Correlations

The correlations identified between factors are from the weak and moderate category as per

the Spearman coefficient value ranking. The major number of correlations is present between



the factors identified inside the dotted box in figure 4.7. The relationships inside the box are

communication and coordination overhead and time difference, communication and

coordination overhead and cultural distance, communication and coordination overhead and

component dependency, communication and coordination overhead and process ownership,

temporal difference and cultural distance, component dependency and temporal difference,

component dependency and cultural difference, and component dependency and process

ownership The five associated factors are component dependency, communication and

coordination overhead, process ownership, cultural difference and temporal difference. These

correlations are also supported by the literature. They are explained one by one, with the

exception of component dependency and communication and coordination overhead, which

have already been discussed (Conway’s law).

1. The amount of communication decreases with the increase in the time zone difference. The

major reason is the lack of awareness regarding who to contact (Ågerfalk et al., 2005). The

amount of communication over a small time zone range is greater than that over a medium

and large time zone range (Nordio et al., 2011). This is due to a lack of overlapping work

hours, which affects the amount of communication (Holmstrom et al., 2006). The temporal

distance also results in delayed communication and delayed responses, as asynchronous

modes of communication are used. This however increases the response time due and creates

communication and coordination overhead because more emails are generated to resolve an

issue, increasing the time it takes to resolve an issue and thereby the coordination cost

(Ågerfalk et al., 2005). Communication is improved by low socio-cultural distance, which

incorporates both national and organizational cultures (Ågerfalk et al., 2005). Language

differences can cause communication and coordination problems (Herbsleb&Moitra, 2001).

Therefore, communication and coordination overhead and cultural distance are also

associated.

2. A properly modularized project can be assigned to temporally distant sites without

worrying about the communication and coordination overhead (O’Conchuir et al., 2006). On

the other hand, if there are dependencies between modules, it would be difficult to assign it to

temporally distant sites due to the communication and coordination needs. Thus, the

component dependencies need to be addressed before the decision of allocation to temporally

distant sites can be taken, or as reported by the interviewees the modular division of work is

not preferred.



3. Process ownership also has a strong correlation with the communication and coordination

overhead, with a Spearman coefficient value of 0.518 (moderate relationship). This is because

the process owners get work done from multiple skilled workers that are located at global

distributed sites from different functional units (Richardson et al., 2010). Therefore, the

increase in the communication and coordination overhead is explainable.

4. The strong correlation between the temporal difference and cultural difference highlights

the fact that the cultural distance increases with the time zone difference.

Other correlations which are also supported by literature but not present inside the box in the

correlations diagrams are also discussed here one by one.

1. Labour cost is correlated with the site characteristics. Labour cost should not be the only

motivational factor in offshore development, companies should offshore to make use of the

capabilities of people rather than labour cost (Gupta et al., 2007). Software needs to be

developed by people who can meet frequently with people who will use the software prior to

development, during development and after development (customer Proximity(one of the

attribute of site characteristic)) said by the vice president of Citibank Korea (Gupta et al.,

2007).

2. Communication and Coordination Overhead is associated with expertise as identified by

Spearman Rho test. People communicate easily and often with people they know and are

aware of the knowledge and skills they possess (Ehrlich & Chang, 2006).It is highlighted that

when team members are aware of each other profiles such as jobs, roles, and expertise, it

results in developing shared task knowledge which facilitates group coordination and

performance (Ehrlich & Chang, 2006). Shared knowledge of the team will make it easier for

its members to locate experts when needed, thus helping to coordinate the access to and

utilization of that expertise (Faraj&Sproull, 2000).

3. Labour cost is correlated to communication and coordination overhead. The cost of

communication and coordination and the cost of staff that supports communication and

coordination increases the overall cost of a project. The communication and coordination cost

can remove the benefits of reduced labour cost due to too much rework.



5.2 Threats to Validity

The most relevant validity threats to the survey and interview research along with different

precautions undertaken to minimize them are described in respective sections.

5.2.1 Threats to Survey Study

The construct validity defines whether an inference can be made from the study observations

to the theoretical constructs which the study is measuring. The instrument design affects the

construct validity. The phrasing of questions and the metrics are chosen very carefully. We

incorporated the partially structured questions to obtain a correct response from the

respondents. Moreover to remove ambiguity and increase comprehension, the questionnaire

was pilot-tested by a GSD organization. Respondents were provided with a “Do Not Know”

option to remove noise.

Internal validity refers to the phenomenon that results are not influenced by external factors.

To ensure that we only obtain responses from people who are actually involved in task

allocation for GSD projects, responses from researchers were excluded, since we were not

sure whether they have ever worked in the software industry. A cover letter was included with

all emails and postings to ensure that the respondents understand the seriousness and purpose

of the research and respond only if they are interested and involved in task allocation during

GSD. Incomplete responses were also discarded. Cognitive testing of the questionnaire

ensured the comprehension of the survey questions so that the respondents do not

misunderstand. In the mandatory question related to the ranking of the factors, the “Do Not

Know” option was introduced, so that respondents can check it instead of feeling constrained

to select from the Likert scale options.

To ensure the external validity, i.e., the ability to generalize from the results, the samples were

chosen from around the globe. Initially, during the survey design, the number of waves

decided for snowball sampling was five; however the number was reduced to 1 or in few

cases to 2 due to the lack of information on further contacts by the practitioners. Therefore,

we complimented the snowball sampling by posting the survey link on social media, i.e.,

Facebook, LinkedIn and Twitter. We also used email to increase the sample size. A total of

110 responses were received, but only 54 were included as being representative of the

population and complete



5.2.2 Threats to Interview Study

Internal validity of the interview study was also ensured by interviewing 10 highly

experienced project managers from different type and size of GSD organizations working in

different domains.

External validity of interview data was ensured by collecting data from project managers of

different type and sized organizations, all of them were executing GSD.

The descriptive validity of interviews is ensured by recording the interviews and listening to

them again and again so that no information was lost. Open-ended interview questions were

designed and piloted to ensure that they were not biased and not directed towards an answer.

This helped us to ensure interpretation validity. Follow up questions were designed but were

only asked in case of a positive answer. To ensure that the meaning is clearly understood,

answers were reconfirmed from the interviewees. This also helped to reduce interpretation

validity.

Researcher bias is also controlled as the project managers belonged to variant sized

organizations working on the development of different software development via GSD. The

same set of questions was asked from all practitioners regardless of the type and size of

organization and region etc.

Theoretical validity was ensured by recording and reporting all the interview data. The

conclusion of the interview is also peer reviewed. Reactivity was reduced with the help of

cover letter which explained in detail that the responses will be evaluated as aggregate to

ensure respondent’s anonymity. The chapter presents the important factors and their inter

relationship identified from both the empirical studies and highlights the similarities and

differences from reported literature. The next chapter presents the proposed TA framework in

detail. Comparison of the framework with the existing literature is also performed.



CHAPTER 6

Proposed Task Allocation

Framework/Validation



6.1 Task Allocation Framework

e used multiple methods to acquire quantitative and qualitative data comprising of

the TA factors and important information related to the TA decision making. The

TA framework is developed on the basis of the statistical analysis of the acquired

data. The proposed framework is organized in planes where each plane is

associated with the next plane via meaningful relationship. The attributes present

on the plane are also associated with attributes present on other planes. The relationships

between planes are shown with help of arrows. A closer look reveals that the attributes/factors

consist of technical aspects of tasks and technology as well as social aspect of the

organization and individuals. The factors such as component dependency, size, volatility, task

budget and development cost etc. are attributes of tasks and concerned with the technical

aspect of the TA decision whereas other attributes such as trust, personnel capability,

workload, availability, organizational and national culture etc. are social aspects that need to

be considered before making the TA decision. The social aspects are both related to

individuals as well as to organizations or site i.e. group of individuals (team).

Keeping in view the factors which can be differentiated as technical and social factors

necessary for a TA decision, the Social Technical Systems theory is suitable for the

development of the framework. The framework highlights the variant situations to a task

allocation scenario along with the important factors that need to be considered for an effective

task allocation. The variation points identified from the qualitative data are Task, Expertise,

Organization and Site. The framework highlights the shortcomings of the already existing task

allocation strategies along with highlighting the complexity and dynamics of the task

allocation decision.

Social Technical System Theory: The framework is based on socio technical theory where

the organization is seen as a socio technical system (STS). According to STS the best way to

introduce technology is to align it with the social system of the organization(Appelbaum,

1997). The organizations need to adapt to be able to support the technology change; therefore

the best way to introduce technology in the organization is to design processes keeping in

view the social system of the organization. The STS theory is useful in designing/redesigning

work in different areas from manufacturing to software development. The organizational

processes are carried with help of human resource and technology, synchronization is required

between the two for incorporating technology into the social structure of an organization.

Software development processes can benefit from the STS by explicitly modelling the

W



technology and social structure together and accomplish work. The traditional method of

designing technology and then incorporating it in the social structure require change in the

social structure which is not always successful. STS keeps the social aspect in mind while

designing technology and introducing it in the organization. Task allocation is one such

process which can be modelled keeping in view the STS theory. The tasks are allocated

between sites that are composed of teams or individuals whereas the tasks to be performed,

technology needed such as tool, language platform and other resources are the technical

aspect. The STS theory is very successful in case of self-regulating groups, groups that

perform inter related tasks to achieve an objective and have the ability to manage different

scenarios and adapt with reference to different situations. Software Development Teams are

good example of self-regulating groups.

A revised version of the model that also incorporates communities along with individuals to

depict work groups in the social system given below in figure 6.1(Cartelli, 2007). This model

is kept in view while designing the TA framework since we are interested in teams and

organizations to which task is allocated.

Figure 6.1: Representation of revised STS

STS Design: A perfect fit between technology and social structure results in both physical

products as well as psychological outcome. This is the main concern while designing STS, to

ensure that the interaction between the technology and social structure yields positive

outcome whether in the form of a product or psychological outcome. This is known as joint

optimization (Appelbaum, 1997). The process of task allocation in GSD is designed such that

the expertise, culture, availability and domain of work etc. of workers (social component) is



carefully analysed and tasks (technical component) having specific budget, volatility,

requiring a particular skill set and criticality etc. are assigned.

Objective to do GSD is an attribute of the organization participating in GSD, therefore the

explicit consideration is in alignment with the guideline of designing work in STS i.e. work

should be organized according to the objective of organization. The factors on each plane are

identified whereas more factors can be identified in case of different situations. Moreover the

weightage of each factor varies with situation. This is one more aspect of STS that the

features should vary according to the technical and social needs of the situation. The TA

factors are divided on the basis of STS theory and represented with help of the fish bone

diagram in figure 6.2.

Figure 6.2: Proposed Task Allocation Framework (organized in Planes)

The factors according to STS theory are divided into that of Task, Technology, Individual,

Community and Social Structure.

The contribution of this research is twofold; we have gathered industry’s feedback on the

importance of task allocation factors, their correlations and the importance of architecture and

Software Development Task Technology

Team Member

Individual/People

Organization

Community/Team

Site

Social Structure

Task Allocation

Decision

Social System

Technical System

Communication &

coordination overhead

Stability

Development Cost

Legal issue

National Culture

Temporal

Difference

Customer Proximity

Objective of doing GSD

Organizational culture

Domain of Work

Trust

Personnel Continuity

Size

Maturity

Personal Capability

Workload

Availability

Experience of specific

tool/technology/platform and

language

Component Dependency

Volatility

Timeline

Budget

Required Skill Set

Criticality

Size



communication and coordination needs along with the creation of a novel framework to

facilitate task allocation decision. The final framework is presented in figure 6.3 where the

initial framework given to the participants of the focus group is given in Appendix G.

Figure 6.3: Proposed Task Allocation Framework (organized in Planes)

The planes depict the variation points and attributes present on each plane are the factors

necessary for a TA decision in GSD. These factors are directly and indirectly associated to

each other depicting the correlations among them. The framework is also compared with the

task allocation strategies and approaches present in literature described in the next section.

6.2 Comparison with Literature

The literature survey chapter 2 highlights many approaches/ models/ algorithms/ tools and

surveys along with industry experience of TA in GSD. Time difference between distributed

sites is the only criteria used for allocation decision by practitioners and researchers who plan

on achieving 24 hour development (Gorton &Motwani, 1996). Assigning tasks to temporally

distant sites also looks for Operational dependency and skill and resource constraints (Jalote&

Jain, 2006). The 24 hour development model is a famous task allocation and coordination

mechanism also known as follow the sun (Setamanit et al., 2007). Time zone is the



characteristic of the distributed site and catered as property of the site (Lamersdorf&Münch,

2010b). Communication and coordination need or overhead between distributed sites is also a

common task allocation criterion. The research work that allocates tasks to distributed sites

keeping in view communication and coordination requirement is usually based on Conway’s

law (Avritzer et al., 2010)(Sooraj&Mohapatra, 2008)(Amrit, 2005). Product structure or the

architecture of the system is also used for allocation decision (Grinter et al., 1999)(Tran

&Latapie, 2006)(Setamanit et al., 2007)(Avritzer et al., 2010). The coupling between

modules or tasks is seen before a final task allocation decision is made (Bass, 2006). A major

factor that contributes to choose task allocation site is the expertise required for the task

(Grinter et al., 1999)(Mockus& Weiss, 2001)(Edwards et al., 2008). The implicit dependency

that exist between different software development phases or steps is also a major source of

allocation decision which is also known as process steps or phase based allocation (Grinter et

al., 1999)(Mockus& Weiss, 2001)(Tran &Latapie, 2006)(Setamanit et al., 2007). Some less

common ways of allocation include allocation based on release based schedules (Avritzer et

al., 2010), maintenance work (Mockus& Weiss, 2001) and process ownership etc. (Edwards

et al., 2008). None of the approach/strategy/model/ algorithm and tool present in literature

performs task allocation keeping in view the extensive criteria as identified and incorporated

in the proposed TA framework. More over the research that presents detailed criteria draws

data from limited sample size and still miss some factors (Lamersdorf&Münch, 2010b). The

presentation of factors in planes help in understanding the impact they exercise on each other.

This helps in careful evaluation during the TA decision. The informed and careful evaluation

impacts the task allocation decision. The variations to task allocation scenario presented in the

form of planes help in making a decision which is context dependent. The framework is

validated with the help of an online focus group, the design and execution of the focus group

is presented in next section.

6.3 Validation via Online Focus Group

The purpose of the focus group was to gather practitioners’ feedback on the applicability and

effectiveness of the proposed TA framework for GSD projects. Practitioners were asked to

comment on the applicability of the framework keeping in view real world GSD task

allocation scenarios. The feedback of the practitioners’ helped in determining the applicability

of proposed TA framework keeping in view the context, the strengths and weaknesses of the

proposed TA framework, problems in the framework that hinder its applicability and



solutions/changes that will help in improving the framework in order to make it more

practical.

Focus groups are practically helpful in answering analytical phase questions dealing with

comprehension and applicability of the model under discussion (Kontio et al., 2004). They are

cost effective and fast (Bader & Rossi, 1998). Online focus group benefits from the

technology as all conversation can be exported and there is no need to take notes(Bader &

Rossi, 1998). It is also beneficial and supports balanced conversation as shy members of the

group along with individuals of such culture which restraint conversation, actively participate

during the session (Bader & Rossi, 1998).

The focus group is usually composed of 3-12 members, present in a face to face meeting.

However the participants were distributed around the globe in our case with participation

from US, UK, South Africa and Sweden, since the task allocation decision makers in case of

GSD were not available in Pakistan.

We created the focus group on www.focusgroupit.com and sent invitation to all the

participants who had already agreed to participate in the discussion. The invitation to

participate in the focus group session was sent to practitioners working in the area of GSD as

Project Manager or Product Manager; all of them were active in GSD and had read the

framework prior to discussion. The participants of the focus group were identified from

LinkedIn keeping in view our prior experience with the social site. Invitations were sent to

many practitioners involved in GSD. Two of the participants of focus group were also

involved in the interview study that we conducted previously. Therefore the focus group

consisted of seven members two provided their feedback on dynamics of task allocation and

five new members. These members were sent an invitation to participate in the focus group

discussion via link sent to their email. Interaction was ensured with the help of automatic

notification of new comments and answers. The participants were able to view and reply to

answers and comments posted by other member and were encouraged to do so.

The focus group consisted of three main questions along with a warm up and wrap-up section.

The warm up section introduced the participants to the proposed TA framework and inquired

about any confusion regarding framework comprehension. However the framework was also

emailed to all participants beforehand, all the participants came prepared before logging in to

the portal, and therefore no new queries were received.



The protocol of the online focus group session is attached in Appendix F. The participants

were also able to view the response of other practitioners once they responded to a question.

This constraint ensured individuality and eliminated chances of group thinking; to ensure

interaction they were allowed to view and respond to the answers of other participants (Tong,

Sainsbury, & Craig, 2007). The conversation of the focus group was exported and later

qualitatively analysed for improvement to the TA framework.

The discussion of the participants is exported in a word file and is attached in Appendix G

presented participant wise. Qualitative analysis is performed on the feedback and discussion

data of online focus group session and main points are extracted and analysed. The analysis

shows that the overall comments fall in five main categories i.e. those related with factors,

context of use, hierarchy of framework, applicability of framework and other suggested

improvements. The agreement level specifies the support by multiple practitioners.

The extracted comments are organized category wise and presented in table 6.1, where the

comments column specifies the updates done or rationale of why a certain feedback is not

incorporated in the framework. The detailed comments of the focus group participants as well

as the whole discussion exported from the online focus group are attached in Appendix G.

Table 6.1: Main Feedback from Participants of Focus Group Session

Category Sub

Category

Focus Group (Excerpts) Agreement

Level

Comment

Attributes

There are also considerations such as

customer service, technical and production

support - where software is being used as

it's being written and updated then

1

The following factors are

highlighted from discussion

of focus group as missing

in framework

1. Customer’s service,

technical and

production support.

(customer support etc.

is a concern after

software is deployed

we are only concerned

with assigning tasks)

2. Conflict of interest

The framework needs to incorporate the

variable of "conflict of interest" which can

become a big issue when dealing with

global teams and also "conflict

management".

1

Thought about more factors like

Government and Political.

1



Addition

Intellectual Property & security of the

code & assets produced. How well do

contracts, IP agreements, and the practical

aspects of applying the law to deal with IP

issues, work? Some work may be

performed in particular countries or states

for IP and / or security reasons.

I agree that IP protection is an important

consideration, while sometimes it is

politically challenging to implement

2 (management issue)

3. Government and

political influence

(incorporated as

Stability of Site)

4. Intellectual property

(supported by 2

participants therefore

it is incorporated

inside legal Issues; an

attribute of a site)

5. Criticality of a task

attribute defined

which also

encompasses

confidentiality.

You should also consider the

confidentially aspects of the project as

there can be blocks of the SW/project

which need to be specifically contained

within a certain group and geographical

location. You have to also consider the

regulations of the regions that your teams

might be in and think about the

mechanism to accommodate the

confidentiality involved in the project.

This is a very influential factor for all of

the industry sectors where confidentiality

is critical.

1

Update

Some important factors needs elaboration

such as organization's nature plays a

crucial role in aligning project portfolio

strategy with company’s structure and

culture. Moreover, organization’s mission

plays an important part in defining clear

goals and metrics supporting the strategy.

1

We have incorporated an

attribute named as

objective of doing GSD at

organization layer (It

impacts the task allocation

and we are only concerned

with it) more strategic level

factors are not part of

framework since we are

concerned with task

allocation and not

outsourcing



One final comment for now is on the

effects of the technological environment.

In one global company, a checkout of a

project's source code took many hours in a

remote office, but only a few minutes in

the HQ. In another, staff in India had to

remotely connect through remote console

programs to development machines in the

USA to do their work which decreased

their effectiveness by at least one order of

magnitude. The real-world context plays

such a significant role in global software

teams that the context needs to be

understood and factored in. Ditto the

human aspects, including virtually all

aspects of how the people communicate,

interact and work together.

1 It may be related to how

communication and

coordination overhead is

measured as it is dependent

on technology support for

C&C.(Communication and

Coordination overhead

would be measured based

on this, however it is not a

separate factor)

Expertise does not belong to a Site it is

more of a human attribute.

1 We have a separate plane of

expertise; it only shows the

relationship to organization

plane as “belongs to”.

Expertise is a separate

plane which has personnel

capability, experience,

availability and workload

as factors of expertise.

There are various additional factors to

consider including the perceived

(in)equality from one team to another e.g.

if I 'believe' the team I'm receiving the

work from are at least as competent as I

and my team then I'm more willing to

work with them then receive and continue

the work. If, conversely I don't believe

they're as competent I'll question their

work and be reluctant or even refuse to

touch their work.

Additional factors such as trust (in the

competence, ability to deliver, and the

quality of an individual's or a team's work)

are important, relevant factors to consider.

2 We have capability of

personnel as a separate

factor as an attribute of

expertise plane. It has

correlation with trust.

Trust is another attribute

incorporated in

organization plane. Which

is measured on basis of

multiple factors, prior

experience is one of them.



I don't think you clearly bring through the

product definition role - you have product

definition at the site level, but I would

think that would be a more organizational

thing.

1 We only had development

cost, C&C overhead,

customer proximity, time

zone and culture at site

variation point.

Metrics for

Factors

Through bitter experience people learned

that many people hired with certificates

were mediocre at actually writing

software. Experience measured by time is

a very weak and often misleading indicator

of competence, ditto when measured by

many industry certifications such as

ISTQB, Java Certification, etc. (as people

with certifications or experience leave)

1 We have only presented

factors and presented

correlation between them,

they may have positive or

negative impact in different

scenario.

Some of the dimensions are very general

(e.g. "trust") and probably compounded

from other subsidiary dimensions (e.g.

delivery record, quality of work, etc.) that

are more directly measurable.

3 The information about what

metrics are used to measure

each one of the factors

needs a detailed study. The

measures can be qualitative

or quantitative.

However we have included

description of each attribute

in framework as to what

these attributes are and

made up from.

I think the dimensions presented as

components of each layer are too broad

and not directly measurable. How do you

define "work load" or "capability of

personnel" for instance? This makes the

framework less useful for practical

implementation

I agree that describing ways to measure

the dimensions would be useful. Measures

could be quantitative, qualitative, or

nominal scale

Context of

Framework Suited for

Framework is more beneficial for work

packages than tasks or activities.

1 Framework is suitable in

mentioned situations

Framework is good in places where we

have knowledge of the other sites.

Theoretically a task allocation framework

may help somewhat e.g. where

organizations have some awareness of the

expertise of staff and teams in other

locations and the relative costs; they may

3



make more informed decisions.

Framework is beneficial especially when

the product being developed is mature and

has market presence and stability and not

that innovative

On the other hand, if an organization’s

mission is mainly the bottom-line and

profits (most of our corporate software

world), it chooses to invest in projects

which align neatly with its own culture,

strategy and structure. For example, it

prioritizes understanding the needs of

customers and it prefers its product

features to be pulled by customer

requirements, rather than pushed by

technical competence of its researchers

and software engineers. This type of

corporate software organization cherishes

customer affiliation, celebrates teamwork,

leads by established operational processes

and prioritizes the customer. The Bottom-

line is in this type of organization, the

aforementioned task allocation framework

(along with addition of feedback loops

required to assess and change/ review task

allocation as per project dynamics) works

very well because the company already

has established processes and espouses

teamwork and customer affiliation

Not suited

for

A fine-grained task allocation seems to

assume that a conventional project

manager is making the allocation

decisions. This is not the case in self-

directed or agile teams, for whom this

framework would probably be too heavy.

1 We have specified that this

task allocation framework

is for traditional software

development not applicable

for agile methodologies

since the dynamics of task

allocation are different in

agile.

On the other hand, a university research

organization arm or incubation center

cherishes achievement, celebrates brains

and top-performers, leads by expertise and

prioritizes the cutting-edge research work.

1



The task allocation decision is strictly

based on research expertise of the team.

For example, a breakthrough research

module may take time to implement, to

refine and to test for applicability. I, as a

product manager of a team with such

experts made sure that the particular

research feature is implemented in its

entirety, and as such we are able to tap into

the full potential of that research. As a

software manager, my priority in this case

will not involve how much profit this

feature or module will eventually generate.

However, this priority of profit generation

does become a variable in task allocation

decision when product starts to mature.

Hierarchy of

Framework

Layering

hierarchy

good

The variables mentioned in each layer are

accurate and will help with the task

allocation strategy because in reality the

sequence/flow of the layers is not very

explicitly defined or followed and varies

on experience of the person leading the

project. What ends up happening is that

some factors/variables being the most

impacting for the organization tend to

influence the flow and therefore the task

allocation decisions start to revolve around

these variables. This can sometimes cause

the organization to face unexpected

challenges later in the project because of

not foreseeing the less important but

impacting variables ahead of time. This

framework gives a clarity on most of the

major variables with a certain flow (layer

wise) which if considered in planning will

help chose the most suitable task

allocation strategy while laying out hidden

challenges/problems ahead of time.

1 Layering style changed to

depicting factors on

different planes. The

different planes are the

variation points.

Layering

hierarchy

not good

I think they'd consider some of the factors

you've captured in your framework;

however they're unlikely to consider these

factors as part of a hierarchical framework.

I don't believe the hierarchy of levels (if

it's meant to be that) is always the same. I

1



can see cases where the organizational

objectives would be the highest level

factor, or possibly the least important

factor, in the allocation decision

I’d start by removing the concept of

hierarchy (at least initially) and then try

modelling the relationships between the

various entities/objects (task, expertise,

org, & site).

Applicability

of

Framework

Applicable

with

adaptation

From my work experience working in

distributed teams environment, the model

mentions all the aspects. It is a framework

and each company will need to adapt it as

per requirements. The new processes and

methods can be added to compliment the

needs of Task Allocation.

I take this model as a guideline and then

adapted by project based on the factors.

2 Can be judged when

practical implementation

will be provided.

Practical

examples

required

It has potential. However, it would be

more helpful if the framework were

presented as a use case. This would make

it more practical.As stated earlier apply the

framework to real life projects

demonstrating its use. This will remove

the abstract and make it more concrete.

I agree, providing different scenarios can

well motivate the usefulness of model

Provide example scenarios which illustrate

how task allocation would occur without

the framework, and with, to show how the

framework is used and how it can be

useful. Do this with input from industrial

companies if possible, or as thought

experiments if not.

Yes, GSD is agile and over time there will

be different challenges. The real world

application of the framework will provide

more valuable insight towards using it.

I agree with both Mathew and Prof... - this

5 Part of future work to

extend this framework by

implementing the

framework on different

situations of Global

Software Development.



framework seems theoretical. I personally

doubt it'd be workable in actual software

development projects (whether academic,

open source, commercial or governmental

(including security-sensitive work)). I've

found the material interesting to read

(albeit by skimming through the 2

documents provided) and think you've

done a lot of research and thinking about

relevant issues - the challenge is to move

from theory to validation of the concept

and the model.

Alignment

with process

and SDLC

phases

In SDLC (Software Development Life

Cycle) there are different stages/phases

and I think in this framework an important

assumption that needs to be defined is that

the strategy based on the framework

MUST be revisited at every phase as the

priorities and the impacting variables can

change during the SDLC.

What do you think about aligning the

processes and development

methodologies? If same way of working is

not followed then it can effect on planning

and deliverables.

2 Future Work

Aspects to

incorporate

Other issues that can be discussed with

respect to the framework and established

industry practices, which can potentially

extend the process of task allocation

include:

I. Enabling of distributed work

(Installation and deployment of tools for

collaboration, and

familiarity with those tools across the

entire team that uses them)

II. Measuring performance and appraisal

of developers and testers

III. Conflict management

1



Detail

required

More rigorous definition of the appropriate

dimensions for each level. More context to

define what the layers actually mean, and

how you see their contribution to the

overall project structure.

It's not clear whether this model is meant

to represent a single organization with

multiple development centers, as opposed

to a sub-contracting kind of effort with

multiple vendors. The task/resource

allocation decisions are different in either

case.

I've seen examples where outsourcing

companies provide an 'A' team to win a

contract / project then - over time - quietly

replace the more competent team members

with less expensive, significantly less

competent staff. Staff changes are

commonplace and frequent in

organizations and team and will occur

during many assignments. How does the

model communicate these changes and

their likely immediate and longer term

impacts?

Each component of each layer of the

framework needs to be defined to provide

a proper context to the reader.

2 The layers are changed to

planes and each plane as

well as the attributes of a

plane are defined in detail.

The framework is for both

single organizations

multiple sites and multiple

sites of different

organizations. The

weightage assigned to

attributes will vary in

different cases.

Task allocation decision

can be updated in case of

changes in architecture and

other criteria.

6.3.1 Limitations of Online Focus Group

We were unable to conduct face to face focus group session, since the participants were

situated around the globe. Online focus group (Murgado-Armenteros, Torres-Ruiz, & Vega-

Zamora, 2012)(Bader & Rossi, 1998) is a variation which can be used in situations like these

to handle participation from temporally and geographically distant sites. The online focus

group promises many advantages (Bader & Rossi, 1998). The online focus group is like a

bulletin board or blog consisting of asynchronous communication (Murgado-Armenteros et

al., 2012)(Bader & Rossi, 1998). Online focus group does suffer from limitations of lack of

real time groupness and interaction (Murgado-Armenteros et al., 2012), however we tried to



minimize this limitation by selecting practitioners from similar background to increase

groupness.

To ensure discussion, all participants were communicated that the focus group will be active

for three days only and that they are required to login time and again in these three days to

view answers by other participants and can comment on them as well. An automatic

notification was also sent via email automatically by the portal for any new submitted answer

or comment.

6.4 Revisions in the Framework

The framework is revised on the basis of the comments and feedback of the practitioners. The

final TA framework is presented in figure 6.3 above whereas the TA framework initially

proposed and given to the focus group participants is attached in appendix G. The correlation

among factors on same plane is represented by solid lines whereas between factors on

different planes is represented by dotted connections. The relationship between different

planes is also depicted with help of connectors with name of the association written on top of

it. The social and technical perspective is evident from the planes and attributes, the

relationship between the attributes and planes depicted with help of arrows highlight the

synchronization between attributes that is required for a successful TA decision.

Three new factors are added as a result of focus group suggestions, which are given below

1. Legal Issues (Attribute of a Site) includes Intellectual Property and Security of a Site.

2. Stability (Attribute of a Site) includes financial and political stability of a site.

3. Criticality(Attribute of a Task)

The legal issue attribute is incorporated to depict the Intellectual Property and legal binding to

allocate task to a particular site, also supported by a survey conducted by industry experts in

2017 (Mahmood et al., 2017).

The security of a site or political stability of site is measured via stability which is again a site

characteristic. The criticality is an attribute of a task which may incorporate the importance of

the task. The importance is measured via its business value, complexity or due to its

confidentiality.



A major change is concerned with the organization of the framework. It was organized in

layers, but a major criticism was on the constraints imposed by layered hierarchy. Therefore

the framework is organized in planes with each plane consisting of related attributes which are

related with other attributes on the same plane as well as across plane. The dotted arrows

show the relationship between factors across planes whereas solid arrows show the

relationship between factors on the same plane. The direction of the relationship is shown

with help of the arrow.

All the rest of the factors are explained under their respective heading.

1. Site:

a. Legal issues (incorporates the legal issues related to development of software at

that particular site, also includes Intellectual Property rights)

b. Stability (stability can be measured both in cases of financial stability as well as

political stability)

c. National culture (highlights the culture of the region, includes attributes such as

culture, holidays, norms and values of the people living in that region)

d. Development Cost (includes labour cost and other cost such as cost of

communication and coordination, infrastructure, taxes etc.)

e. Temporal Difference (Temporal difference is not only measured on the basis of

time zone of the site but the overlapping working hours (removes the breaks) and

shift of time on which work is usually done at that time (e.g. in some countries

evening shift is taken))

f. Communication and Coordination Overhead (measured on the basis of national

culture, organizational culture and time zone difference)

g. Customer Proximity (how much close the site is to the customers of the product or

software being developed

2. Organization

a. Size (usually measured with help of number of employees)

b. Maturity (measured on the basis of CMM level achieved or on the basis of the

maturity of the processes and practices)

c. Domain of Work (type of domain the organization develops software for e.g.

Financial Systems, Healthcare Solutions etc..)



d. Organizational Culture (Corresponds to the work ethics norms and values of

the organization, includes belief towards innovation, teamwork, aggressiveness

and stability etc.)

e. Trust (trust is measured on the basis of prior experience which may relate to

quality of delivered work, ability to handover on promised time line etc.)

f. Objective of Doing GSD (the literature has highlighted many reasons of doing

GSD such as to achieve 24 hour development, reducing development cost,

increasing the quality etc.)

g. Personnel Continuity (the staff turnover is measured as a percentage of average

monthly employment)

3. Expertise

a. Availability (it is measured directly as if a resource is available or not due to

being busy on other projects or on leave)

b. Workload (if the person is available but has heavy work load, it is concerned

with the busy schedule of the selected personnel)

c. Personal Capability (highlight the ability of the person to deliver quality work

in the specific time; it will include capability to work under pressure, ability to

solve problems and work in team etc. It is also measured on the basis of skill

set of the person)

d. Experience (measured on the basis of experience with the specific tools,

technology platform or type of application etc.)

4. Task

a. Volatility (the changing nature of the task, deals with the certainty of work to

be accomplished)

b. Criticality (measured on the basis of complexity, business value or

confidentiality of the task)

c. Timeline (time duration assigned for the task)

d. Budget (cost assigned to the task)

e. Component Dependency (architectural dependency between components

related to the task to be allocated)

f. Required Skill Set (the required skills to accomplish the task, can be specific to

a language, tool or domain)

g. Size ( measured on the basis of function point or lines of code to be written)



The weights assigned to factors may vary from situation to situation. The project

characteristics and nature of the task can affect the weightage. Consensus among the task

allocation team members is required for assigning proper weights to the factors. Detailed

evaluation of the factors along with their weights will help in reaching an informed and

effective task allocation decision. The planes can be extended to incorporate more factors in

case of new factors.

The revised framework consists of four planes namely Task, Expertise, Organization and Site,

which are also the variation points that determine the GSD scenario. The planes are connected

with each other via “Requires”, “Belongs To” and “Situated At” relationship. Task requires an

expertise, the expertise belongs to an organization and the organization is situated at a site.

The attributes of these planes are the factors that are important for a task allocation decision

and should be thoroughly and explicitly considered for an informed task allocation decision.

However it is not necessary that all the factors are important in all situations, some factors

may not be important in a given situation at all e.g. if an organization is not involved in any

project at the moment then workload is not applicable. Some factors may be considered but

their relative importance diminishes e.g. in a project where it is being developed for a new

platform, the requirements remain the same and hence factors like volatility and time line are

not much important. Thus the trade-offs that take place in a GSD situations are determined by

the attributes on the four planes. The attributes/ factors can also be extended based on new

information.

The chapter presents the final proposed TA framework, its comparison with the existing

literature. The design and execution of the focus group study to validate the framework is also

given. The recommendations and changes suggested by the practitioners are presented. The

changes done to the framework are justified, whereas rational for suggestions which are not

incorporated is also given. Conclusion and Future work is presented next. The characteristics

of the task i.e. budget, size, criticality and time line etc. are all mapped to the task present in

the technical system. The expertise hold factors that can be mapped to specific individual or

team members in GSD, therefore linked to people in social systems. The factors related to

organization such as personnel continuity, trust, objective of doing GSD, organizational

culture, size and maturity can be mapped to community since these attributes are

characteristics of groups of people.





CHAPTER 7

Conclusion and Future Work



T

7.1 Conclusion and Contributions

ask allocation is of critical importance to GSD because the success of a GSD

project depends upon effective allocation decision. The literature highlights

the need for an informed task allocation decision but the task allocation

strategies lack the depth. The strategies present in literature as well as

practiced by industry work by allocating tasks to distributed sites on the basis of limited

criteria such as labour cost, expertise or time distance individually. Therefore the gap

motivated us to aim for improving the TA decision making process in GSD. Our main goal

was to facilitate the task allocation process by highlighting the important information

explicitly that is required during the decision making process. We have developed a TA

framework which provides information of the important factors and variations to a GSD task

allocation decision making.

The research process we selected was a detailed literature review to capture the research work

in the area, followed by an industrial survey and an interview study to capture the breadth and

depth of the industry practice with respect to task allocation in GSD. The objectives to

achieve the goal of this research are listed one by one along with the contributions of the

research.

Objective 1: To identify the important factors and their relative importance during task

allocation decision while GSD according to practitioners’ point of view. To determine

the role of product architecture during task allocation decision. To check the

applicability of Conway’s law during TA decision.

The literature of task allocation in GSD was thoroughly studied to identify the problem

statement. The limitations of the task allocation decision making activity motivated us to gain

in-depth knowledge of the TA activity in GSD. The literature motivates the use of many

important factors for the task allocation decision, however none of the strategies and

approaches present in literature considers all of them. Moreover what actually goes on in

making the task allocation decision in practice is missing from the literature.

A comprehensive survey (Lamersdorf et al., 2009) performed also lacks some of the

important factors. Therefore the detailed literature survey helped in identification of the

important task allocation factors necessary for an informed decision making process in GSD.



The comprehensive list developed as a result of the literature survey was used and given to

GSD practitioners for ranking.

Task allocation in GSD is performed by organizations involved in developing the software

globally. Moreover the organizations which divide or distribute work are the ones which can

provide useful information, where the organizations which receive work do not have much

knowledge of the TA decision. The region where we reside is on the receiving end of the

work in case of GSD. Hence feedback of the practitioners’ from same region was not of much

use. Travelling to multiple regions was also not possible. To solve this issue we made use of

the computer technology to reach practitioners around the globe during all three studies i.e.

survey, interview and focus group. These three industrial feedbacks took most of the time in

all three cases requiring persistence and endurance; however the end result is the data, which

is representative of the real world.

The survey helped in identification and ranking of the important factors to task allocation

decision from practitioner’s point of view. The correlation between the task allocation factors

was identified with help of a Spearman Rho test applied on survey data. The correlation

highlights the complexity of the task allocation decision making activity where all factors

needs to be seen together. The correlations are also backed-up by the literature review in the

chapter of findings and discussions. The factors considered as critical by the GSD

practitioners for TA decision is finalized after three empirical studies and is given in end.

The results of the survey show that product architecture is important and ranks the different

architectural relationships in terms of their importance to task allocation decision in chapter 4.

It also shows that Conway’s law is used during task allocation decision since the component

dependencies are used to identify the communication and coordination requirements between

teams, which are then considered during the task allocation decision. However the results of

the interview study are in contrast to these observations which are discussed under objective

2.

Objective 2: To understand the process and dynamics of task allocation decision in GSD.

We conducted an interview study from 10 experienced GSD practitioners to understand the

dynamics of the task allocation decision. The results of the interview have highlighted the

importance of variation points i.e. the different variations that make up a GSD situation, some

of which are:



1. Type of GSD i.e. off shoring or off shore outsourcing

2. Nature of project or task (Criticality and Urgency of project or task)

3. GSD involving multiple vendors

4. Number of distributed sites

5. Objective of carrying out GSD

6. GSD involving large and small company(s)

The final variation points embedded in the framework are that of Task, Expertise,

Organization and Site. The interviews with GSD practitioners have also highlighted the trade-

offs that take place during the TA decision making process. The trade-offs between factors

depend on the values of the attributes related to these variations e.g. if the objective of the

GSD is to do 24 hour development then temporal distance, cultural distance and

communication and coordination overhead is very much important. The interview study has

highlighted the complexity of the task allocation decision making process where the

information of factors, correlations, variations is required to perform a trade-off and reach a

decision.

The interviewees have reported that although the product architecture does influence

communication and coordination requirement, however dependent components are not

allocated to distributed sites. Some experiences of communication and coordination overhead

between distributed sites that resulted in unnecessary delays were also reported by the

practitioners. Overall the decision to keep dependent modules on one site is preferred and

detailed architecture is not needed before task allocation due to the very same reason.

Hence the ranking of different architectural relationships by survey respondents is not of

much use. Moreover although Conway’s law is applicable and used in research for TA but is

not used as far as TA decision in GSD industry is concerned.

Objective 3: To design an effective way to allocate tasks to distributed teams in GSD.

The information obtained from the survey and interview study is used to develop a TA

framework. The proposed framework does not prescribe a specific sequence of steps and

guarantee success; however it may help in increasing the awareness of the influencing factors,

and the variations to a task allocation decision in GSD. This awareness can help in an

informed and sound instead of an ad-hoc allocation decision. The valuable comments and

suggestions of the focus group participants are used to refine the framework. The final list of



factors considered as important for a TA decision in GSD are presented in front of each

variation point.

1. Site:

1. Legal issues

2. Stability

3. National culture

4. Development Cost

5. Time Zone

6. Communication and Coordination Overhead

7. Customer Proximity

2. Organization

1. Size

2. Maturity

3. Domain of Work

4. Organizational Culture

5. Trust

6. Objective of Doing GSD

7. Personnel Continuity

3. Expertise

1. Availability

2. Workload

3. Capability of Personnel

4. Experience

4. Task

1. Volatility

2. Criticality

3. Timeline

4. Budget

5. Component Dependency



6. Required Skill Set

7. Size

The proposed framework is validated with help of a computer mediated focus group session

involving 7 GSD practitioners from around the globe. The practitioners validated the

framework and discussed the applicability in real world TA situations. The feedback and

suggestions given by the participants are incorporated and the framework is revised on the

basis of these suggestions. The framework having passed the initial level of validation is now

ready for use in real world TA scenario, which we plan to do as part of the future work to this

research.

The Framework facilitates the practitioners in raising awareness of what factors are important

to the task allocation decision and should be explicitly considered for an informed TA

decision.

7.2 Implication on Research

A detailed literature review along with industrial survey and interview study has identified the

important factors to the TA decision during GSD. The comprehensive list of factors is useful

for researchers interested in application of TA in different scenarios and automation of the TA

framework.

The interview study has also highlighted the importance of situational characteristics which

can impact the value of these attributes and therefore the TA decision. The statistical tests

performed on the survey data have identified the correlations, emphasizing that the factors

cannot be evaluated individually increasing the complexity of the task allocation decision.

These correlations call for multiple trades-offs before a final task allocation decision can be

made. Each trade-off has its associated pros and cons, which can only be evaluated with

respect to the situation and goal. Therefore the research opens ups a new dimension of

research concerned with the dynamics of the task allocation process.

7.3 Implications on Industry

All the work performed in this research is based on practitioner’s point of view. Therefore no

gap exists between research and industry in this research. The factors are validated from the

practitioners. Mixed method approach is used to gather useful data from highly experienced



GSD practitioners’ making the findings of the research more valuable. The framework raises

awareness of the different dimensions of the task allocation process for practitioners.

7.4 Personal Reflections, Lessons learnt

We started with the need to identify the important factors to a GSD task allocation decision

but ended with multifaceted information to the problem including variation points, trade-offs

and goals as an important dimension to the decision making process along with the TA

factors. Thus addition to objectives to fulfil the goal was done throughout the research. The

final task allocation decision is made on the basis of careful evaluation of all the important

factors, trade-offs and variations with respect to the goal of GSD.

A systematic literature review instead of a normal literature review would have been more

beneficial in the start making sure that no empirical evidence is missed. But we found a

systematic literature review later in the research process and compared our results with it.

Residing in a region where task allocation is not performed, since it is on the receiving end of

work introduced many difficulties and delays. However the computer mediated tools for

survey, interviews and focus group helped accomplish the research goal. If I were to go back

in time and select a research topic again I would choose one related to the receiving side

organizations in GSD. The shift to Distributed Development (DD) instead of GSD could also

have sped up the work.

Lack of response from the industry is a big hindrance in conducting useful research. A lot of

invitations for participation in survey interview and focus group via email and social sites

used ample amount of time from the research process. Moreover the response rate after

spending a lot of time was low, which is one of the limitations of the research. However we

gathered enough responses in all three cases to be able to get useful information. Having

personal contacts in the global industry could have helped, but again coordination from

greater distance is still an issue.

7.5 Research Ethics

The research work is novel and the idea is not copied or taken from another source. Similar

literature is presented in Chapter 2 and properly cited. We have tried our best to present



information accurately and with reference. A thorough plagiarism check has been performed,

the work is typed and any matching if found has been rephrased or quoted.

This research uses two main research methods i.e. survey and interviews to collect data and

focus group study to validate framework. The participants of all the studies were educated

prior to the execution of the methods about

1. Anonymity of the responses

2. Usage of response as an aggregate

3. Usage of response for research purpose only

We have also made sure that no information regarding the identity of the participants is

disclosed in the document. The consent to record the interview was taken prior to conducting

interviews.

Statistical Package for Social Sciences is used to run the statistical analysis on the acquired

data saved in excel file, the results are not manipulated.

The work does not have any conflict of interest.

A part of the research work is already published and is available online. Whereas another one

has been submitted to a computer science journal. Both submissions have been made keeping

in view the research ethics.

7.6 Future Work

The framework is not applied on real world GSD task allocation scenarios of variant sized and

type of organizations and situations. We plan to use the framework on real task allocation

scenarios to evaluate its applicability as part of future work to this research. However to do

this, we would first need to develop tool support to facilitate the implementation of the

proposed solution. The first step towards the automation of TA decision making process

would be use of fuzzy logic to generate rules for evaluating factors with reference to the

specific GSD scenario. Metrics would need to be defined for each factor to ensure quantitative

measurement and facilitate design and development of tool. Our final goal is to determine the

impact of a well-considered situation specific task allocation on communication and

coordination overhead and thereby the project duration as an extension to this research. We

also aim to identify the points where task allocation/ reallocation decisions should be made



during software development. It can be aligned and integrated with the software development

methodology followed for software development. Task allocation is an activity which is

performed in case of traditional software development methodologies, whereas the dynamics

of agile software development are very different. Moreover whether the framework can help

in agile methodologies will also be seen as a future work, since some work in the direction of

task allocation is already underway.

7.6 Publication and Research Objectives

Table 7.1: Objective mapped with Publications

Research Objective Publication Status

Objective 1: To identify the important

factors and their relative importance

during task allocation decision while

GSD according to practitioners’ point

of view.

Salma Imtiaz, Naveed Ikram,

“Dynamics of Task Allocation in

Global Software Development”,

Journal of Software: Evolution and

Process, volume 29, issue 1, 2017.

Published

Objective 2: To understand the process

and dynamics of task allocation

decision in GSD.

Salma Imtiaz, Naveed Ikram, “A

Framework for Task Allocation in

Global Software Development:

Results of a Computer Mediated

Focus Group”, Submitted in Journal

of Submitted in Journal of Computer

Information Systems.

In Progress

Objective 3: To design an effective

way to allocate tasks to distributed

teams in GSD.

Salma Imtiaz, Naveed Ikram, “A

Framework for Task Allocation in

Global Software Development:

Results of a Computer Mediated

Focus Group”, Submitted in Journal

of Information Technology and

Software

In Progress

References



Ågerfalk, P. J., Fitzgerald, B., Holmström, H., Lings, B., Lundell, B., & Conchúi, E. Ó. (2005). A

framework for considering opportunities and threats in distributed software development.

Proceedings of the International Workshop on Distributed Software Development, Paris,

Austrian Computer Society, pp 47–61.

Al-Ani, B., & Edwards, H. K. (2008). A comparative empirical study of communication in distributed

and collocated development teams. Proceedings of the International Conference on Global

Software Engineering, pp. 35–44.

Ali, S., Li, H., Khan, S. U., & Zhao, Y. (2018). Fuzzy Multi Attribute Assessment Model for Software

Outsourcing Partnership Formation. IEEE Access, Volume 6, pp 55431 - 55461, DOI

10.1109/ACCESS.2018.2871710.

Alsri, A., Almuhammadi, S., & Mahmood, S. (2014). A model for work distribution in global software

development based on machine learning techniques. Presented at the Science and

Information Conference (SAI), Heathrow, London, pp. 399–403.

Amrit, C. (2005). Coordination in software development: the problem of task allocation. In ACM

SIGSOFT Software Engineering Notes, Volume 30, pp. 1–7.

Amrit, C., & Hillegersberg, J. van. (2007). Mapping social network to software architecture to detect

structure clashes in agile software development. Presented at the European Conference on

Information Systems, St. Gallen, Switzerland, pp.334-345.

Amrit, C., & van Hillegersberg, J. (n.d.). Task Allocation In a Globally Distributed Software

Development Environment, pp. 105-113.

Appelbaum, S. H. (1997). Socio-technical systems theory: an intervention strategy for organizational

development. Management Decision, 35(6), pp. 452–463.

Aspray, W., Mayadas, F., & Vardi, M. Y. (2006). Globalization and offshoring of software. Report of

the ACM Job Migration Task Force, Association for Computing Machinery.

https://doi.org/10.1109/ACCESS.2018.2871710



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), pp. 1881–

1895.

Bader, G. E., & Rossi, C. A. (1998). Focus groups: A step-by-step guide, San Diego, Calif: Bader Group;

1999.

Bass, M. (2006). Monitoring GSD projects via shared mental models: a suggested approach. In

Proceedings of the 2006 International workshop on Global software development for the

practitioner, Shinghai, China, pp. 34–37.

Bass, M., Mikulovic, V., Bass, L., James, H., & Marcelo, C. (2007). Architectural misalignment: An

experience report. The Working IEEE/IFIP Conference on Software Architecture, Mumbai,

India, pp. 17–17.

Battin, R. D., Crocker, R., Kreidler, J., & Subramanian, K. (2001). Leveraging resources in global

software development. IEEE Software, 18(2), pp. 70–77.

Begel, A., Nagappan, N., Poile, C., & Layman, L. (2009). Coordination in large-scale software teams. In

Proceedings of the 2009 ICSE Workshop on Cooperative and Human Aspects on Software

Engineering, Vancouver, Canada, pp. 1–7.

Boucké, N., & Holvoet, T. (2006). Relating architectural views with architectural concerns. In

Proceedings of the 2006 international workshop on Early aspects at ICSE, Shanghai, China,

(pp. 11–18.

Bowman, I. T., & Holt, R. C. (1998). Software architecture recovery using Conway’s law. Presented at

the Proceedings of the 1998 conference of the Centre for Advanced Studies on Collaborative

research, Ontrio, Canada, p. 6.

Carmel, E. (1999). Global software teams: collaborating across borders and time zones. Upper Saddle

River, NJ, USA, Prentice Hall PTR.

Carmel, E., & Agarwal, R. (2001). Tactical approaches for alleviating distance in global software

development. IEEE Software, 18(2),pp. 22–29.



Carmel, E., & Agarwal, R. (2006). The Maturation of Offshore Sourcing of Information Technology

Work. In: Hirschheim R., Heinzl A., Dibbern J. (eds) Information Systems Outsourcing.

Springer, Berlin, Heidelberg, pp. 631–650.

Cartelli, A. (2007). Socio-technical theory and knowledge construction: Towards new pedagogical

paradigms?. Issues in Informing Science & Information Technology, pp. 1-14.

Casey, V., & Richardson, I. (2006). Uncovering the reality within virtual software teams. In

Proceedings of the 2006 international workshop on Global software development for the

practitioner, Shanghai, China, (pp. 66–72). ACM.

Clerc, V., Lago, P., & Van Vliet, H. (2007). Global software development: are architectural rules the

answer?. Second IEEE International Conference on Global Software Engineering, Munich,

Germany, pp. 225–234.

Componation, P. I., & Byrd Jr, J. (2000). Utilizing cluster analysis to structure concurrent engineering

teams. IEEE Transactions On Engineering Management, 47(2), pp. 269–280.

Conway, M. E. (1968). How do committees invent. Datamation, 14(4), pp. 28–31.

Damian, D. (2007). Stakeholders in global requirements engineering: Lessons learned from practice.

IEEE Software, 24(2), pp. 21–27.

Damian, D., Izquierdo, L., Singer, J., & Kwan, I. (2007). Awareness in the wild: Why communication

breakdowns occur. Second IEEE International Conference on Global Software Engineering,

Munich, Germany, pp. 81–90.

de Souza, C. R., Quirk, S., Trainer, E., & Redmiles, D. F. (2007). Supporting collaborative software

development through the visualization of socio-technical dependencies. In Proceedings of the

2007 international ACM conference on Supporting group work, Sanibel Island, Florida, US, pp.

147–156.

Doma S., Gottschalk L., Uehara T., Liu J. (2009) Resource Allocation Optimization for GSD Projects. In:

Gervasi O., Taniar D., Murgante B., Laganà A., Mun Y., Gavrilova M.L. (eds) Computational



Science and Its Applications –. ICCSA 2009. Lecture Notes in Computer Science, Volume 5593.

Springer, Berlin, Heidelberg, pp. 13-28.

Easterbrook, S., Singer, J., Storey, M.-A., & Damian, D. (2008). Selecting empirical methods for

software engineering research. In Guide to advanced empirical software engineering, Lake

Beuno Vista, Florida, US, pp. 285–311.

Edwards, H. K., Kim, J. H., Park, S., & Al-Ani, B. (2008). Global software development: Project

decomposition and task allocation. In International Conference on Business and Information,

Innsbruk, Austria.

Ehrlich, K., & Chang, K. (2006). Leveraging expertise in global software teams: Going outside

boundaries. International Conference on Global Software Engineering, Gothenburg, Sweden,

pp. 149–158.

Espinosa, J. A., & Carmel, E. (2003). The impact of time separation on coordination in global software

teams: a conceptual foundation. Software Process: Improvement and Practice, 8(4), pp. 249–

266.

Fabriek, M., Brand, M. van den, Brinkkemper, S., Harmsen, F., & Helms, R. (2008). Reasons for

success and failure in offshore software development projects. European Conference on

Information Systems , Galway, Ireland.

Faraj, S., & Sproull, L. (2000). Coordinating expertise in software development teams. Management

Science, 46(12), pp. 1554–1568.

Fernandez, J., & Basavaraju, M. (2012). Task allocation model in globally distributed software projects

using genetic algorithms. Presented at the Seventh International Conference on Global

Software Engineering, Porto Alegre, Brazil, p. 181.

Fitzgerald, B., & O’Kane, T. (1999). A longitudinal study of software process improvement. IEEE

Software, 16(3), pp. 37-45.



Gopal, A., Espinosa, Ja., Gosain, S., & Darcy, D. P. (2011). Coordination and Performance in Global

Software Service Delivery: The Vendor’s Perspective. IEEE Transactions on Engineering

Management, 58(4), pp. 772–785.

Gorton, I., & Motwani, S. (1996). Issues in co-operative software engineering using globally

distributed teams. Information and Software Technology, 38(10), pp. 647–655.

Graham Hole Research Skills Mann-Whitney test handout version 1.0. (2011). Retrieved September

10, 2015, from https://www.google.com.pk/?gws_rd=cr,ssl&ei=lU7xVZ6uGMStsgGI0YTYAQ#

q=Mann+Whitney+U+Handout+2011

Grinter, R. E., Herbsleb, J. D., & Perry, D. E. (1999). The geography of coordination: dealing with

distance in R&D work. In Proceedings of the international ACM SIGGROUP conference on

Supporting group work, Phoenix, USA, pp. 306–315.

Gupta, A., Crk, I., & Bondade, R. (2011). Leveraging temporal and spatial separations with the 24-hour

knowledge factory paradigm. Information Systems Frontiers, 13(3), pp. 397–405.

Gupta, A., Seshasai, S., Mukherji, S., & Ganguly, A. (2007). Offshoring: the transition from economic

drivers toward strategic global partnership and 24-hour knowledge factory. Journal of

Electronic Commerce in Organizations (JECO), 5(2), pp. 1–23.

Hammer, M. (2007). The process audit. Harvard Business Review, 85(4), p. 111.

Hammer, M., & Stanton, S. (1999). How process enterprises really work. Harvard Business Review,

Volume 77, pp. 108–120.

Herbsleb, J. D. (2007). Global software engineering: The future of socio-technical coordination. Future

of Software Engineering, Minneapolis, Minnesota, pp. 188–198.

Herbsleb, J. D., & Grinter, R. E. (1999a). Architectures, coordination, and distance: Conway’s law and

beyond. IEEE Software, 16(5), pp. 63–70.

Herbsleb, J. D., & Grinter, R. E. (1999b). Splitting the organization and integrating the code: Conway’s

law revisited. In Proceedings of the 21st international conference on Software engineering,

Los Angeles, USA, pp. 85–95.



Herbsleb, J. D., & Mockus, A. (2003). An empirical study of speed and communication in globally

distributed software development. IEEE Transactions On Software Engineering, 29(6), pp.

481–494.

Herbsleb, J. D., Mockus, A., Finholt, T. A., & Grinter, R. E. (2000). Distance, dependencies, and delay in

a global collaboration. In Proceedings of the 2000 ACM conference on Computer supported

cooperative work, Philadelphia, USA, pp. 319–328.

Herbsleb, J. D., Mockus, A., Finholt, T. A., & Grinter, R. E. (2001). An empirical study of global

software development: distance and speed. In Proceedings of the 23rd international

conference on software engineering, Toronto, Ontrio, Canada, pp. 81–90.

Herbsleb, J. D., & Moitra, D. (2001). Global software development. IEEE Software, 18(2), pp. 16–20.

Holmstrom, H., Conchúir, E. Ó., Agerfalk, P. J., & Fitzgerald, B. (2006). Global software development

challenges: A case study on temporal, geographical and socio-cultural distance. International

Conference On Global Software Engineering, Florianopolis, Brazil, pp. 3–11.

How should one interpret the comparison of means from different sample sizes? - Cross Validated.

(2012). Retrieved September 10, 2015, from https://stats.stackexchange.com/questions/

31326/how-should-one-interpret-the-comparison-of-means-from-different-sample-

sizes/31330#31330

J. Alberto Espinosa1, Sandra A. Slaughter2, Robert E. Kraut3, James D. Herbsleb4. (n.d.). Team

Knowledge and Coordination in Geographically Distributed Software Development. Journal of

Management Information Systems, 24(1) , pp. 135–169. https://doi.org/10.2753/MIS0742-

1222240104.

Jalote, P., & Jain, G. (2006). Assigning tasks in a 24-h software development model. Journal of

Systems and Software, 79(7), pp. 904–911.

Miguel Jiménez, Mario Piattini, and Aurora Vizcaíno, “Challenges and Improvements in Distributed

Software Development: A Systematic Review,” Advances in Software Engineering, Vol. 2009,

Article ID 710971, 14 pages, 2009. https://doi.org/10.1155/2009/710971.

https://doi.org/10.1155/2009/710971



Keil, P., Paulish, D. J., & Sangwan, R. S. (2006). Cost estimation for global software development. In

Proceedings of the 2006 International workshop on Economics driven software engineering

research, Shanghai, China, pp. 7–10.

Khan, S.U., M. Niazi & N. Ikram. Systematic Literature Review Protocol for Software Outsourcing

Relationships Trust (SORT). School of Computing & Maths, Keele University, UK.

Kommeren, R., & Parviainen, P. (2007). Philips experiences in global distributed software

development. Empirical Software Engineering, 12(6), pp 647–660.

Kontio, J., Lehtola, L., & Bragge, J. (2004). Using the focus group method in software engineering:

obtaining practitioner and user experiences, Presented at the International Symposium on

Empirical Software Engineering, Redondo Beach, CA, USA, pp. 271–280.

Kothari, C. R. (2004). Research methodology: Methods and techniques. New Age International.

Kroll, J., Friboim, S., & Hemmati, H. (2017). An empirical study of search-based task scheduling in

global software development. Presented at the 13th International Conference On Software

Engineering, Beunos Aires, Argentina, pp. 183–192.

Kussmaul C., Jack R., Sponsler B. (2004) Outsourcing and Offshoring with Agility: A Case Study. In:

Zannier C., Erdogmus H., Lindstrom L. (eds) Extreme Programming and Agile Methods -

XP/Agile Universe 2004. XP/Agile Universe 2004. Lecture Notes in Computer Science, Volume

3134. Springer, Berlin, Heidelberg, pp. 147-154.

Lamersdorf, A., & Munch, J. (2009). TAMRI: a tool for supporting task distribution in global software

development projects. International Conference On Global Software Engineering, Limereck,

Ireland, pp. 322–327.

Lamersdorf, A., & Münch, J. (2010a). A multi-criteria distribution model for global software

development projects. Journal of the Brazilian Computer Society, 16(2), pp. 97–115.

Lamersdorf A., Münch J. (2010b) Model-Based Task Allocation in Distributed Software Development.

In: Nordio M., Joseph M., Meyer B., Terekhov A. (eds) Software Engineering Approaches for



Offshore and Outsourced Development. SEAFOOD 2010. Lecture Notes in Business

Information Processing, vol 54. Springer, Berlin, Heidelberg, pp. 37–53.

Lamersdorf, A., Munch, J., Fernandez-del Viso Torre, A., Sánchez, C. R., & Rombach, D. (2010).

Estimating the effort overhead in global software development. Presented at the 5th

International Conference On Global Software Engineering, Princeton New Jersey, pp. 267–

276.

Lamersdorf, A., Munch, J., & Rombach, D. (2009). A survey on the state of the practice in distributed

software development: Criteria for task allocation. International Conference On Global

Software Engineering, Limerick, Ireland, pp. 41–50.

Lane, M. T., & Agerfalk, P. J. (2008). On the suitability of particular software development roles to

global software development. International Conference On Global Software Engineering,

Banglore, India, pp. 3–12.

Larsen, M. H., & Klischewski, R. (2004). Process ownership challenges in it-enabled transformation of

interorganizational business processes. Proceedings of the 37th Annual Hawaii International

Conference on System Sciences, Big Island, Hawaii, p. 11.

Lichtman, M. (2012). Qualitative Research in Education: A User’s Guide: A User’s Guide. Sage

Publications.

Lings, B., Lundell, B., Agerfalk, P. J., & Fitzgerald, B. (2007). A reference model for successful

Distributed Development of Software Systems. International Conference On Global Software

Engineering, Munich, Germany, pp. 130–139.

Mahmood, S., Anwer, S., Niazi, M., Alshayeb, M., & Richardson, I. (2015). Identifying the factors that

influence task allocation in global software development: preliminary results. In Proceedings

of the 19th International Conference on Evaluation and Assessment in Software Engineering,

Nanjing, China, p. 31.



Mahmood, S., Anwer, S., Niazi, M., Alshayeb, M., & Richardson, I. (2017). Key Factors that Influence

Task Allocation in Global Software Development. Information and Software Technology.

Volume 91, pp. 102-122.

Mann-Whitney U Test using SPSS Statistics, Laerd Statistics. (n.d.). Retrieved September 10, 2015,

from https://statistics.laerd.com/spss-tutorials/mann-whitney-u-test-using-spss-

statistics.php

Mann-Whitney U test with unequal sample sizes - Cross Validated. (2012). Retrieved September 10,

2015, from http://stats.stackexchange.com/questions/40342/mann-whitney-u-test-with-

unequal-sample-sizes

Manuel E. Sosa,Steven D. Eppinger,Craig M. Rowles. (2004). The Misalignment of Product

Architecture and Organizational Structure in Complex Product Development. Journal of

Management Science, 50(12), pp. 1674–1689. DOI

http://dx.doi.org/10.1287/mnsc.1040.0289.

Marques, A. B., Carvalho, J. R., Rodrigues, R., Conte, T., Prikladnicki, R., & Marczak, S. (2013). An

ontology for task allocation to teams in distributed software development. Presented at the

International Conference On Global Software Engineering, Bari, Itlay, pp. 21–30.

Mockus, A., & Herbsleb, J. (2001). Challenges of global software development. Proceedings of the

Seventh International Symposium in Software Metrics, London, England, pp. 182–184.

Mockus, A., & Weiss, D. M. (2001). Globalization by chunking: a quantitative approach. IEEE Software,

18(2), pp. 30–37.

Moe, N. B., & Šmite, D. (2008). Understanding a lack of trust in Global Software Teams: a

multiple‐case study. Software Process: Improvement and Practice, 13(3), pp. 217–231.

Morelli, M. D., Eppinger, S. D., & Gulati, R. K. (1995). Predicting technical communication in product

development organizations. Engineering Management, IEEE Transactions On Engineering

Management, 42(3), pp. 215–222.



Mullick, N., Bass, M., Houda, Z., Paulish, P., & Cataldo, M. (2006). Siemens global studio project:

experiences adopting an integrated GSD infrastructure. International Conference on Global

Software Engineering, Florianopolis, Brazil, pp. 203–212.

Münch, J., & Lamersdorf, A. (2009). Systematic task allocation evaluation in distributed software

development. Presented at the OTM Confederated International Conferences" On the Move

to Meaningful Internet Systems, Vilamoura, Portugal, pp. 228–237.

Murgado-Armenteros, E. M., Torres-Ruiz, F. J., & Vega-Zamora, M. (2012). Differences between

online and face to face focus groups, viewed through two approaches. Journal of Theoretical

and Applied Electronic Commerce Research, 7(2), pp. 73–86.

Myers, M. D. (1997). Qualitative research in information systems. Management Information Systems

Quarterly, 21(2), pp. 241–242.

Narendra, N. C., Ponnalagu, K., Zhou, N., & Gifford, W. M. (2012). Towards a formal model for

optimal task-site allocation and effort estimation in global software development Presented

at the SRII Global Conference (SRII), San Jose, CA, USA, pp. 470–477.

Nguyen-Duc, A., & Cruzes, D. S. (2013). Coordination of Software Development Teams across

Organizational Boundary--An Exploratory Study. International Conference On Global Software

Engineering (ICGSE), Bari, Itlay, pp. 216–225.

Nicholson, B., & Sahay, S. (2001). Some political and cultural issues in the globalisation of software

development: case experience from Britain and India. Information and Organization, 11(1),

pp. 25–43.

Noll, J., Beecham, S., & Richardson, I. (2010a). Global software development and collaboration:

barriers and solutions. ACM Inroads, 1(3), pp. 66–78.

Noll, J., Beecham, S., & Richardson, I. (2010b). Global software development and collaboration:

barriers and solutions. ACM Inroads, 1(3), pp. 66–78.



Nordio, M., Estler, H., Meyer, B., Tschannen, J., Ghezzi, C., & Nitto, E. D. (2011). How do distribution

and time zones affect software development? a case study on communication. International

Conference On Global Software Engineering, Helsinki, Finland, pp. 176–184.

O’Conchuir, E., Holmstrom, H., Agerfalk, P. J., & Fitzgerald, B. (2006). Exploring the assumed benefits

of global software development. International Conference On Global Software Engineering,

Florianopolis, Brazil, pp. 159–168).

Olsson, H. H., Conchúir, E. Ó., Ågerfalk, P. J., & Fitzgerald, B. (2008). Two-stage offshoring: An

investigation of the Irish bridge. MIS Quarterly, 32(2), pp. 257–279.

Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules.

Communications of the ACM, 15(12), pp. 1053–1058.

Pitfalls of “don’t know/no opinion” answer options in surveys | CheckMarket. (n.d.). Retrieved

October 13, 2015, from https://www.checkmarket.com/2014/01/pitfalls-dont-know-no-

opinion-answer-option-surveys/

Rainer, A., & Hall, T. (2002). Key success factors for implementing software process improvement: a

maturity-based analysis. Journal of Systems and Software, 62(2), pp. 71–84.

Ralyté, J., Lamielle, X., Arni-Bloch, N., & Léonard, M. (2008). A framework for supporting

management in distributed information systems development. International Conference On

Research Challenges in Information, Fez, Morocco, pp. 381–392.

Reid, D. J., & Reid, F. J. (2005). Online focus groups. International Journal of Market Research, 47(2),

p. 131.

Richardson I., Casey V., Burton J., McCaffery F. (2010) Global Software Engineering: A Software

Process Approach. In: Mistrík I., Grundy J., Hoek A., Whitehead J. (eds) Collaborative Software

Engineering. Springer, Berlin, Heidelberg, pp. 35–56.

Ruano‐Mayoral, M., Casado‐Lumbreras, C., Garbarino‐Alberti, H., & Misra, S. (2014). Methodological

framework for the allocation of work packages in global software development. Journal of

Software: Evolution and Process, 26(5), pp. 476–487.



Ruano-Mayoral, M., Colomo-Palacios, R., Fernández-González, J. M., & García-Crespo, Á. (2011).

Towards a framework for work package allocation for GSD. Presented at the OTM

Confederated International Conferences" On the Move to Meaningful Internet Systems,

Hersonissos, Crete, Greece, pp. 200–207.

Sakthivel, S. (2007). Managing risk in offshore systems development. Communications of the ACM,

50(4), pp. 69–75.

Salger, F. (2009). Software architecture evaluation in global software development projects. In On the

Move to Meaningful Internet Systems: OTM 2009 Workshops, Vilamoura, Portugal, pp. 391–

400.

Schmidt, W. C. (1997). World-Wide Web survey research: Benefits, potential problems, and solutions.

Behavior Research Methods, Instruments, & Computers, 29(2), pp. 274–279.

Setamanit, S., Wakeland, W., & Raffo, D. (2007). Using simulation to evaluate global software

development task allocation strategies. Software Process: Improvement and Practice, 12(5),

pp. 491–503.

Simão Filho, M., Pinheiro, P. R., & Albuquerque, A. B. (2017). Task assignment to distributed teams

based on a qualitative multi-criteria approach. Presented at the Iiberian Conference On

Information Systems and Technologies (CISTI), Lisbon, Portugal, pp. 1-6.

Smite, D., Wohlin, C., Aurum, A., Jabangwe, R., Numminen, E., & Smite, D. (2011). Towards an

Understanding of Sourcing Decisions. In Global Sourcing Workshop, Courchevel,

Sooraj, P., & Mohapatra, P. K. (2008). Developing an inter-site coordination index for global software

development. In IEEE International Conference on Global Software Engineering , Banglore,

India, pp. 119–128.

Stephan, M., & Silvia, M. (2008). A dynamic perspective on next-generation offshoring: The global

sourcing of science and engineering talent. The Academy of Management Perspectives, 22(3),

pp. 35–54.



Tong, A., Sainsbury, P., & Craig, J. (2007). Consolidated criteria for reporting qualitative research

(COREQ): a 32-item checklist for interviews and focus groups. International Journal for

Quality in Health Care, 19(6), pp. 349–357.

Tran, V. N., & Latapie, H. M. (2006). Models for Structuring Teams and Work in globally Collaborative

Projects. International Conference On Engineering Management, Bahia, Brazil, pp. 425–431.

Tripathy, A. ; Eppinger, S.D. (2010). Organizing Global Product Development for Complex Engineered

Systems. Engineering Management, IEEE Transactions, 58(3), pp. 510–529. DOI

https://doi.org/10.1109/TEM.2010.2093531

Turney, L., & Pocknee, C. (2005). Virtual focus groups: New frontiers in research. International Journal

of Qualitative Methods, 4(2), pp. 32–43.

Using SPSS for Ordinally Scaled Data: Mann-Whitney U, Sign Test, and Wilcoxon Tests, tutorial. (n.d.).

Retrieved September 10, 2015, from http://academic.udayton.edu/gregelvers/psy216/spss/

ordinaldata.htm

Vathsavayi, S., Sievi-Korte, O., Koskimies, K., & Systä, K. (2013). Planning global software

development projects using genetic algorithms. Presented at the International Symposium on

Search Based Software Engineering, Petersburg, Russia, pp. 269–274.

Weir, I. (2015). Spearman Rank Correlation (Spearman’s Rho): Definition and How to Calculate it,

Accessed on 2017, Retrieved from https://www.statisticshowto.datasciencecentral.com

/spearman-rank-correlation-definition-calculate/.

Wickramaarachchi, D., & Lai, R. (2013). A method for work distribution in global software

development. Presented at the Advance Computing Conference, Nara Centennial Hall,

Nara, Japan, pp. 1443–1448.

Willcocks, L. P., Oshri, I., Kotlarsky, J., & Rottman, J. W. (2011). Outsourcing and offshoring

engineering projects: understanding the value, sourcing models, and coordination practices.

IEEE Transactions on Engineering Management, 58(4), pp. 706–716.

https://10times.com/japan/conferences



Wiredu, G. O. (2006). A framework for the analysis of coordination in global software development.

In International workshop on Global software development for the practitioner, Shanghai,

China, pp. 38–44.

Wright, K. B. (2005). Researching Internet‐based populations: Advantages and disadvantages of

online survey research, online questionnaire authoring software packages, and web survey

services. Journal of Computer‐Mediated Communication, 10(3), pp. 00–00.

Ye, Y., Nakakoji, K., & Yamamoto, Y. (2007). Reducing the cost of communication and coordination in

distributed software development. In Software Engineering Approaches for Offshore and

Outsourced Development pp. 152–169.



Appendix A: Industrial Questionnaire

The purpose of the survey is to identify the factors considered for task allocation to distributed sites by the

Global Software Development (GSD) industry. By GSD we mean development that spans multiple remote sites

separated by geographical, cultural and temporal distance. We aim to use the result of the survey for designing

and developing a task allocation strategy for GSD industry. The strategy will be based on the finalized list of

factors affecting task allocation decision and the relationship between them. We want to determine the

relationship between task allocation and architecture of the system, task allocation and communication and

coordination needs and architecture of the system and communication and coordination needs.

The survey results will strictly be used for research purpose only. Your responses are confidential and will not be

identified by individual. All responses will be compiled together and analyzed as a group. The survey Comprises

of 18 questions and the duration of the survey is 15 minutes, we appreciate your valuable time and are highly

grateful for taking part in this survey. In case of any issues and concerns please email at

[email protected]

Name of the Organization________________________

Country_______________________________________

1. Your role(s) in the organization

Pro

du

ct

Man

ager/

Pro

ject

Man

ager

Arch

itect

Team

Lead

Dev

elop

er

Sy

stem

An

alyst

Bu

siness

An

alyst

Tester

Req

uirem

ent

En

gin

eer

Qu

ality

Assu

rance

En

gin

eer

Any other role ________,___________________,_____________________

2. Your organizations is a

a. Client

organization

b. Vendor

organization

c. Both

3. How long the organization has

been doing GSD?

a. < 3 Years

b. 3 – 6 Years

c. 6-9 Years

d. 9 + Years

mailto:[email protected]



4. How long you have

been working on GSD

projects?

a. <1 year

b. 2-4 years

c. 5-7 years

d. 8 + years

5. When you were last involved in a Global Software

Development Project?

a. Currently working on one

b. <2-3 years

c. <4-5 years

d. >6 years

6. How many sites are

commonly involved

during GSD as per your

experience?

a. 2-3 sites

b. 4-6 sites

c. 7-9 sites

d. 9+ sites

1. What kind of a relationship your organization has with

distributed remote

sites(keeping in view the below given matrix)?

Country

Company

Same Different

Same (off shoring)

Different

outsourcing (off shore

outsourcing)

a. Off shoring (case when the countries are

Globally Distributed)

b. Offshore outsourcing

2. What factors from the below given list you consider while allocating tasks to distributed sites?

Also rank them in terms of their importance for task allocation decision as perceived by you.

(Please note that the list of factors is not prioritized). You can add more factors at the end

of list and rank them if required.



Ver

y im

po

rtan

t

Imp

orta

nt

Mo

dera

tely im

po

rtan

t

Of little im

po

rtan

ce

Un

imp

orta

nt

Do

no

t kn

ow

1. Labor cost rates at distributed sites

2. Work load at distributed sites

3. Site Characteristics (Analyst capability,

programmer capability, language and tool

experience, personnel continuity, customer

proximity

4. Task- Site Dependencies (experience of type of

application being developed, experience of plate

form)

5. Size of Task

6. Personnel Availability

7. Process Ownership

8. Communication and coordination overhead / cost

between distributed sites

9. Expertise available at sites

10. Component dependencies

11. Time difference between distributed sites

12. Cultural difference between distributed sites

13. Any Other______________________________

3. Which of the following architectural relationship (s) you consider while allocating tasks to

distributed remote sites? (You may choose more than one option from each category if you

consider it during task allocation decision)

A. Category 1: Module View Type

a. Contained relationship between



modules

b. Functional dependency

relationship between modules

c. Specialization relationship

between modules

d. Allowed to use relationship

between modules

e. Any Other ____________________________,

_______________________,______________

B. Category 2: Component and Connector View Type

a. Data read and Data write

relationship between filters

b. Call return relationship between

entities

c. Request response relationship

between client and server.

d. Read and write relationship between

data assessors and data repositories

e. Publish subscribe relationship

between events and subscribers

f. Relationship between concurrent

units.

g. Any Other _________________, _________,_____________

C. Category 3: Allocation View Type

a. Deployment relationship between

software element and physical

entities

b. Allocated relationship between

module and configuration item



c. Containment relationship between

configuration items.

d. Allocated relationship between

module and teams and individuals.

e. Any Other ______________________, _________________________

4. Do you identify the component

dependencies before allocationg to

distributed teams?

a. Yes

b. No

c. Don’t

Know

5. Do you use the identified component

dependencies to acess the communication

and coordination needs?

a. Yes

b. No

c. Don’t Know

6. Do you usually keep these

communication and coordination needs

in mind while allocating tasks to

distributed sites?

a. Yes

b. No

c. Don’t

Know

7. Do you think that distributed teams

communicate apart from the known

component dependencies?

a. Yes

b. No

c. Don’t

Know

8. Do you use any other mechanism to identify the undocumented design interfaces (unknown

component dependency)? (Please write None in case no other mechanism is used for

identification of unknown component dependencies).

___________________________,_____________________________,_________

9. Which of the following communication and coordination dependency link you identify and

consider them important for allocating tasks to distributed sites?



Ver

y im

po

rtan

t

Imp

orta

nt

Mo

dera

tely im

po

rtan

t

Of little im

po

rtan

ce

Un

imp

orta

nt

Do

no

t Kn

ow

1. Dependency between tasks/

activities

2. Dependency between people

3. Dependency between

Resources

4. Temporal dependency between

sites

5. Any other______

10. Which of the following

communication and coordination

requirements you define for the GSD

project?

a. Collaboration Policy

b. Determine the Team

Organization

c. Determine Engineering

Process at Distributed Sites

d. Determine Development

Process at Distributed Sites

e. What Communication

Channels will be used and

When

f. Any Other_________,______

11. Does the change in the frequency of

communication and coordination w.r.t the

software development stages affect task

allocation?

a. Yes

b. No

c. Don’t Know



12. Considering the below given scenario What will happen to the task allocation decision?

Task i is dependant on Task j where Person i is reponsible for performing

Task i and Person j is responsible for performing Task j according to the initial task allocation

decision, the dependency of tasks introduces a coordination dependency between Person i and

Person j, in case of GSD the two individuals are at distributed sites (Site A and Site B). The

change in architecture results in change in coordination path

.

Site A Site B

a. Task allocation will have to be updated according to communication and

coordination needs.

b. No change in task allocation is required

Thank you so much for being a part of this survey. We appreciate your valuable time and response. As part of the

snowballing strategy, kindly recommend three more GSD organizations of your region along with the contact

inforamtion. We assure you that the contact information will only be used for survey correspondance.

Organization 1_________________Contact Person ___________Email________________

Organization 2_________________Contact Person __________Email_________________

Organization 3_________________Contact Person __________Email__________________

Appendix B: Probing Method Cognitive Stage Questions

The questions given in table below consist of questions of comprehension, retrieval, judgement and response of

probing method. These questions were asked for each of the question of the main questionnaire.

Table Appendix-B1: Probing Method Cognitive Stage and Question Mapping

Cognitive Stage

Definition

Question Problems:

Response Errors

Questions

Comprehension Respondents

interpret the

question

Identification of

unknown terms,

ambiguous concepts long

and overly complex

Explain in your own words what the

question is asking?

Are there any unknown or

difficult/ambiguous terms in the

Task Dependency

Task j Task i

Coordination

dependency Performed by Performed by

Person j Person i



Pilot Tested Questionnaire

SURVEY OBJECTIVE: TO IDENTIFY THE FACTORS CONSIDERED FOR TASK

ALLOCATION IN GLOBAL SOFTWARE INDUSTRY

THE PURPOSE OF THE SURVEY IS TO IDENTIFY THE FACTORS CONSIDERED FOR TASK ALLOCATION TO DISTRIBUTED

SITES BY THE GLOBAL SOFTWARE DEVELOPMENT (GSD) INDUSTRY. BY GSD WE MEAN DEVELOPMENT THAT

SPANS MULTIPLE REMOTE SITES SEPARATED BY GEOGRAPHICAL, CULTURAL AND TEMPORAL DISTANCE. WE AIM TO

USE THE RESULT OF THE SURVEY FOR DESIGNING AND DEVELOPING A TASK ALLOCATION STRATEGY FOR GSD

INDUSTRY. THE STRATEGY WILL BE BASED ON THE FINALIZED LIST OF FACTORS AFFECTING TASK ALLOCATION

DECISION AND THE RELATIONSHIP BETWEEN TFHEM. WE WANT TO DETERMINE THE RELATIONSHIP BETWEEN TASK

ALLOCATION AND ARCHITECTURE OF THE SYSTEM, TASK ALLOCATION AND COMMUNICATION AND COORDINATION

NEEDS AND ARCHITECTURE OF THE SYSTEM AND COMMUNICATION AND COORDINATION NEEDS.

THE SURVEY RESULTS WILL STRICTLY BE USED FOR RESEARCH PURPOSE ONLY. YOUR RESPONSES ARE

CONFIDENTIAL AND WILL NOT BE IDENTIFIED BY INDIVIDUAL. ALL RESPONSES WILL BE COMPILED TOGETHER AND

ANALYZED AS A GROUP. THE SURVEY COMPRISES OF 19 QUESTIONS AND THE DURATION OF THE SURVEY IS 15

MINUTES, WE APPRECIATE YOUR VALUABLE TIME AND ARE HIGHLY GRATEFUL FOR TAKING PART IN THIS SURVEY.

IN CASE OF ANY ISSUES AND CONCERNS PLEASE EMAIL AT [email protected]

Name of the Organization__Not to be disclosed __ (please do not refer to the company name in your research

results).

Country_Finland

7. Your role(s) in the organization

question?

Explain in your own words how you

chose a particular answer over another?

Retrieval Respondent search

memory for relevant

information

Recall difficult Was recalling the requested information

easy?

How did you recall the requested

information e.g. did you answer the

question by thinking about the most

recent incident or information?

Judgment Respondent evaluate

or estimate response

Biased or sensitive,

estimation difficulty

How did you arrive at this answer?

Why do you believe this?

How sure are you about the answer to

this question?

Response Respondent provide

information in the

format requested

Incomplete response

option

The provided options are enough?

Is it difficult to state your answer in the

options provided?

Would you prefer to state your answer on

some other scale?




Pro

du

ct

Man

ager/

Pro

ject

Man

ager

Arch

itect

Team

Lead

Dev

eloper

Sy

stem

An

alyst

Bu

siness

An

alyst

Tester

Req

uirem

ent

En

gin

eer

Qu

ality

Assu

rance

En

gin

eer

+ +

Any other role _______________________, _________________________,

_______________________

8. Your organizations is a

d. Client

organization

e. Vendor

organization

f. Both +

9. How long the organization has been

doing GSD?

e. < 3 Years

f. 3 – 6 Years +

g. 6-9 Years

h. 9 + Years

10. How long you have been working

on GSD projects?

e. <1 year +

f. 2-4 years

g. 5-7 years

h. 8 + years

11. When you were last involved in a Global

Software Development Project?

a. <1 year

b. 2-4 years +

c. 5-7 years

d. 8 + years

12. When you were last involved in a

Global Software Development

Project?

e. Currently

working on one

+

f. <2-3 years

g. <4-5 years

h. <6+years

13. How many sites are commonly involved

during GSD as per your experience?

e. 2-3 sites +

f. 4-6 sites

g. 7-9 sites

h. 9+ sites



14. What kind of a relationship your organization has with distributed remote sites (keeping

in view the below given matrix)?

Country

Company

Same Different

Same (off shoring)

Different outsourcing (off shore outsourcing)

a. Off shoring (when the countries are

Globally Distributed)

b. Offshore outsourcing +

15. What factors from the below given list you consider while allocating tasks to distributed

sites? Also rank them in terms of their importance for task allocation decision as

perceived by you. (Please note that the list of factors is not prioritized).

Very

imp

orta

nt

Imp

orta

nt

Mod

erately

imp

orta

nt

Of little im

porta

nce

Un

imp

orta

nt

Do n

ot k

now

14. Labor cost rates at distributed sites +

15. Work load at distributed sites +

16. Site Characteristics (Analyst capability, programmer

capability, language and tool experience, personnel

continuity, customer proximity

+

17. Task- Site Dependencies (experience of type of

application being developed, experience of plate form)

+

18. Size of Task +

19. Personnel Availability +

20. Process Ownership +

21. Communication and coordination overhead / cost

between distributed sites

+

22. Expertise available at sites +

23. Component dependencies +

24. Time difference between distributed sites +

25. Cultural difference between distributed sites +

26. Any Other________________________________



16. Which of the following architectural relationship (s) you consider while allocating tasks to

distributed remote sites? (You may choose more than one option from each category if

you consider it during task allocation decision)

D. Category 1: Module View Type

f. Contained relationship between

modules

+

g. Functional dependency relationship

between modules

+

h. Specialization relationship between

modules

+

i. Allowed to use relationship between

modules

+

j. Any Other ____________________________,

_______________________,______________

E. Category 2: Component and Connector View Type

h. Data read and Data write relationship

between filters

i. Call return relationship between entities

j. Request response relationship between

client and server.

+

k. Read and write relationship between data

assessors and data repositories

l. Publish subscribe relationship between

events and subscribers

+

m. Relationship between concurrent units.

n. Any Other __________________________, _________________________,____

F. Category 3: Allocation View Type

f. Deployment relationship between

software element and physical entities

+

g. Allocated relationship between module

and configuration item

h. Containment relationship between

configuration items.

i. Allocated relationship between module

and teams and individuals.

j. Any Other ______________________, _________________________, ______



17. Do you identify the component dependencies

before allocationg to distributed teams?

d. Yes +

e. No

f. Don’t Know

18. Do you use the identified component

dependencies to acess the communication

and coordination needs?

d. Yes +

e. No

f. Don’t Know

19. Do you usually keep these communication

and coordination needs in mind while

allocating tasks to distributed sites?

d. Yes +

e. No

f. Don’t Know

20. Do you think that distributed teams

communicate apart from the known

component dependencies?

d. Yes +

e. No

f. Don’t Know

21. Do you use any other mechanism to identify the undocumented design interfaces (unknown

component dependency)? (Please write None in case no other mechanism is used for

identification of unknown component dependencies).

None

22. Which of the following communication and coordination dependency link you identify

and consider them important for allocating tasks to distributed sites?

Very

imp

orta

nt

Imp

orta

nt

Mod

erately

imp

orta

nt

Of little im

porta

nce

Un

imp

orta

nt

Do n

ot K

now

6. Dependency between tasks/

activities

+

7. Dependency between people +

8. Dependency between Resources +

9. Temporal dependency between

sites

+

10. Any other______



23. Which of the following communication

and coordination requirements you define

for the GSD project?

g. Collaboration Policy +

h. Determine the Team

Organization

i. Determine Engineering

Process at Distributed

Sites

j. Determine Development

Process at Distributed

Sites

k. What Communication

Channels will be used and

When

+

l. Any

Other_________,____________

24. Does the change in the frequency of

communication and coordination w.r.t

the software development stages affect

task allocation?

d. Yes +

e. No

f. Don’t Know

25. Considering the below given scenario What will happen to the task allocation decision?

Task i is dependant on Task j where Person i is reponsible for performing Task i and

Person j is responsible for performing Task j according to the initial task allocation

decision, the dependency of tasks introduces a coordination dependency between Person

i and Person j, in case of GSD the two individuals are at distributed sites (Site A and Site B).

The change in architecture results in change in coordination path

.

Site A Site B

c. Task allocation will have to be updated according to communication and

coordination needs.

d. No change in task allocation is required +

Appendix C: Interview Protocol

Greetings from Pakistan.

My name is Salma Imtiaz and I am doing my PhD research in the field of Global Software Development. Global

Software Development (GSD) is the type of software development where multiple teams at distributed sites work

on a system/project. These teams are separated not only by geographic distance but also by cultural and

temporal distance. Allocation of task related to a development project to the team members at these distributed

Performed by Performed by

Person i Person j

Task i Task j

Coordination

dependency

Task Dependency



sites is a critical activity which affects the project execution and success if not done properly. We aim to identify

the factors which affect the decision of task allocation to distributed sites in a GSD context. We also intend to

determine the relationship of task distribution with communication and coordination needs and architecture of

the system.

The interview is targeting the practitioners involved in GSD for the responses. We want to assure that the

respondents’ information and responses will not be disclosed. The information collected will strictly be used for

research purpose only, and will be analysed and reported as an aggregate. In case of any questions please contact

me at: [email protected].

Your response is highly appreciated and will be of great help in our research. Your input will help us in

developing a task allocation framework which would be beneficial for the practitioners. It will help in bridging a

huge gap by specifying steps on how task allocation should be performed for effective Global Software

Development.

Table Appendix-C1: Interview Protocol

Suitable

Date:

Suitable

Time:

Preferred

Interview

mode:

Skype By Call Face to face

Objective of

Interview:

1. To determine the role of various factors during Task Allocation in a GSD context.

Relationship of Task Allocation activity with Off shoring decision.

2. To determine inter-relationships between factors, the process used for task allocation

during GSD, inputs, outputs of process along with roles involved in Task Allocation.

3. To determine the role of communication and coordination needs and architecture

during task allocation.

Interviewee Profiling

Name of Interviewee:

Role/Designation of Interviewee:

Q1: How long you have been working in GSD?




Organization Profiling

Name of Organization:

Size of Organization (specify in number of employees):

Number of sites usually work distributed to:

How long the organization has been doing GSD?

Do you perform GSD on regular basis?

What type of GSD is usually performed by the organization i.e. off shoring or off shore outsourcing etc?

Type of Projects usually developed globally?

Software development Methodology used during GSD?



Section 1:

OBECTIVE: Understanding TA in context of objective of GSD.

Question Follow up Questions Prospective Follow Up

Questions

Q1: As an organization what is the reason

you go for GSD?

Q2: What you want to achieve by GSD?

Q1.1: Is it part of your strategic

planning policy?

Q2.1: Do you keep objective of

GSD in mind while allocating

tasks to distributed sites?

Q2.1.1 Does task

allocation change with

change in objective of

doing GSD?

Section 2:

OBJECTIVE: Process of TA, Who is involved in the TA decision, when it is performed. Inputs to TA activity

and Outputs?

Q3: What is the process of Task Allocation in

your organization?

Q4: Who does task allocation in your

organization?

Q5: When is TA performed, Can you specify

with respect to SDLC?

Q3.1: What information is

required for Task Allocation?

Q4.1: Do they need feedback

from any other role?

Q4.2: Who finally approves the

task allocation?

Q5.1: Is it a onetime activity?

Q3.1.1: Are any

documents used for Task

Allocation?

Q4.2.1: Who can change

task allocation if required?

Q5.1.1: If not can you

specify why or when

reallocation is required?

Q5.1.1.1 How re



Q6: Do you save Task Allocation decisions?

Q7: What is the duration of Task Allocation

activity? Can you specify in days or hours?

Q6.1: What documents are

produced as a result of TA?

allocation is done?

Section 3

OBJECTIVE: To determine the most important factors for Task Allocation in GSD specifically clarifying the

role of labour cost, expertise, temporal and cultural difference.

Q8: What are the three most important factors

for Task Allocation during Global Software

Development?

Q9: How you trade off between factors?

Q8.1: what about time

difference and cultural

difference between sites?

Q8.2: Will these be the top most

important factors in all

situations?

Q9.1: Do you record the trade

off decisions for future use?

Q8.1.1: would they remain

same for all projects?

Q8.1.2: Can you think of

any other factor which

should be considered

during TA?

Q8.2.1: If not what other

factors would be

important and in what

situation?

Section 4

OBJECTIVE: To understand what architectural information is used for TA and what architectural

documents/information produced.

Q10: Is input taken from

architect or architecture

document?

Q10.1: If yes what architectural

information you base your TA

on?

Q10.1.1: What if the

architecture of the system

changes? Do you update



Q11: Do you document you

Task Allocation in form of

some architectural view?

Q12: What other information

does the product architecture

hold?

Q11.1: Is this allocation

information associated with

other architectural information?

Q11.2: Who creates and updates

this allocation information?

Q12.1: What about the

communication and

coordination needs of the

organization?

Q12.2: Do you update

architecture in case of change of

communication and

coordination needs?

TA?

Section 5

OBJECTIVE: To understand the role of communication and coordination needs during TA specifically w.r.t

temporal and cultural distance.

Q13: What are the factors

that affect communication

and coordination during

GSD?

Q13.1: Do you consider these

factors before Task Allocation?

Q13.1.1: If not how you

handle them?

Appendix D: Interview Transcripts of All Interviewees

Interview 1:

Suitable Date: 25th June 2015

Suitable Time: 1430

Preferred Interview mode: Face to Face




Name of Interviewee: (Not to be Disclosed)

Role/Designation of Interviewee: Product Manager – Information Management

How long you have been working in GSD? Since 2000


Name of Organization: (Not to be Disclosed)

Size of Organization (specify in number of employees): 500+

Number of sites usually work distributed to: 8

How long the organization has been doing GSD? Since 2001

Do you perform GSD on regular basis? Yes

What type of GSD is usually performed by the organization i.e. off shoring or off shore outsourcing etc?:Both

Type of Projects usually developed globally?:Petroleum_Exploration and Production Software Products

Software Development Methodology usually followed in the organization for software development? Agile –

Scrum Framework and traditional

Section 1:

Question

Q1: As an organization what is the reason you go for GSD? (strategic planning or short term goal)

The organization gives IT services to petroleum industry. Founded in 1994 2001 The organization and

another organization association. The other organization software developing cell(Landmark softwares)

bought 50% shares of the organization Pakistan had computer graduates who are available at low labour

cost, along with other countries such as India, Vietnam, china, Romania (competitors of the organization).

Now the other organization distribute work to them as well. But now the organization has developed a

skill set of developing oil and gas softwares and the organization started developing software of his

own.2010 acquired the organization product geographic.

Two work Outsourcing, the other organization assign work to the organization in 2010 we acquired

Geographic’s product, R&D team in Islamabad but some developer in US and Croatia too, Product and

program managers at distributed locations.(major factor skill set and labour cost)

Requirements defined by product managers in USA by interaction with client and most of the clients of

geographics in north America. Development done here in Islamabad.

Q1.1: Is it part of your strategic planning policy?

Yes (major offices opened in different locations because of these reasons)



Q2: What you want to achieve by GSD? (objective of GSD e.g. quality, short time etc)

24/7 development, Reduce cost, Sales, marketing and management etc in different locations where they

can acquire business and take new ventures.

Q2.1: Do you keep objective of GSD in mind while allocating tasks to distributed sites?

Yes, work assigned in such a way that one site delivers work to the next site.

Q2.1.1 Does task allocation change with change in objective of doing GSD?

Section 2:

Q3: What is the process of Task Allocation in your organization?

Product managers responsible identifying requirements of product based on e.g.

1. Some companies have 100 licenses, other has 400 licenses, so 400 license companies more important, so

their problems important to us, we prioritize on its basis.

2. Requirement made by product managers, which requirements should be done in this release, program

manager tell how many releases per year based on what new features we should bring to be active in

market, based on what features lacking in other products so we should bring.

3. CEO defines sometime that we need these much releases to look aggressive in market or give a features

in 2 years but it should be very different and new etc.

Now if 8 months how many requirements can be completed in 8 months. Requirements given to R&D

which have team leads etc. project manager concerned with assignment of task to people. Sprint starts

then team picks task themselves keeping in view capacity and velocity of team. Microsoft team foundation

server so collaboration across different remote teams very easy. Expertise seen of person before assigning

task. Everyone knows about the expertise of people in team.

Q4: Who does task allocation in your organization?

Team leads or development leads they assign if not picked, we use them in agile as well. Otherwise agile

doesn’t have concept of team lead etc.

Q5: When is TA performed, Can you specify with respect to SDLC?

Release planning Meeting: tentative time and scope of release, Second step who will do what iteration

planning meeting. Phase gate meetings in traditional development, requirement analysis, then design and

then architecture, task allocation after requirement analysis.


Team foundation server everything entered here in case of agile, Artefacts such as project plan etc.



Q7: What is the duration of Task Allocation activity? Can you specify in days or hours?

Within hours, almost one day

Section 3

Q8: What are the three most important factors for Task Allocation during Global Software Development?

Trained resources (people of that domain, skilled resources of that domain), Requirements what to

deliver, Time (when to give certain requirements), workload


Domain wise teams done by the other organization so all work related to a particular domain comes to the

organization data management work all comes here. Then scope comes if scope cannot be handled by the

organization then they move to other companies. So it’s a decision making process. Q8.1: what about (

See from list)….specifically ask about time and cultural difference

Time zone: Not an issue as develops come to match time of remote site, flexi hours of the organization, you

can come at times according to your meetings.

Culture: not much of an issue, language etc Pakistani v good at it now. Problems can come due to selection

of words. Also due to work ethics but we adapt as company mature.

University education has improved. Social media has also helped us in being more aware of different

people languages, made you more confident in dealing, adaptive.

Holidays can be an issue. Usually no

Section 5

Q13: Is input taken from architect or architecture document?

Yes, architecture team taken on board

Section 6

Q11: What are the factors that affect communication and coordination during GSD? ( temporal distance and

cultural distance)

Team foundation server as used for communication.

Q11.1: Do you consider these factors before Task Allocation?

Q11.1.1: If not how you handle them? (Use of strategies to handle time and cultural difference)

Flexi hours to handle time zone difference, Travelling to reduce cultural distance



Interview 2:

Suitable Date: 1st June 2015

Suitable Time: 4 Pm Pakistan time, Blue Area

Preferred Interview mode: face to face



Role/Designation of Interviewee: Project Manager

Q1: How long you have been working in GSD?: 4 years this company, 5 years previous


Name of Organization:(Not to be Disclosed)

Size of Organization (specify in number of employees): Around 2700, 950 in Pakistan

Number of sites usually work distributed to: 90% 3, in some cases 4-5

How long the organization has been doing GSD?: 5 and half years

Do you perform GSD on regular basis?: Yes

What type of GSD is usually performed by the organization i.e. off shoring or off shore outsourcing etc?:

Offshoring only

Type of Projects usually developed globally?: Financial data gathering and analysis applications, non

financial data gathering applications, customer facing software, Data acquiring applications, web

applications.

Section 1:

Question


Cost ,24/7 development,For backup


Quality, Timeliness




Yes


Task allocation will compliment it but they are high level goals of company. Task allocation is operational

decision

Section 2:


We do agile, scrum, list of projects , then we have guidelines as in which teams from which area as our

team of financials so all financial related projects or changes come to us, either we pick or they are

given..Both ways it can happen. But decided in a meeting, with consensus, area from area and capacity

seen. Project divided in user stories which are put in back log and prioritized. Teams start picking tasks

from top. Each team has velocity. 4 week sprint done. Amount of work done by each team in these 4 weeks

is velocity. Capacity of team seen from previous experience if our team usually delivers 60-65 story points

per sprint this is our capacity keeping that the team is same.

Projects shuffled keeping in view capacity, if a team busy we can take a less priority work from them and

give this one.


In a meeting, no final authority, self organizing and self motivating teams


Planning after requirement elicitation and analysis


Team foundation server a tool all things save in it. Everything saved from capacity, national holidays etc


2-4 hours

Q3.1: What information is required for Task Allocation?

Decided in a meeting head by PMO, everyone present, video conferencing done, screen sharing by one.

Known as grooming meeting, decided then and there. Pick user stories identify tasks for it and decide on

who will pick by voluntarily basis, we try to pick project manager of same time zone ,but still if he wants

decided as consensus Specifications, mockups

Q5.1: Is it a one time activity?

Will remain same what is planned delivered



Q5.1.1.1 How re allocation is done?

One developer sparred only who works on changes

Section 3


All people in same Time zone, Expertise, Availability, Willingness to work, backup


In meeting decided via consensus. No pattern, vary from situation to situation, e.g. in case of expertise and

capacity we can see which to choose maybe low priority work taken from that site which has expertise.

Q8.1: what about ( See from list)….specifically ask about time and cultural difference Culture not

an issue, language not an issue as official language english . Usually things adapted.

Q8.1.2: Can you think of any other factor which should be considered during TA? (political reason, trust, prior

relationship etc)

No

Section 4

Q10: What are the three main factors considered while deciding to Offshore?

Cost , backup support offices, 24/7 development.

Q11: Who decides to offshore?

Its company design decided on high level. Predefined, like ceoetc

Q12: When is decision to offshore taken with respect to SDLC?

Section 5


If old projects such documents already exist so we give those, In case of new projects Architect involved in

teams

Q14: Do you document you Task Allocation? (Allocated View)

Section 6

Q11: What are the factors that affect communication and coordination during GSD?

Time, language




No.

Q11.1.1: If not how you handle them?

Things divided in Small tasks so it can be handled, the impact can be handled as well.

Interview 3:

Suitable Date: 27th June 2015

Suitable Time: 11:00 AM Eastern Standard Time (EST), 8 pm Pakistan time.

Preferred Interview mode: Skype


Name of Interviewee:(Not to be Disclosed)

Role/Designation of Interviewee: CEO, Sr. Process and Technology Strategist-Leader

Q1: How long you have been working in GSD? 15+ years



Size of Organization (specify in number of employees): 10 to 19 FTE


How long the organization has been doing GSD? 15+ years


What type of GSD is usually performed by the organization i.e. off shoring or off shore outsourcing etc?: Both

Type of Projects usually developed globally? Business Process Automation

Software Development Methodology usually followed in the organization for software development?

Agile(scrum) as well as traditional software development methodology

Section 1:


For a symbiotic relationship, if we can’t do it in-house efficiently or effectively then we outsource. As we

may not have the skill set or if we have the skill set then they may be busy in other projects not available

due to workload.




Yes (but we do within reason) it be seem good to outsource but when we send project offshore you maybe

spending more money for quality and logistics then if developed locally.


Objectives of project tied to objectives of the organization, if offshore component cannot help us achieve

the strategic objectives by meeting the project objectives we don’t’ offshore.


We use Methodology model has two components

Project Component:

Yes, build on objectives, tasks are decided and then resources, who is going to do it, what are the

deliverables.

Methodology Component

Decision about each task:

How the task is going to be done, what references they will be using, what frames they going to be using

Example:

Improve customer experience (strategic objective) project part of program. The project maybe self

serving application where customers an login and do what they want so this project helping achieve

customer experience, all project given to Singapore as we first identify what are the core competency

needed,(skill set required). We ask questions and who answers best we give to them. The methodology

they use, what is their security policy. See their culture, We meet face to face for a connection. Liaison who

has done software development in US so culture was compatible as well.

Section 2:


When you outsource, you take organizations that have processes which are standardized. We make the

outsourcing person part of our project planning effort (one on one meeting). Define work in detail. We

identify the work packages. We use earned value approach, assign cost to these packages, when each task

has to be done. so the people when they go to their respective sites they know exactly when each work has

to be done, so it’s a productive exercise this way as they were involved in planning now they own t he work

and work towards its completion. They are also involved in requirement gathering and architecture and

data architecture etc. we do these meetings quarterly, first

If it is done by different people it is done by different people in same site, not distributed among sites. 4

different countries mean 4 different cultures, languages, time zones, different sites means different



principals, policies, processes, frameworks, infrastructure, systems, organizational structure, culture

ethics and behaviour, people and skills, applications, difficult to manage.


Program manager (benefit realization, choose the site),Project manager(day to day operations)


Engineering is iterative, There constant feedback, as you find something new each time. You have to

freeze it at some point so not exactly one point.


Yes we save lessons learnt

Q7: What is the duration of Task Allocation activity? Can you specify in days or hours? Q3.1: What

information is required for Task Allocation?

Architecture is required before task allocation, slices of information.

Business architecture, information systems architecture, data architecture and application architecture,

then technology architecture but we do it for a slice. Send it for a slice. If you don’t do this, this is what

happens

Once I was demonstrating some functionality, it ran all ok, everyone was so excited so they called in their

colleagues to see the Same functionality broke. as someone was testing some stuff in test environment,

there is a process to promote some functionality in the environment. The testing technology it is very

sensitive, when they move this component in due to lack of integration testing it broke, so everyone should

know about interfaces between components.

Architecture gives you logical approach to build the system. We don’t separate it among sites as it would

become coordination nightmare.

Q4.1: Do they need feedback from any other role? If architect skip to section 5 question 13.1

Yes, we ask questions from the outsourcing people, people who will actually be involved, how would you

go about building a project plan, we would look for is how they plan it. Then you can estimate time and

cost as now you have true collaboration. Do you know how to facilitate or engage the team? What will be

the change process?

So program manager does task allocation with project manager who also involves the the team as well.

Q4.2: Who finally approves the task allocation?

Program manager does it by involving project manager who involves his team as well.




No iterative.

Q5.1.1: If not can you specify why or when reallocation is required?

Example is a task allocated to a resource but he was working slow, but you have a schedule to meet. You

have two options either assign it to a new person who can communicate with the old one to understand, or

you can leave it with the old person as now you will have administrative overhead so you have to a have

decision making process build in your working that is good governance.

Section 3


Culture

Processes they have in place

Skill and core competencies of the site.


You want to work with companies where the delta is minimized. The way that you do things the way they

do things you want minimal differences.

Pior relationship site wins over labour cost as the grass the not always greener on the other site.

You only leave a site if Very difficult to work with

Cost is increased (due to rework or communication and coordination overhead)

Confidence level in them is decreased

Q8.1: what about ( See from list)….specifically ask about time and cultural difference

Labour cost is why we offshore or outsource it’s the driving point. but labour cost is something which can

be trade off as if you have a project that you plan to release by certain date and if not released no revenue

so it gives a negative image to your company. If you are a publically held company it would give a negative

commendation to wall street since you did not meet your revenue projections.

Try to use time zone to our benefit by using 24/7 model of development

Q8.2: Will these be the top most important factors in all situations?

You start with these three then add to them the 8 enablers I talked about you thing about all of them

Q7.1: Do you record the trade off decisions for future use? Q8.1.1: would they remain same for all projects?

Vary from project to project




relationship etc)

Trust is major factor

Section 5


Yes program manager makes and updates it. Made in public as well as commercial sector

Q15: What other information does the product architecture hold? (communication and coordination structure of

the distributed team)

Q13.1: If yes what architectural information you base your TA on?

Work packages are modules so we allocate to single site or different sites. But in case of different sites you

need a relationship manager who coordinates between the sites. We stay away from this model.

We offshore to multiple sites in same country

We offshored to india, Singapore, china , UK but offshore sites were developing backups, sort of load

balancing. But building application we want to minimize number of sites as much as possible.

More people you have different culture, labour cost goes out the window.

Work packages interdependent never allocated to different sites due to communication and coordination.

Q13.1.1: What if the architecture of the system changes? Do you update TA?

Yes, all depends it goes back to architecture review board, they decide.

Section 6

Q11: What are the factors that affect communication and coordination during GSD? (temporal distance and

cultural distance)

Recently working with a company sat with them know their culture, we started with the problems they

have, you have to make a physical one on one connection as it breaks the communication barrier. It is 4c

Connection then communication

Communication then coordination

Coordination then collaboration

If it is not done like this then you don’t get the 4C



The enablers affect the communication and coordination as well as they makes the culture of organization.

They are enablers of governance


Liaison person to handle culture

Major insurance company, we redesigning 400 million dollar project. What architecture consisted off?

Development in UK only but it impacted the globe. Rapid analysis design session where people from South

Africa, Canada, UK, other parts of USA.

Rapid application design process. We built the Process model , data model, architectural package, by

having the representative it broke down cultural barrier, so they went back to build in UK so there were

hiccups but easy to correct.

Interview 4:

Suitable Date: 22nd june

Suitable Time: -9 pm




Role/Designation of Interviewee: Independent consultant/ PM

How long you have been working in GSD? 9 years



Size of Organization (specify in number of employees): overall 70-80k

Number of sites usually work distributed to: India and china

How long the organization has been doing GSD? Way long

Do you perform GSD on regular basis? yes

What type of GSD is usually performed by the organization i.e. off shoring or off shore outsourcing etc?: Both

Type of Projects usually developed globally?:Various IT Projects

Software Development Methodology: Agile(Scrum)/Waterfall/Waterscrum



Section 1:

Question

Q1: As an organization what is the reason you go for GSD, what you want to achieve? (strategic planning or

short term goal)

It depends on organization, Microsoft access to people all around the world; cost is one factor as

organizations like Microsoft cost is cheap as compared to hiring people onsite.

Labour Cost


Yes

Section 2:


Depends. We have people in china and India, we assign work to people based on whose available, second is

if similar project is done by that site or not (prior experience). If Chinese site has already worked on such

project, it is given to them else we find the next suitable candidate based on skill set.

Language is also a barrier in case of some sites e.g. china so in case where a lot of communication is

required project not assigned to china but in case where specifications final and only development

required we can assign to china e.g. once for a project in china I talked for two hours and after two hours

nobody had a clue what I talked about. Now we have interpret

I do most of the design, talk to customer until they are happy then send this design document to the other

site i.e. either china or India. Building software, testing and deployment goes offshore.

We have technical program manager at each site, who communicate among themselves to get the work

done


Project Manager

Technical Project Manager/ Technical Program Manager


Kind of project if big project you do documentation, for small projects not much documentation.


Few minutes



Setting up a division is different task. Then later on its easy.


Business requirement documents by customers

FRD document Functional requirement Document. Features, ways how things will be handled

architecture related information, customer signs it off. SOW given to customer on basis of it. Discovery

and Analysis phase of waterfall, once it is approved, this document given to offshore team.


No


Project manager with consultation with program manager

Q3.1.1: Are any documents used for Task Allocation?

If architecture documents skip to section 5 question 13.1

CRM project. It’s a tool by Microsoft, its a package application. Very specific to how the system

information will be documented e.g. in case of CRM concept of business units, security role, users all

entities and tables need to be defined in detail and then how they will be related one to one , one to many

etc

But all project goes to one site as otherwise communication and coordination very difficult due to time

zone differences, it is going to be a mess and nightmare. Don’t outsource to regions


Couple of times, one experience, working with india developers not good. Not easy to reallocate project

but we escalated it to my manager and then we shifted to china…took it three months. A lot of escalations.

Section 3


Creating a site:

Political factors in there, clearance from LCA, people who will help us find vendor, insurance system if

some thing goes wrong, issues with government

Utilizing Site:

Availability of site



Skill set for the project (if project about a technology then who knows it)

Who I am comfortable working with. Prior experience or relationship


Depends the way it is done manager chooses the site, he creates sites, for him cost is biggest factor for me

people the biggest factor as I am responsible for delivery. I will focus on capability, who knows technology.

Usually cost remain same for off shoring1. Small differences don’t matter. People bargain and set rates.

If the project is very critical I would make sure project doesn’t fail. Credibility matters a lot. Whether you

can deliver project.If prior experience very good project given without much thought to cost.

Modules allocated once but it was a failure Have competitive vendor in china and India, the Indian folks

were not sharing information with china because they wanted to keep information with them, for me to

give information from Indian to china very difficult. Chinese they record information and listen to it again

and again .time got wasted so much. Internal politics two vendors very difficult. Problem of one module

affecting other module no one owns it.


Time zone major factor, as it is very difficult to manage multiple time zones, communication and

coordination a major issue.

Multiple cultures, different work habits very difficult to manage, Indians come after 11:30 they have tea ,

fun and a lot of stuff and vanish at 5 or 6 I don’t prefer to give work to them. China cannot understand

language, they are ethical good people. Emails are such that it gives you a laugh.


Yes usually

Section 6


cultural distance)

Time and culture yes


Yes Never wish to work again with two regions with different time zone as it is very difficult.


Strategies such as interpreters and email them as written never call people with language issue.



Interview 5:

Suitable Date: Dec. 21 or 22, or Jan. 4+

Suitable Time: Daytime EST

Preferred Interview mode: Skype (text, not video) By Call Face to face



Role/Designation of Interviewee:Lead Principal Researcher

Q1: How long you have been working in GSD?Over 20 years



Size of Organization (specify in number of employees): (at your site, along with overall count)80, overall count

170000

Number of sites usually work distributed to:1-4

How long the organization has been doing GSD?Longer than I have been there (14 years)

Do you perform GSD on regular basis?Yes, most of my projects have been globally distributed

What type of GSD is usually performed by the organization i.e. off shoring or off shore outsourcing etc? (off

shoring when work is allocated to same company’s offices in different locations whereas in off shore outsourcing

work is allocated to different company’s in different locations)

Offshoring – although we don’t use that term for this meaning


Most R&D projects, including software research, are global.

Software Development Methodology usually followed in the organization for software development?

Mostly agile (scrum)

Section 1:

Q1: As an organization what is the reason you go for GSD?

Software research is globally distributed across 5 different geographic locations, in order to have a center

of competence near the major global markets and business units of the company. For reasons of ‘critical



mass’, each center has a specialty (e.g. HMI, performance). Projects tend to be small and when a project

needs a special competence, it is staffed with people from the centers that have the best competences.


The best possible: project results, alignment of assignments with skills and people’s interests, and

coordination with the global business units we collaborate with.


Yes, the global footprint and agreements on which centres will host which specialties is definitely part of

the strategic plan for software research.


Not sure I understand the question, but when tasks are allocated, ability to work independently (or with

maximum time zone overlap with someone else) is always considered. This is traded off vs. the key

competences – what the project needs, what people are good at, and what they are interested in working

on.


Not clear on this question – I do not think our GSD objectives have changed substantially over time.

Section 2:


It varies by project. Generally it’s a combination of volunteerism (in agile projects), consensus among the

core team on who will lead which “work packages” or epics of a project, and assignment of tasks to team

members by the project leader.


Project leaders and/or team members


Work package or epic ownership is agreed during the early planning stages. On scrum projects, task

assignments are agreed during sprint planning sessions (conducted via phone/webex). Tentative

assignments of tasks by project leaders are sometimes made during backlog grooming by the product

owner/project leader (it’s generally the same person on our research projects) in the agile project

management tool.




Allocations for individual tasks are captured in the agile project management tool (e.g. Pivotal Tracker).

Rationale for task allocations, at the high (epic, work package) level is captured in a conventional Project

Plan or Technical Plan in a section which maps the competences needed by the project to the competences

of the assigned staff.


Initial high-level planning probably takes 4-8 hours. Detailed task allocation is done during backlog

grooming and sprint planning, which takes 1-4 hours per sprint (typically 2 weeks) Q3.1: What

information is required for Task Allocation?

Competences needed for task, rough estimate of task effort, availability of each person with suitable

competence (how much work is already “on their plate”, and any planned absences).

Q4.1: Do they need feedback from any other role?

Generally no, although on occasion a higher level manager will comment on assignments.


Core team members and project leader

Q5.1: Is it a onetime activity?

No, new and revised task assignments are addressed during regular sprint planning (typically every 2

weeks)

Q6.1: What documents are produced as a result of TA?

See Q3.1.1: Are any documents used for Task Allocation?


Minimal documents – Project Plan/Technical Plan at epic or work package level. Agile project

management tool is used at detail level for defining tasks, estimating effort, and allocating epics and

stories to team members.

Q4.2.1: Who can change task allocation if required?

Generally the project leader, although it would probably be ok in most cases if two team members agreed

among themselves to swap some tasks.




Reallocation is required when something changes – e.g. task effort becomes much bigger than its original

estimate due to realized risks or technical issues, or when someone becomes much more or much less

available than planned, or when task priorities or deadlines change based on stakeholder inputs.


The same way allocation is done – if the team member or project leader feels that assignment changes are

needed due to schedule or availability or other reasons, it’s discussed during sprint planning and adjusted

then as needed.

Section 3


They vary but in general: expertise, temporal overlap, workload balancing.

Cost can be a lower-importance factor in deciding how to staff a project’s core team, but it does not drive

allocations of tasks among the project core team members.

Q9: How you trade-off between factors?

Once the overall staffing of the project is defined, workload balancing is critical. Task assignments depend

on the project and work package and how big the learning curve is likely to be for having someone with

less expertise/competence pick up specific tasks instead of having the most expert person do it.

If a serious gap is identified between the amount of work for a certain competence vs. the staffing level

with that competence, then the overall project staffing may be revisited. Temporal overlap is generally

maximized wherever possible, with use of tools for collaboration to support effective asynchronous work.

Q8.1:what about time difference and cultural difference between sites?

Time differences are a very important issue and can definitely impact task allocations.

Cultural differences are recognized as important, but are accommodated via education and training and

generally do not ‘drive’ task allocations.


In most cases, team members always have at least 1 hour of temporal overlap (with some flexibility on the

part of team members to start or finish their workdays a little earlier or later). If that were not the case,

then decoupling the task assignments might get higher priority consideration.

Q9.1: Do you record the trade-off decisions for future use?

Generally, no. They might come up in a project retrospective, and be documented there,especially if the

trade-offs made did not work out well.

Q8.1.1: would they remain same for all projects?



The factors can vary in importance on projects. I suppose there might be some cases where cultural or

cost factors are in the top 3, but I haven’t seen it in the projects I have managed.

Q8.1.2: Can you think of any other factor which should be considered during TA?

A ‘soft’ factor which can impact task allocation is personality and how aggressively or cautiously a team

member handles technical risks. This is true whether the project is globally distributed or not and it may

ot be as simple as a stereotypical ‘cultural’ factor. Everyone is different.

You did not explicitly ask about this, and it is not the same as cultural differences. But differences in

language competences can impact task allocations, e.g. having a native English speaker/writer review/edit

a deliverable document. This is true even in cases where the project is not globally distributed, since many

people who work in our English-language based research centres are not native speakers of English.

(English is the official global working language of the company.)

Q8.2.1: If not what other factors would be important and in what situation?

Answered under 8.2

Section 4


Yes, at a high level, when work packages are structured and epics are defined. Often, our software

research project tasks include developing the architecture, and the architecture generally emerges and

evolves throughout the project.

Q11: Do you document your Task Allocation in form of some architectural view?

Generally, no.

Q12: What other information does the product architecture hold?

Usually, an overview, various diagrams, rationale, specific architecture decisions on 4 levels with

rationale, references on selected technologies or to technology evaluations, etc.


Architecture tends to be decoupled at the work package level, and/or there is one work package which is

for the overall architecture. People with strong architecture competence are generally assigned to the

tasks of the overall architecture WP. These people are also generally assigned as reviewers on the

architectures of the component WPs.

Architecture decisions on technologies are closely coupled to team competences in the candidate

technologies.

Q11.1: Is this allocation information associated with other architectural information?



Formally associated, no, other than in the Technical Plan.

Q11.2: Who creates and updates this allocation information?

Project leader

Q12.1: What about the communication and coordination needs of the organization?

Communication and coordination needs are identified and strategy is documented in the Project Plan.

Q12.2: Do you update architecture in case of change of communication and coordination needs?

Indirectly, perhaps. Key communication or coordination needs should be captured in the architectural

drivers and considered accordingly.

In general we do consider alignment of architecture structure with organizational structure (there are

papers on this if you are interested). We also realize that in a dynamic organization, it’s not always

desirable to revamp the architecture every time the organization changes. So flexibility is often an

important architectural goal.

Q10.1.1: What if the architecture of the system changes? Do you update TA?

Task assignments evolve as architecture evolves, yes. If a new architecture decision involves selection of a

technology that the current team does not yet have sufficient competence on, then definitely the task

allocations would change, and the overall staffing of the project might change as well, or new training

tasks might be added.

Section 5


This is a very broad question and there are many factors that affect GSD communication and

coordination – there are many papers on it. I’ll forward one we published in SEAFOOD 2010.

At a high level: soft factors like trust are critical, as are harder factors like communication skills.


Yes

Q13.1.1: If not how you handle them?

Independent of task allocation, we also look for ways to improve or mitigate the factors we noted in the

SEAFOOD 2010 paper

Interview 6

Suitable Date: 30th May 2015



Suitable Time: 2 pm Pakistan time 10 am UK time




Role/Designation of Interviewee: Project Manager

How long you have been working in GSD?: 5 Years



Size of Organization (specify in number of employees): 30-35 in (software development in Bahawalpur and

London), more than 3000 in gulf, London, Manchester other functions

Number of sites usually work distributed to: 2-3

How long the organization has been doing GSD?: 2005

Do you perform GSD on regular basis?: Yes 80% GSD

What type of GSD is usually performed by the organization i.e. off shoring or off shore outsourcing etc?: 60%

Off shoring and 40%offshore outsourcing

Type of Projects usually developed globally?: Security Solutions, ERP Solution

Section 1:


Cost cutting


Reduce Development Time mainly (too many holidays and 5 working days in UK)

In Pakistan 6 working days


Setup established in Pakistan specifically for GSD so it is long term planning


Yes, like some urgent tasks we build in UK don’t give to offshore office due t o reason of delay and all



Section 2:


Requirement Elicitation done then make work breakdown structure then move to statement of work

(define timelines, modules, milestones),then make progress sheets which is has time associated with it

(designed in Google sheets).

Use agile methodology so focus on dividing tasks therefore work is divided into tasks and they are

allocated to individuals


Project Manger (head software section so all software related work comes here).


After statement of work, requirement specification finalized.


Yes everything saved in work progress sheets.


2-3 hours


No


Meeting all executive staff,ceo,2 directors, sales development team leads, discussed there


Project Manager


One time, very rarely need to change, in case of new requirement

Work progress sheets



Architecture document seen components prioritized on its basis.




Project Manager


One developer sparred only who works on changes

Section 3


Urgency of Task

Experience level of developers and expertise


Vary from project to project, where timeline strict we choose site which is expert and changes of errors

less


Yes labour cost

Time other sites adapt to our time so no issues, similarly communication and coordination they adapt,

personnel availability not much of an issue usually we accommodate by doing some other task at that time.


Yes

Q7.1: Do you record the trade off decisions for future use?

Meeting recorded by camera and minutes of meeting


Mostly same, some factors like urgency of task varies if it is for some customer.


relationship etc)

Yes trust matters, sites which usually deliver on time, experience good.

Political reasons not a factor.


Section 4



Q10: What are the three main factors considered while deciding to Offshore?

Commitment level, skill level, cost

Q11: Who decides to offshore?

Executives mostly, team leads

Q11.1 Do you take input from any other role or document?

UML diagrams but my work on use cases

Module wise allocation done in a meeting of team leads

Q12.1: Do you know about the tasks to be off shored at off shoring decision time?

Yes

Q10.1.1: Can you think of any other factor?

Timely delivery

Cultural differences as communication gaps so those sites dropped (Indian)

Availability of site

Q12.1.1: If yes do you map the characteristics of off shoring site with the characteristics of the tasks to be off

shored?

Yes with respect to skill and time as well, when to develop.

Section 5


Yes, architect gives suggestions, work breakdown structure has dependencies in terms of which module

needs to be developed early so we see it.


Work breakdown structure, statement of work,progress sheets


Project manager

Section 6


cultural distance)



Communication and coordination needs no issue in our case it was a problem when we used to get work

done from freelancers. As timing did not match

In our case the Pakistan site adapts to time difference

We communicate via skype or email to save it

But time is a major factor when sites increase in case when we are working with 3 sites communication

becomes are problem, Indians have set their time according to usa time.


no


none

Interview 7

Suitable Date: 4rth August 2015

Suitable Time: 7:30-8:30 AM Pacific Day light Saving Time




Role/Designation of Interviewee: Program manager (mobility cloud service)

How long you have been working in GSD?:10Years



Size of Organization (specify in number of employees): 200 engineers’ enterprise team who builds actual

services _rest very big


How long the organization has been doing GSD? 25-30 Years


What type of GSD is usually performed by the organization i.e. off shoring or off shore outsourcing etc? Both

Type of Projects usually developed globally?all communication softwares specifically speech related

softwares



Software development Methodology used during GSD? Combination of waterfall and agile, more agile but

waterfall is necessary to see if things in place.

Section 1:


Resource skill set and labour cost


Time to market, 24/7 development, Reduce cost, Make use of skill set


Yes


Yes absolutely


Yes, if we are looking at specific team of people to work on a portal interfaces we may look for experts.

Indian teams have that skill set of designing portal interfaces so we give to them

Section 2:


A team selected for a project or program for development or services. It would participate in task

assigned to resources who have skills in waterfall. Difficult as you need time zone with which you can

work. In agile people pick task.


Development Manager, or the scrum or sprint master.


Scoping and requirement phase

Architecture and design

When we agreed on design then resources are assigned to components. Always tied to who has the

expertise or skills to do it. Assigning components to different regions, their will be dependencies between

the for sure, work flow dependencies seen for task allocation. Different components given to different

regions but then integration testing done.




Its contractual. When team assigned to component it remain same for years. Scope of work document etc


Few ours or one to two days for large projects …which may take over a year.


Developer manager or scrum master


Q6.1: What documents are produced as a result of TA? Skip to Q14 of section 5

Shared document for overall solution ,their is information regarding each component


No previous documents seen


Generally no need but there are cases where for whatever executive reasons that we no longer want to

work ..team maybe dissolved.


Section 3


Skill set

Cost

These are the two.

Resources are on multiple projects, so personnel availability a factor.


Global market today is about where do you have resources available. You would look for availability. We

look at cost. But that is only a factor when you have resources available in all regions which may not

always be the case

Skill set more important.




No time zone difference not seen….too many communication and coordination technologies

available.Cultural difference also not seen.If culture is a problem then you find a point of contact who

knows both languages.Experience of site developing that particular kind of application is similar to skill

setTesting and QA department also world wide so process ownership not seen

Customer proximity not seen since we provide services globally, if it was for a specific customer then yes

maybe.Communication and coordination maybe a consideration but not too much important.


yes


It’s stored as resource assignment, why a particular development group was selected. It is not rigid as

that. When a service is pulled together , its long term but old documents not seen for future allocation


yes

Q8.1.2: Can you think of any other factor which should be considered during TA? (Political reason, trust, prior

relationship etc)

Political reason a factor, yes trust and prior relationship also a factor..it becomes preference not a

requirement.


Section 5


The design document.

Q15: What other information does the product architecture hold? (Communication and coordination structure of

the distributed team)

Yes Conway’s law holds, but we don’t see communication and coordination structure before task

allocation. You don’t allocate based on component dependency as all teams are supposed to have the

communication and coordination infrastructure for development, its expected. There is always a need for

cross communication. Its not a factor at all, it’s a baseline requirement.


The design document, we allocate based on skill that is required. It is consistent with architecture..you

look for skill set required , your assumption would be skills of engineers are according to workflow so not

the dependencies that derives the task allocation.




Must have to be able to have conference calls, video or some time of live communication that you can do.

Technology can help the communication and coordination needs. Team has to accommodate the time

difference. It is common in US to work late to accommodate, Italy, china, Canada or India.

Sites we work with

We work with Montreal Canada, In Germany, Italy, Offices in india

Section 6


Cultural liason a strategy to minimize cultural difference.Communicate using Google translator, its not a

joke…its not precise but intent in meaning. They either are English speaking or they use a point of contact

who knows it. We adjust time work late or getting up early.

Interview 8

Suitable Date:

Suitable Time:

Preferred Interview mode: Skype By Call Face to face



Role/Designation of Interviewee:Technology Consultant

Q1: How long you have been working in GSD?7 years



Size of Organization (specify in number of employees):1,20,000 employees worldwide

Number of sites usually work distributed to:Various sites around the world

How long the organization has been doing GSD?More than 30 years

Do you perform GSD on regular basis?Yes


The term is in use in several distinct but closely related ways. It is sometimes used broadly to include

substitution of a service from any foreign source for a service formerly produced internally to the firm. In other

cases, only imported services from subsidiaries or other closely related suppliers are included. A further



complication is that intermediate goods, such as partially completed computers, are not consistently included in

the scope of the term.


Business software, Chemical engineering software, Software for children, Communication software, Computer-

aided manufacturing software, Data management software, Desktop widgets, Editing software, Educational

software, Entertainment software, Genealogy software, Government software, Graphics software, Industrial

software.

Software development Methodology used during GSD?

Agile, scrum, Dynamic Systems Development, Joint Application Development, rapid Application Development,

Spiral

Section 1:


No licensing costs, Time saving, Money saving, Better focus on business operations, Build effectiveness of the

business, Achieve your business targets & goals, Better business profits.


Immense Resources, Incomparable Quality, Technical Expertise, In Time & Affordable Solution,

Customized Solutions


Yes.


Yes.

Q2.1.1 Does task allocation change with change in objective of doing GSD?Yes off course.

Section 2:




First identify which tasks can only be allocated to either the machine or human (mandatory allocation),

and then provisionally allocate tasks on either a permanent and dynamic basis. This provisional allocation

should then be evaluated and revised if necessary.


Project manager


When development phase is started in SDLC,


Yes we save it on project management software.


It depends on the work to be done.


Benefits and skills

Q4.1: Do they need feedback from any other role?

Yes.


Manager or team lead.

Q5.1: Is it a one-time activity?

Yes but it is often revised.

Q6.1: What documents are produced as a result of TA?

Task allocation, resource management


Yes task allocation sheet is maintained by project manager.


Team lead.




When someone is unable to to do the task.


By seeing free resource available.

Section 3


Resource using, Quality ,Time

Q9: How you trade-off between factors?

Q8.1: what about time difference and cultural difference between sites?

Both parties have to coordinate with each other.


Q9.1: Do you record the trade-off decisions for future use?

Yes.


No

Section 4


No.

Q11: Do you document you Task Allocation in form of some architectural view?

Yes.

Q11.1: Is this allocation information associated with other architectural information?

Yes.


Team lead


Different time zones, Cultural level , Communication level




Yes.

Interview 9

Suitable Date: 17th June, 2015

Suitable Time: 3 pm Pakistan time




Role/Designation of Interviewee: Senior Project Manager, Global Program Management Office

Q1: How long you have been working in GSD? 13 years



Size of Organization (specify in number of employees): 3500 at my site, 240,000 Global


How long the organization has been doing GSD?:20+ Years

Do you perform GSD on regular basis?: Yes


Offshoring within Same Company

Type of Projects usually developed globally? Embedded application

Software Development Methodology usually followed in the organization for software development? Hybrid

(PMI + AGILE/Scrum + SDLC)

Section 1:


Asia on receiving end, Europe on both sides receiving as well as allocating, task being allocated to it.

Software development has penetrated in different industries. Elance website and rent a coder changed the

dynamics and introduced Asia to north America because of cost, labour and skill set available in asia.

No industry without software. Past 10 years it has penetrated all industries, oil and gas, electronics etc.

Eastern Europe countries like Parague developing talent in software development.



Labour cost (cost) first reason, labour v. high, fortune 50, 100, 500, 1000 companies see cost. It started

with cost.

Second is skill set. Skill set variety in India and china. A concept of big theta, tera data, all about data

analytics, expertise in china, so all work related to data outsourced there.

For tax as well, as tax of making software in

Very high in America so reducing tax one reason. Companies like Ibm, Accenture, capgemini, kpmg hire

resources from india to gain benefit from 24 hour cycle. This is one of the reason to GSD as well. NCR,

Teradata, pepsi globally distributed company. They have developed offshore offices to gain benefit from

GSD.


24 hour cycle.

Success.

Scope of work very big so to cater it we need GSD.

(small companies don’t do much task allocation)

Pepsi in all countries, Microsoft and Cisco psychology very different so it depends on the psychology.


Both

Strategic business planning as well as on small scale.


Yes.

Our consumer good industry. Our task allocation not structured what work we have to get done from

where. We know this.

Section 2


Simple we are following PMI and Just Do it (JDI) and Scrum methodology.

When things translated from strategic vision into actionable portfolios. That’s the point when these

portfolio elements into projects and start allocation.




Project manager assigned to projects. Who is involved, whom to allocate what, pretty standard way.

PMI different then agile.

PMI psychology different in agile

Agile like parent child relationship

Driving force PMI methodologies.

Scrum and agile part of program plan. Some companies still use waterfall

Project manager, program manager or program sponsor all can do task allocation. Program sponsor is

the one who has to deliver.


Right after requirement analysis after requirement gathering. SRS finalized.

Subject matter expert giving information to requirement engineers.All information making SRS.Task

allocation last step in planning.



Scrum is used when software developed, waterfall for overall system development. For Samsung galaxy

android operating system made using scrum whereas Samsung galaxy handset made using waterfall.

It varies from project to project, scope to scope.


Portfolios identified, like in telenor, finance marketing, HR, IT, it’s a Norwegian company. Strategic plan

says by 2015 you have to achieve this. Telenor Pakistan converts it into Actionable items(projects), telenor

talk shalk one project among it, then project manager assigned and task allocated. These projects relate to

strategic business plan. But no one in Norway thought about telenor talk shalk. Resources then searched

for these projects. Mostly all this waterfall, but when software development comes it is agile


IT person (system architect) will tell What capabilities to enhance in existing system.


Iterative…When Scope change, Quality issue

Major resource left



Turnover, key people left. A lot of reasons.


Project manager discusses with program sponsor, but other options evaluated. Reallocation is not easy.

Section 3


Scope of work, if its big we outsource magnitude and nature of work matters.

Cost (in case of outsourcing)

Skill set…where it is present.

Data analytics present in china so all work related to it outsourced to china.


It depends on nature of work, scope of work. For example. Now we are making ipad of fountain drinks,

like you can customize your drink. All development work done in india in tech Mahindra. Why because in

india doing a lot of work in gadgets. UI(user interface) UX(user experience) developed in California.

Product packaging in New york


Culture and time?

Yes, but not much as very few companies look into it. These are not decision making factors. Companies

just want to make money. E.g. if critical work you have to allocate to a location no matter what cultural

location or time zone it is in?


No Steering committee, all conversations. In board meeting tell all detail we are doing this, this is the way

we are going for it. Just Power point presentations. Q8.1.1: would they remain same for all

projects?

It will differ from Organization to organization

Scope of work, nature of work


relationship etc)

Yes, vendor is Accenture, previous vendor Ibm. I am happy and comfortable with IBM not with

Accenture so next time I will definitely choose IBM.



Section 5


Components not allocated to different sites.

You may allocate task on basis of architecture or not.

Architecture not stable, they get changed. Deciding task allocation on a level of architecture may or may

not be possible.

Section 6


cultural distance)

Depends on work if its only transactional work is ok.Chinese problem English language so very difficult to

get work from them.

Precise and Crips…

Adequate level of communication.

to avoid confusion issue, then he should be able to communicate with sponsor before discussing with team.

He should have a very structured frequency of coordination with the team. Open channel with them.

Timely coordination should be done.


Nothing. Company to company it varies. Big companies have made their standard, so we have to adapt.

Small companies adapt to time and culture. Microsoft and ibmetc you have to follow their working hours

etc.

Interview 10:

Suitable Date: WeekEnd(Fri, Sat.) (15 June 2015) at 11 pm pakistan time

Suitable Time: After 10PM, GMT +3

Preferred Interview mode: By Call



Role/Designation of Interviewee: Chief System Engineer

How long you have been working in GSD? 10+ Years





Size of Organization (specify in number of employees): 5000+


How long the organization has been doing GSD? Since Start


What type of GSD is usually performed by the organization i.e. off shoring or off shore outsourcing etc?offshore

outsourcing

Type of Projects usually developed globally? different

Section 1:


In case of changes if high volatile project we keep it in house. We do outsource when we feel that other

company can manage, we are unable to due to resource shortage etc. And also if like a module they can

work on it, if the work is independent (module is : every part of system which can work independently, it

can be library a system or it can be solution (cloud based))


How quick we need the product so we outsource because of parallel work

We don’t want to reinvent the wheel so give work out.


GSD not part of strategic planning policy, not well defined but based on feasibility we have to take

decision with management that we need to outsource


Yes we do, 10 years before working distributed very difficult because of lack of tools, passing files, emails

we had to maintain Now a days project management tools, task management tools, development team

management all tools available. Tasks can be added, actual code, the tool has information of which code

entered by which person in which country etc. code checkin, checkout status update…

Section 2:


Domain of the person seen, scope of project seen. We ask for company profile and cv in case of free lancer

(we interview as well). We chose sites or organization on basis of reference as well.



When requirements come, requirement engineering done, we understand client, conflicts come, they

cannot understand technology issues. Then we make SRS (software requirement specification document)

for scrum it freezes for a sprint. WBS made, project plan made, acceptance done, execution plan made,

designs made, we handover to developer and so on.

GUI designed as well.


Project Management but other management involved too.

Usually technical manager and non-technical manager separate, both managers involved to understand

what type of resources should be involved etc.


After architecture, When other requirements identified as well e.g. discussion with sponsors as well.


We use systems, all things put in system, task assignment also done through system like foundation server

etc.


Depends on project scope etc, An activity where we put all modules put in system, before it task allocation

done. Can’t specify time as it varries. Q3.1: What information is required for Task Allocation?


Yes architect involved


Project Manager


Usually if system not properly designs we will need to re allocation. But if system modularized properly,

structured, 90% no problem. Very few cases it may still be required.

Q6.1: What documents are produced as a result of TA? Skip to Q14 of section 5

None, all things done in tool






Project Manager


A task we assigned but later found out it come in automated testing domain so we had to reallocate.


Section 3


Technical things don’t matter much

Culture matter, their way of living we need to understand. Weekends and holidays etc seen as well.

Cultural differences, we should see their norms and values as well.

We want to establish a long term relationship, We want to build a trust relationship, knowledge sharing

done etc.


I may choose a low calibre person on site if it is coming from a trust Worthy reference.

We make plans and give to management as per deadline and budget given; they are the ones who decide.


Time zone difference calculated…base lining a time zone e.g. UTS, we sync so not much of an issue many

Problems do come due to different time zone.


Yes they vary situation to situation. According to situation decisions vary

Section 5


Not an expert

In general answer it is not coming from mercury or mars…they are derived from business logic…we

make our design..Customer is a real world entity; we make a Business flow and a System flow as well. E.g.

if in business flow it is



Documents cannot go before officer signature in

System flow it is a functionality dependency

Therefore they are both dependent. They can introduce dependency.


All coordination on tool.manager level may need communication but technical teams hardly communicate

much except for what is defined

Section 6


cultural distance)

Yes v. imp factor, communication . We do consider it. We define a role of technical communicator


Yes…

Australians very Blunt, though they don’t mean it but we prefer to introduce a person who has worked

with Australians before

Appendix E: Detailed Spearman Rho Test

Table Appendix-E1: Spearman Rho Correlation between Architectural Views

Correlations

La

bo

r C

ost

Wo

rklo

ad

Dis

trib

ute

d S

ites

Sit

e C

ha

ract

eris

tics

Ta

sk_

Sit

e D

epen

den

cy

Ta

sk S

ize

Per

son

nel

Av

ail

ab

ilit

y

Pro

cess

Ow

ner

ship

Co

mm

un

ica

tio

n/C

oo

rdin

ati

on

Ov

erh

ead

E

xp

erti

se

Co

mp

on

ent

Dep

end

enci

es

Tim

e D

iffe

ren

ce

Cu

ltu

ral

Dif

feren

ce



Spearm

an's rho

Labor_Cost Correla

tion

Coeffic

ient

1.00

0

.468

**

.292

*

.244 -

.043

.167 .132 .286

*

.231 .198 .032 .094

Sig. (2-

tailed)

. .000 .036 .081 .765 .237 .362 .042 .100 .159 .822 .510

N 52 52 52 52 52 52 50 51 52 52 52 51

Workload_DistributedSites Correla

tion

Coeffic

ient

.468

**

1.00

0

.356

**

.255 .008 .179 .234 .171 .253 .167 .177 -

.010

Sig. (2-

tailed)

.000 . .010 .068 .958 .204 .102 .231 .070 .238 .210 .946

N 52 52 52 52 52 52 50 51 52 52 52 51

Site_Characteristics Correla

tion

Coeffic

ient

.292

*

.356

**

1.00

0

.452

**

.119 .169 .249 .231 .384

**

-

.016

.028 -

.035

Sig. (2-

tailed)

.036 .010 . .001 .397 .227 .078 .103 .005 .912 .844 .806

N 52 52 53 53 53 53 51 51 53 52 52 51

Task_Site_Dependency Correla

tion

Coeffic

ient

.244 .255 .452

**

1.00

0

.015 -

.086

.112 .269 .333

*

-

.005

-

.042

-

.032

Sig. (2-

tailed)

.081 .068 .001 . .914 .539 .433 .056 .015 .970 .768 .824

N 52 52 53 53 53 53 51 51 53 52 52 51



Task_Size Correla

tion

Coeffic

ient

-

.043

.008 .119 .015 1.00

0

.433

**

.453

**

.144 .172 .337

*

.272 .252

Sig. (2-

tailed)

.765 .958 .397 .914 . .001 .001 .315 .219 .014 .051 .074

N 52 52 53 53 53 53 51 51 53 52 52 51

Personnel_Availability Correla

tion

Coeffic

ient

.167 .179 .169 -

.086

.433

**

1.00

0

.380

**

.070 .256 .318

*

-

.095

-

.234

Sig. (2-

tailed)

.237 .204 .227 .539 .001 . .005 .623 .062 .020 .497 .094

N 52 52 53 53 53 54 52 52 54 53 53 52

Process_Ownership Correla

tion

Coeffic

ient

.132 .234 .249 .112 .453

**

.380

**

1.00

0

.518

**

.307

*

.444

**

.246 .147

Sig. (2-

tailed)

.362 .102 .078 .433 .001 .005 . .000 .027 .001 .082 .302

N 50 50 51 51 51 52 52 50 52 51 51 51

Communication_Coordinatio

n_Overhead

Correla

tion

Coeffic

ient

.286

*

.171 .231 .269 .144 .070 .518

**

1.00

0

.480

**

.521

**

.410

**

.448

**

Sig. (2-

tailed)

.042 .231 .103 .056 .315 .623 .000 . .000 .000 .003 .001

N 51 51 51 51 51 52 50 52 52 52 52 51



Expertise Correla

tion

Coeffic

ient

.231 .253 .384

**

.333

*

.172 .256 .307

*

.480

**

1.00

0

.330

*

.059 .110

Sig. (2-

tailed)

.100 .070 .005 .015 .219 .062 .027 .000 . .016 .676 .439

N 52 52 53 53 53 54 52 52 54 53 53 52

Component_Dependencies Correla

tion

Coeffic

ient

.198 .167 -

.016

-

.005

.337

*

.318

*

.444

**

.521

**

.330

*

1.00

0

.468

**

.361

**

Sig. (2-

tailed)

.159 .238 .912 .970 .014 .020 .001 .000 .016 . .000 .009

N 52 52 52 52 52 53 51 52 53 53 53 52

Time_Difference Correla

tion

Coeffic

ient

.032 .177 .028 -

.042

.272 -

.095

.246 .410

**

.059 .468

**

1.00

0

.590

**

Sig. (2-

tailed)

.822 .210 .844 .768 .051 .497 .082 .003 .676 .000 . .000

N 52 52 52 52 52 53 51 52 53 53 53 52

Cultural_Difference Correla

tion

Coeffic

ient

.094 -

.010

-

.035

-

.032

.252 -

.234

.147 .448

**

.110 .361

**

.590

**

1.00

0

Sig. (2-

tailed)

.510 .946 .806 .824 .074 .094 .302 .001 .439 .009 .000 .

N 51 51 51 51 51 52 51 51 52 52 52 52

**. Correlation is significant at the 0.01 level

(2-tailed).



*. Correlation is significant at the 0.05 level (2-

tailed).

Appendix F: Focus Group Protocol

FOCUS GROUP PROTOCOL

The purpose of the focus group is to gather practitioners’ feedback on the applicability and effectiveness of the

proposed Task Allocation Framework for GSD projects. Practitioners will be asked to comment on the

applicability of the framework keeping in view real world GSD task allocation scenarios.

The feedback of the practitioners’ will help in:

1) Determine the applicability of proposed task allocation framework on real world GSD project(s) for

different GSD scenarios.

2) The strengths and weaknesses of the proposed task allocation framework.

3) Problems in the framework that hinder its applicability.

4) Solutions/changes that will help in improving the framework.

The above feedback will help us in improving the proposed task allocation framework..

Objective of Study

Objective 1: Checking the applicability of “Task Allocation Framework” for actual GSD scenarios by industry

experts.

Objective 3: Improving the “Task Allocation Framework” based on feedback from industry experts.

Total time required: 2 Hours 30 Minutes

Focus Group Roles:

Project Leader: Salma Imtiaz, Dr. Naveed ikram.

Facilitator/ Moderator: Ms. Tara Hussain

Assistant Moderator:

Focus Group Participants: Project Managers or Other roles involved in task allocation decision of a GSD

project.

Exclusion Criteria:

1. The practitioners having GSD experience <3 years.

2. Researchers working in GSD



Date:

Time:

Location:

Table Appendix-F1: Agenda Items

Time required: 10 Minutes

Introduction

Introduction of Facilitator: Back ground and Experience (Ms. Tara Hussain) Internal to the Organization.

General purpose: We want to conduct focus group to get feedback of practitioners on the applicability and

effectiveness of the task allocation framework developed as part of PhD research for a Global Software

Development (GSD) Environment.

Use of data:

The data will be used to highlight the validity of the task allocation framework to the research community.

It would also be used to improve the task allocation framework to increase its usefulness by the industry.

Anonymity: We want to assure that the focus group member’s information and responses will not be disclosed.

The information collected will strictly be used for research purpose, and will be analyzed and reported as an

aggregate. We will tape record the session for analysis of data.

Time required: 10 Minutes

Warm Up Period:

Start the session by reference to the task allocation framework (which has already been sent) if any question

regarding fame work, answer during the allocated time period of warm up period.

Time: 10 Minutes

Writing Period:

Write down the important factors you consider while allocating tasks to distributed sites based on different GSD

scenarios.

Time: 2 Hours 10 Minutes (5 Minutes Each for Each Participant)

Questions Period(5 Minutes)

Name:

Designation:

Organization Name (if worked in multiple GSD organizations please specify):

Number of years on GSD Projects:

Country (if worked in multiple countries please specify):

Q1: Do you think that the task allocation framework will help in making decisions for allocating tasks on a GSD

project?

Q1.1 If yes, How will it help?

Q1.2 If not, why not, What are the problems you see?

Q1.2.1: Why you think these problems will affect the applicability of the framework?

Q1.2.1 How can the framework be changed to increase its applicability for real world task allocation

of GSD projects?



Time: 10 Minutes

Summary

May identify new variations points/layers or change/delete old ones.

May identify new attributes as result of discussion or change/delete old ones.

Proposed changes to improve the applicability and generalizability of the framework

Strengths of framework

Weakness of framework

Time: 5 Minutes

Wrap up /Thank you

We are really thankful for your time and valuable feedback. It would greatly help us in improving the task

allocation framework.

Your responses are confidential and would only be used for research purpose.

We will also email you the summary of the focus group within two weeks.

Appendix G: Task Allocation Framework Given to Participants and Focus Group

Discussion

The developed TA framework given to the participants for evaluation is given below

The attributed present on each layer are the TA factors and the layers are the variation points

to the TA decision.The direct correlation is between size of task (Layer 1) and personnel

availability in (Layer 2) where as an indirect correlation is between component dependency

(Layer 1) and communication and coordination overhead (Layer 4). The correlations

highlight the ability of factors to impact each other whether they are associated directly or

indirectly. The dots present in the bottom right corner of the layers are used for extension

purpose, i.e. the list of factors is not complete and can be extended based on new knowledge

and situation. The layers are connected with arrows with the association written on right; task

requires expertise and expertise belong to an organization and the organization is located at a

site. The site is either a country or a particular region e.g. we may identify it as a Pakistani site

or Asian Site. Some factors present in a layer may impact others on the same layer. Task

allocation decision should consider the attributes of task such as volatility, urgency and



component dependencies and then identify the associated expertise for it. Volatility also

known as requirement stability is highlighted as an important factor by industry experts

(Mahmood et al., 2017). Similarly choice of an available and experienced expertise is

followed by evaluating the factors of the organization. Finally the factors associated with the

site are analysed and a task allocation decision is made. Thus the consideration of factors on

each layer one by one will help us in reaching the final task allocation decision. Moreover the

factors have different weightage with respect to the situational and project characteristics e.g a

project which has time constraint may give more weightage to time zone difference and

expertise than other projects. Similarly a task which is volatile in nature would give more

importance to communication and coordination overhead and keep the task at home site etc.

This weightage needs to be assigned by the task allocation team when the decision is to be

made. Consensus is required between all the task allocation team members before weight

assignment. Such a task allocation will be based on careful evaluation of all the important

factors for an effective task allocation in a GSD scenario rather on ad hoc basis. We assume

that the task allocation performed after careful evaluation using the proposed framework will

result in smooth and independent development and would not result in unnecessary delays.

The framework inherits the benefits associated with the layered style, since more layers can

be added if needed. The feedback of the participants is recorded below.

WARMUP

Kindly download the file in the link below and read the document for a good basic understanding of the

framework under discussion.

Do you have any query regarding any layer or attribute of the framework?

Karen S

None

Posted 14 days ago

Comment Agree (0) Delete

Khurram B

What challenges this Framework tend to resolve in Task allocation? The model has been described well though

Posted 14 days ago


https://www.focusgroupit.com/groups/9b34eaa2/questions/9759


https://www.focusgroupit.com/groups/9b34eaa2/questions/9759/replies/88919






Salma Imtiaz MODERATOR

Dear Mr. Khurram

We explicitly wanted to state all critical factors that need to be considered for a better task allocation decision as

most of the time they are not given much thought resulting in a task allocation that needs to be changed latter on

in software development due to problems in first allocation or may result in problems such as communication

and coordination overhead to resolve problems or over all project delay. Therefore maybe not all factors are

considered but some of them are considered as per scenario.

Posted 14 days ago



The factors are presented in layers to facilitate the selection as some factors influence others as they are

correlated and cannot be considered in isolation.

Posted 14 days ago


julianharty

Rather than have queries, I have concerns that it's theoretical rather than realistic. I doubt international

companies I've worked with and for would really consider this concept or the model that's actually described

here.

I've handwritten some notes on the attachment. In essence the author has made some assumptions or statements I

dispute e.g. "minimal informal communication opportunities". I've worked with various international companies

where I - based in England - have had to work with the parent company in the USA. We've found all sorts of

ways of establishing and to some extent maintaining informal communications. A lot depends on the

mindset/persona of the organisation, their budget and willingness for staff to travel to other locations.

Posted 14 days ago



Thank you Mr. Julian. I do agree that budget and culture of organization impacts the decision but

would a task that is very communication intensive be outsourced to an organization that is very far both

geographically and temporally if the budget is also low and the culture of other organization is not much verbal

communication?

Posted 14 days ago














julianharty

You're presenting a fairly narrow scenario in your question with implicit contradictions: very communication

intensive with a culture of little verbal communication. Such a project wouldn't work well regardless of where it's

intended to take place - the question of outsourcing is secondary. However, paradoxically I could envisage some

organisations choosing to outsource such projects because they don't want the hassle of dealing with the

communication issues locally, and if (as is likely) something goes wrong with the work they can now blame the

outsourcing organisation rather than being blamed themselves. - not, perhaps, what you'd envisage or expect, but

true to human instinct and behaviour.

Posted 14 days ago



Yes Mr. Julian

If i am getting it right this approach is also aligned with risk mitigation where we transfer the risk to another

organization, to deal with problem of ineffective or too much communication. But what if the main site has to

communicate time and again with the remote site due to the nature of the task (which is highly dependent on the

main site). My question is would communication and coordination overhead be given importance and task

allocation changed in this scenario or no?

Posted 12 days ago


Mathew D

You define "Culture" as a dimension in your framework, and have a further attribute "No of cultures" at a higher

layer in the framework. How do you define/measure the culture dimension? Seems a little artificial to me...

Posted 15 days ago



We have defined culture on two layers one corresponds to organizational culture as an attribute, it is the culture

of the organization(s) involved in GSD, the other corresponds to the culture of the country(s) or region(s).

However since a task allocation decision may involve multiple countries and regions therefore the last layer

which corresponds to task allocation decision will comprise of all the cultures of different countries and

organizations involved in that GSD scenario.















Posted 15 days ago


Prof.Dr. Frank H

None

Posted 16 days ago


Q1: Do you think that the task allocation framework will help in making decisions for allocating tasks on a

Global Software Development project? If yes, How will it help?

In my opinion, the task allocation framework will help in making decisions for allocating tasks on a GSD

project, especially if the product being developed is mature and has market presence and stability, and has a

limited innovative design thinking requirement towards it. The strength of the framework lies in its extensibility,

and ability to assign weight age to the various factors affecting the allocation decision.

Posted 24 hours ago

CommentAgree (0) Delete

ZishanNEW

As per my experience in the industry GSD is used more like a concept then an actual 100% implementation of it.

Also I have seen companies mold the concept based on their needs. Considering these facts I believe that this

allocation framework will help provide guidelines in task allocation for the following reasons :

The variables mentioned in each layer are accurate and will help with the task allocation strategy because in

reality the sequence/flow of the layers is not very explicitly defined or followed and varies on experience of the

person leading the project. What ends up happening is that some factors/variables being the most impacting to

the organization tend to influence the flow and therefore the task allocation decisions start to revolve around

these variables. This can sometimes cause the organization to face unexpected challenges later in the project

because of not foreseeing the less important but impacting variables ahead of time. This framework gives a

clarity on most of the major variables with a certain flow (layer wise) which if considered in planning will help

chose the most suitable task allocation strategy while laying out hidden challenges/problems ahead of time.

Karen S

As a minimum, the framework can be beneficial for raising awareness of the factors which can impact

effectiveness of GSD projects. It could also be beneficial, potentially more beneficial, for considering allocation

of higher-level "work packages" and not just individual tasks.

Posted 14 days ago














Thank you Ms. Karen

I will definitely keep that in mind.

Posted 13 days ago


Khurram B

I am sorry, but shouldn't it be the motivation given by the authors on how it will help in making decisions?

Every company has different way of making decisions.

Posted 14 days ago



Yes Mr. Khurram we have described the way it can be used but that is based on our understanding of how the

task allocation decision is done in industry. Although the information is based on the data from survey and

interview study also from practitioners but now we want to validate it again from the industry to improve the

framework so it is more practical.

Posted 14 days ago


julianharty

Theoretically a task allocation framework may help somewhat e.g. where organisations have some awareness of

the expertise of staff and teams in other locations and the relative costs, they may make more informed decisions.

In practice only 2 of the companies I've worked for have had a good understanding of the expertise of others and

these were achieved through people travelling and meeting each other rather than using a framework.

Posted 14 days ago




















Thank you Mr. Julian.

But even if they don't know about expertise present at other sites, would they consider other factors mentioned in

the framework for which they have information?

Posted 14 days ago


julianharty

I think they'd consider some of the factors you've captured in your framework, however they're unlikely to

consider these factors as part of a hierarchical framework. I believe that the individuals who make these

decisions would like to think that they've considered most of the points you've captured in the task allocation

framework, albeit they may do so based on fairly superficial evidence.

Posted 14 days ago



Do you think there is any other hierarchy the factors can be arranged in ..as they do impact one another ?

Posted 14 days ago


julianharty

I;d start by removing the concept of hierarchy (at least initially) and then try modelling the relationships between

the various entities/objects (task, expertise, org, & site) . Also, I've just realised you're modelling expertise as

something that belongs to a site. Expertise is predominantly a human-individual attribute which might be

aggregated or assumed to be available to the (ir) employer. In my view it doesn't 'belong' i.e. it's not a possession.

Even though employment contracts ask to assign IP expertise, etc. expertise is something an individual controls

on a daily basis. The model seems to be digital (yes/no, 3, 65%, etc) while the humans who do the work are

variable, emotional, fickle, etc. The model still has potential BTW these are observations that go beyond as the

model doesn't quite capture reality (and is unlikely to ever do so).

Posted 13 days ago



Thank you Mr. Julian

I would definitely keep that in mind while improving.















Posted 13 days ago


Mathew D

Interesting framework, but some comments:

1. Some of the dimensions are very general (e.g. "trust") and probably compounded from other subsidiary

dimensions (e.g. delivery record, quality of work, etc) that are more directly measurable.

2. It's not clear whether this model is meant to represent a single organization with multiple development centers,

as opposed to a sub-contracting kind of effort with multiple vendors. The task/resource allocation decisions are

different in either case.

3. In general, this is a reasonable model, but probably more theoretical than practical. I don't think it is

particularly useful in real situations.

Posted 15 days ago


julianharty

I agree with Mathew's first point in particular - that additional factors such as trust (in the competence, ability to

deliver, and the quality of an individual's or a team's work) are important, relevant factors to consider. Software

hasn't yet reached the commodity level of work/tasks where 'any' software engineer can complete a piece of work

equally, there are so many more factors involved and plenty of published material on the importance of teams,

approaches, working practices, etc. which don't seem to be represented in this model and I doubt would be

completed by most teams. I've seen too many organisations try the beguiling 'follow the sun' model to get work

done where the results are mediocre and often counter-productive. It's not to say such a model can't work or

doesn't work, just it's unusual when it does effectively. And when it does, it's often because the people involved

in the work know each other and have personal respect and trust (not something recorded in a system or model).

Posted 14 days ago




Yes you are right however the strategies such as follow the sun etc just given importance to one or two factors

such as temporal distance and coordination overhead. Whereas we want to highlight the importance of other

factors as important for the decision even in case of follow the sun configuration e.g. since so much transfer of

work or coordination between teams will take place is workload of the team members considered at all? or is the

culture of the organization considered at all as it may impact the willingness to coordinate?

Posted 14 days ago













julianharty

There are various additional factors to consider including the perceived (in)equality from one team to another

e.g. if I 'believe' the team I'm receiving the work from are at least as competent as I and my team then I'm more

willing to work with them then receive and continue the work. If, conversely I don't believe they're as competent

I'll question their work and be reluctant or even refuse to touch their work. There are also considerations such as

customer service, technical and production support - where software is being used as it's being written and

updated then another factor is how effectively the developers manage to communicate with these other parts of

the organisation.

Posted 14 days ago



Yes you are right Mr. Mathew that trust is based on previous experience where any such experience exist and it

may not be a factor in case of new relationship. But we will keep in to consideration the metrics for each

attribute as per your suggestion.

But why do you think it will not be useful in real situations? Anything can be done to increase its applicability?

Posted 15 days ago



Thank you for your feedback. Actually we are incorporating both models i.e. same organization (multiple offices

in different regions) and different organizations in different regions. In the first case organizational culture would

be same whereas in second one both organizational and national culture would be different.

Posted 15 days ago


Prof.Dr. Frank H

It has potential. However, it would be more helpful if the framework were presented as a use case. This would

make it more practical.

Posted 16 days ago

Comment Agree (1) ?Delete


















Khurram B

I agree, providing different scenarios can well motivate the usefulness of model

Posted 14 days ago



Thank you Mr. Khurram we will do that to highlight the usefulness of the model in different scenarios.

Posted 14 days ago



Yes Dr Harper we can take an exemplary scenario and try to map the framework on it. But you think that it is

applicable on real world scenarios since you have worked on multiple GSD projects.?

Posted 15 days ago


Prof.Dr. Frank H

Maybe....that is why scenarios are needed

Posted 6 days ago


Q 2: What are the problems (if any) you see in the task allocation framework for Global Software

Development? Why you think these problems will affect the applicability of the framework?

some important factors needs elaboration such as organization's nature plays a crucial role in aligning project

portfolio strategy with company’s structure and culture. Moreover, organization’s mission plays an important

part in defining clear goals and metrics supporting the strategy. For example, a university’s research

product is very different from a product developed in a company that develops and improves on an already

established product. The work in a university lab research environment is purely focused on cutting-edge

research based on university funding. The work is based on research from the researchers seeking breakthroughs.

Corporate funding joins the university funding when the idea incubates from the research lab to market as a

successfully deployed prototype in a business setting. On the other hand, if an organization’s mission is mainly

the bottom-line and profits (most of our corporate software world), it choses to invest in projects which align

neatly with it’s own culture, strategy and structure. For example, it prioritizes understanding the needs of

customers and it prefers its product features to be pulled by customer requirements, rather than pushed by

technical competence of its researchers and software engineers. This type of corporate software organization















cherishes customer affiliation, celebrates teamwork, leads by established operational processes and prioritizes the

customer- the Bottomline. In this type of organization, the aforementioned task allocation framework (along with

addition of feedback loops required to assess and change/ review task allocation as per project dynamics) works

very well

because the company already has established processes and espouses teamwork and customer affiliation. On the

other hand, a university research organization arm or incubation center cherishes achievement, celebrates brains

and top-performers, leads by expertise and prioritizes the cutting-edge research work. The task allocation

decision is strictly based on research expertise of the team. For example, a breakthrough research module may

take time to implement, to refine and to test for applicability. I, as a product manager of a team with such experts

made sure that the particular research feature is implemented in its entirety, and as such we are able to tap into

the full potential of that research. As a software manager, my priority in this case will not involve how much

profit this feature or module will eventually generate. However, this priority of profit generation does become a

variable in task allocation decision when product starts to mature.

Posted 24 hours ago


ZishanNEW

I wont call these problems but more of suggestions that might need to be incorporated in the framework:

1. In SDLC (Software Development Life Cycle) there are different stages/phases and I think in this framework

an important assumption that needs to be defined is that the strategy based of the framework MUST be revisited

at every phase as the priorities and the impacting variables can change during the SDLC.

2. The framework needs to incorporate the variable of "conflict of interest" which can become a big issue when

dealing with global teams and also "conflict management".

3. In the lieu of point number 2 you should also consider the confidentially aspects of the project as there can be

blocks of the SW/project which need to be specifically contained within a certain group and geographical

location. You have to also consider the regulations of the regions that your teams might be in and think about the

mechanism to accommodate the confidentiality involved in the project. This is a very influential factor for all of

the industry sectors where confidentiality is critical.

Karen S

In practice, product [line] architecture is a major constraining factor in allocations of work packages. There are

two types of scenarios to consider: greenfield, where the architecture will emerge from the project, and

brownfield, where an existing architecture must be considered. Allocation strategy may need to be adjusted as

the architecture evolves.

As a second consideration, fine-grained task allocation seems to assune that a conventional project manager is

making the allocation decisions. This is not the case in self-directed or agile teams, for whom this framework

would probably be too heavy.







Posted 14 days ago



I totally agree, However we have specified in our scope which is not given here but in my work that this task

allocation framework is for traditional software development methodologies and not the agile ones.

Posted 13 days ago



Ms Karen do you think the framework will be applicable in both scenarios that is greenfield and brownfield ?

Also how much architecture is involved while allocating tasks.?

Posted 13 days ago


Khurram B

What do you think about aligning the processes and development methodologies. If same way of working is not

followed then it can effect on planning and deliverables.

Posted 14 days ago


Khurram B

Continuing with previous comment, thought about a few more factors like Government and Political.

Posted 14 days ago



can you elaborate on government and political factor, Do this mean the pressure or influence of government or

executives of the organization to allocate a task to a specific site or organization?

Posted 14 days ago


Khurram B





















When it comes to Telecom projects, where I have worked with mostly. There were concerns about design tasks,

final release acceptance test, security tests.

I have seen these two factors effect indirectly, even though not highlighted mainly.

Posted 14 days ago


julianharty

As I've already mentioned in my response to the warm up: I don't see this framework would be used by many

international software organisations. Also there are logistical issues in allocating/assigning/accepting work (or do

teams have no decision on whether that'll undertake work?) For some companies, who charge and are paid by the

job such as outsourcing companies, they may choose to accept most of the work they're assigned as it suits their

financial model, however in the global orgs I've worked in the teams have too much autonomy to simply accept

the work they're allocated. And for companies who want to save money as a main objective perhaps this model

might be useful (I hope never to work for such an organisation).

Where work has been performed remotely (in orgs I've worked with/for) it's been agreed through ongoing

discussions as much as any other factors.

At about 2 paragraphs into the attached file (Information on Factors) I can tell there are lots of considerations

that have been researched, the following key factors were triggered while I was reading and I want to note them

now, before I continue reading...

I've seen examples where outsourcing companies provide an 'A' team to win a contract / project then - over time -

quietly replace the more competent team members with less expensive, significantly less competent staff. Staff

changes are commonplace and frequent in organisations and team and will occur during many assignments. How

does the model communicate these changes and their likely immediate and longer term impacts? Next is on years

of experience. One of the adages in Silicon Valley is never hire a programmer who is Java Certified. Through

bitter experience people learned that many people hired with certificates were mediocre at actually writing

software. Experience measured by time is a very weak and often misleading indicator of competence, ditto when

measured by many industry certifications such as ISTQB, Java Certification, etc. And the final comment for now

is on the effects of the technological environment. In one global company, a checkout of a project's source code

took many hours in a remote office, but only a few minutes in the HQ. In another, staff in India had to remotely

connect through remote console programs to development machines in the USA to do their work which

decreased their effectiveness by at least one order of magnitude. The real-world context plays such a significant

role in global software teams that the context needs to be understood and factored in. Ditto the human aspects,

including virtually all aspects of how the people communicate, interact and work together. Right, I'll continue

reading...

Posted 14 days ago









julianharty

OK, I've now read the rest of this document and am pleased you capture, albeit at a topic level, several of the

points I've made in more detail. I've a couple more observations on the contents. Also it'd be useful to have the

set of references which were missing from your document, presumably an extract from a larger doc.

1) Intellectual Property & security of the code & assets produced. How well do contracts, IP agreements, and the

practical aspects of applying the law to deal with IP issues, work? Some work may be performed in particular

countries or states for IP and / or security reasons. Neither seems to be part of the GSD model.

2) With 'follow the sun' and what you describe as the 'overnight gain effect' there's a significant probability that

the recipient of the resulting work (that happened when that staff member was off duty) will result in a morning-

after the night-before effect (which can be time-consuming, frustrating and result in extra work).

I notice both documents have 'plate form' rather than which I think you mean: 'platform'. Perhaps it's worth

checking whether you have some misbehaving or over-enthusiastic auto-correction in your document editor. :)

Posted 14 days ago


Karen S

I agree that IP protection is an important consideration, while also sometimes politically challenging to raise.

Posted 14 days ago



Which layer should this IP protection be assigned too, Is it the responsibility of the organization?

Posted 13 days ago




I am thankful for such detailed feedback, i am sorry about the spelling mistake:).

We would definitely consider other factors.

Posted 14 days ago

















Mathew D

I have alluded to this in my response to the previous questions. In general, I think the dimensions presented as

components of each layer are too broad and not directly measurable. How do you define "work load" or

"capability of personnel" for instance? This makes the framework less useful for practical implementation.

Secondly, I don't believe the hierarchy of levels (if it's meant to be that) is always the same. I can see cases where

the organizational objectives would be the highest level factor, or possibly the least important factor, in the

allocation decision. Thirdly, I don't think you clearly bring through the product definition role - you have product

definition at the site level, but I would think that would be a more organizational thing.

Posted 15 days ago


Karen S

I agree that describing ways to measure the dimensions would be useful. Measures could be quantitative,

qualitative, or nominal scale.

Posted 13 days ago



Thanks Ms. Karen we would definitely define metrics for all attributes during improvement.

Posted 13 days ago



Dear Mr. Mathew we start in from bottom layer but yes we can move back from top layer to bottom layer as

selection of some higher level attribute may affect the attributes on lower layers.

Also the organizations objective of doing GSD may vary and this can impact the task allocation decision we are

assuming that this reason of doing GSD is related with the organization and important for task allocation

decision?

Posted 15 days ago


julianharty

I really don't accept the hierarchical model as viable. Perhaps it applies for GSD organisations you've met,

however it doesn't for any I've worked with in the USA or Europe (or Australia & NZ), and even in my work in
















India and E. Africa I don't think it applied. Perhaps it'd have more relevance in very high competence

engineering teams and some of these may come from particular countries/cultures e.g. Japan & Germany, but I

don't have any concrete experience to provide more detail at this stage (I've worked in Germany and visited

Japan).

Posted 14 days ago



We only considered product architecture in form of component dependency at task level.

Posted 15 days ago



Also please can you highlight what you mean by product definition.

Posted 15 days ago



Thank you for the response. Kindly see the attached file of information on factors which i have uploaded for

explanation of the factors/attributes that we incorporated in the layers.

Posted 15 days ago


Prof.Dr. Frank H

Each component of each layer of the framework needs to be defined to provide a proper context to the reader.

Posted 16 days ago



Thank you Dr Frank. I have uploaded the information of each attribute in a document names "Information on

Factors".

Posted 15 days ago





















Q3: How can the framework be changed to increase its applicability for real world task allocation of

Global Software Development projects?

Other issues that can be discussed with respect to the framework and established industry practices, which can

potentially extend the process of task allocation include:

I. Enabling of distributed work (Installation and deployment of tools for collaboration, and

familiarity with those tools across the entire team that uses them)

II. Measuring performance and appraisal of developers and testers

III. Conflict management

Posted 24 hours ago


ZishanNEW

I think the answer to question number 2 answers this question as well as it provides the suggestions that will help

improve the framework.

Karen S

Provide example scenarios which illustrate how task allocation would occur without the framework, and with, to

show how the framework is used and how it can be useful. Do this with input from industrial companies if

possible, or as thought experiments if not.

Posted 14 days ago



Thank you for the useful feedback, We would check on some exemplary scenarios since the region we are in it is

very difficult to get hold of the main organizations who do task allocation in GSD.

Posted 13 days ago


Khurram B

From my work experience working in distributed teams environment, the model mentions all the aspects. It is a

framework and each company will need to adapt it as per requirements. The new processes and methods can be

added to compliment the needs of Task Allocation.

I take this model as a guideline and then adapted by project based on the factors.













Posted 14 days ago



Mr. Khurram thank you for the valuable feedback.

Posted 13 days ago


julianharty

Lat's start first with the question of the validity and value of the framework. If and when we agree it's got

potential to be materially useful then we can consider revising it. I hope I've provided some suggestions of

factors to include, I won't repeat them here. as they're available in my other responses.

Posted 14 days ago


julianharty

Sorry for my typo, I meant Let's start...

Posted 14 days ago


Mathew D

More rigorous definition of the appropriate dimensions for each level. More context to define what the layers

actually mean, and how you see their contribution to the overall project structure. Finally, it would be useful to

see this framework actually applied to a real-world project.

Posted 15 days ago


Prof.Dr. Frank H

As stated earlier apply the framework to real life projects demonstrating its use. This will remove the abstract

and make it more concrete.

Posted 16 days ago























Khurram B

Yes, GSD is agile and over time there will be different challenges.

The real world application of the framework will provide more valueable insight towards using it.

Posted 14 days ago


julianharty

I agree with both Mathew and Prof... - this framework seems theoretical. I personally doubt it'd be workable in

actual software development projects (whether academic, opensource, commercial or governmental (including

security-sensitive work)). I've found the material interesting to read (albeit by skimming through the 2

documents provided) and think you've done a lot of research and thinking about relevant issues - the challenge is

to move from theory to validation of the concept and the model.

Posted 14 days ago



Thank you for the response.

Yes we would move towards application of the model to real world scenarios or cases to make it more practical.

Posted 14 days ago










