EARLY WARNING SIGNS OF FAILURES IN OFFSHORE SOFTWARE DEVELOPMENT PROJECTS

sleeperhihatManagement

Nov 7, 2013 (3 years and 5 months ago)

44 views


Page
1

of
16

EARLY WARNING SIGNS OF FAILURES IN OFFSHORE
SOFTWARE DEVELOPMENT PROJECTS


Tom Philip*

philip@ ifi.uzh.ch


Gerhard Schwabe

schwabe@ ifi.uzh.ch


Erik Wende

wende@ ifi.uzh.ch


Information Management Research Group

Department of Informatics

University of
Zurich

Binzmühlestrasse 14

CH
-
8050 Zurich

Switzerland


*Corresponding author












Page
2

of
16


EARLY WARNING SIGNS OF FAILURES IN OFFSHORE
SOFTWARE DEVELOPMENT PROJECTS

A Research
-
in
-
Progress Paper

Abstract

Increased globalization and the consequent dispersion
of IT activities across the world have driven the
growth of global IT outsourcing. The share of offshore software development (OSD) in the high
-
cost
countries has grown tremendously in the past years and this trend will continue in the coming years.
Softwa
re development projects continue to experience poor performance problems because of their
inherent complexities and the uncertainties involved from the start. Although OSD projects offer cost
advantages, the unique risks related to cultural, linguistic and

geographic differences, knowledge
transfer and project management make OSD more vulnerable to failure than domestically outsourced
projects. This paper explores the early warning signs (EWS) of failures in OSD projects, a concept that
can be employed as a
n early warning system to avoid failures. Using the Delphi survey method, we
intend to find out the most important EWSs specific to OSD projects. Our panelists include 23 experts
primarily from the offshore client and vendor

companies in Switzerland and In
dia
. We compare the
EWSs of failures identified by client and vendor panel experts in the first survey phase. Four offshore
-
relevant EWS categories are presented in this paper, namely, culture, knowledge management, formal
project management and informal p
roject management.


Keywords
: Offshoring, Global software development, Project failure, Delphi survey, Early warning
sign, Project management


Page
3

of
16


1. INTRODUCTION


The increased globalization and the
resulting
em
ergence of a global IT market
have made IT
off
sh
oring a model of globalization [1, 2]
.
With this

increased distribution of

IT activities across the
world [3], the share

of IT offshoring in the high
-
cost countries is expected to increase significantly in
the coming years. A study by Forrester in 2007
reported that 65% of the US and European
organizations having 1000 or more employees cur
rently develop software

in offshore countries

compared with 45% two years ago [4 cited in 5
, p. 90].
The
IT offshoring

market will continue to
experience high growth r
at
e in the next five years and this

growth will largely come from applications
developmen
t and maintenance [6]
.

Several studies have reported about the failed software projects that cost billions of dollars to
organizations every year. The
much
-
cited
CHAOS Report

[7]

estimated that the US companies spent
USD 81 billion for cancelled so
ftware projects and additional
USD 59 billion for challenged software
projects in 1995
. McManus and Wood
-
Harper [8]

reported that IT project failures cost EUR 142
billion

across the European Union in 2004. In fact, IT projects experience more failures than
successes, if the projects are assessed on the originally estimated time, budget and
requirements [7, 8]
.
However, it should be noted that the concept of project failure

is vague

as very few people agree on
the exact definiti
on of project failure [9]
.

Review of IT outsourcing literature sh
ows that most research

focus on the IT outsourcing decision
processes and the management of IT outsourcing operations
[10
-
12]. Little

research has been carried
out about the IT outsourcing
project failures [13] and software development project failures [14]
. Our
research will contribute to fill this gap in the failure research, especially in IT offshoring.

IT projects can be judged from
the implementation and operations perspective and from the project
development perspective. As w
e focus

on software development processes in offshore projects

in this
paper, we will
adopt the project development perspective. We define
software development
project
failure
as the cancellation of the
software development
project

as a result of the
proje
ct team’s failure
to deliver

operational information system to the users
.

The project team in offshore software
development (OSD) projects includes client and v
endor team members that work at offshore and
onshore sites. The failure to deliver information system can happen at any development phase before
the system becomes operational. Our project failure definition corresponds to ‘total abandonment’ [15]
and ‘imp
aired’ projects [7] from the major works in the failure research.

Complexity of the nature of software development makes it vulnerable to failure
[16, 17] as it
require
s

intensive coordination and control throughout the development stages.

Ewusi
-
Mensah’s

[
14]

Page
4

of
16

comprehensive work about software development failures concluded that failures are
‘multifaceted
and multidimensional’ (p. 9) and any single contributing factor can cause the project to fail
, among
others,
technical,
cultural,
organizational,
political, managerial, sociological,

and economic fa
ctors
.
S
uccess remains rare for software

development

projects as they are difficult to manage

even in
conditions of co
-
location and proximity
’ [2, p.245]
. Software development with its high information
i
ntensity, low customer need, and
low physical presense appears to be
ideal for global dispersion
[18]
.

However, OSD

projects are more prone to

failure than the in
-
house and domestically outsourced
projects

[5]
. This failure susceptibility results from offs
hore
-
related risks, such as,
cultural, linguistic
and time
-
zone diff
erences, communication difficultie
s, and knowledge transfer complexities

[2, 19,
20].

Uncertainty from the project start is another characteristic of software development projects that
ma
kes it prone to failure

[17]
. Therefore, the early project stages are critical for the success

[14]
.
In
their upstream
-
downstream metaphor,
Hoch et al. (2000
, p. 97
) maintain that the uncertainty for
software development projects is higher ‘in terms of the

final outcome as well as in terms of schedule,
cost,

and other project parameters’ during the early stages

(Fig
ure 1
)
, which they refer to as ‘upstream
phase’. The high uncertainties result

because of unclear customer requirements, not entirely
predictabl
e design, changing requirements and changing technology. The uncertainty gradually
reduces as the project progres
ses towards the later stages or the ‘downstream phase’. For the
companies that engage in offshore projects with low organizational project matu
rity, the degree of
uncertainty will be even higher.



Degree of uncertainty
Time
Upstream phase
Downstream phase
Requirements analysis
Design
Coding
Integration and testing
Maintenance

Figure
1
:
Upstream
-
downst
ream framework [17,
p. 98
]

2. EARLY WARNING SIGNS



Page
5

of
16

Although there is no silver bullet to overcome the poor performance of software projects
[16]
,
the

postmortem

examination
s done at

failed

IT projects showed that before
failure
s

happened,
there were
significant symptoms
, indications or warning signs

of trouble
in the early project stages [21].
An
e
arly
warning sign (EWS) is defined as

an event or indication that predicts, cautions, or alerts one of
possible or impending problems … in the first 20 percent of the project’s initial calendar

[21, p. 31
]
.

In the medical field, patients with heart trouble might list problems such as chest pain, numbness in
the left arm as classical symptoms prior to a heart attack

[22]
. However, these symptoms might be late
to handle or they may be late warning signs. For

effective prevention of heart trouble early symptoms
such as high blood pressure or high cholesterol levels should be checked
[22]. As in the above
analogy, the early symptoms or warning signs that are known from the previous project experiences
can be le
veraged for better project outcomes.

F
ai
lures

do not happen overnight

[16] since they are dynamic and their ‘
opportunities for occurrence
are both ever
-
present and cumulative’
[23, p
.
72]
.
T
he project troubles
before the failure
are hardly
detected early
enough in the IT industry

[24].

Id
entifying and managing those troubles

provide a
n
effective

solution to save project efforts. In order to p
ut the troubled projects back on

track, an early
warning control mechanism seems to be necessary, especially in the early project st
ages. Keil and
Montealegre [25, p. 65]

have recommended the following:

At the earliest possible stage, managers need to ask themselves whether any “red flag
s” … are serious
enough to warrant project termination or significant redirection. By institutionalizing such an early
warning system, organizations can save considerable sums of money simply by identifying failed
projects while they are still in the stage
s of development

The early turnaround and recovery of projects maximizes the chances of success

[24, 26].
While the
project risk management focuses on risks during the who
le project life cycle, the
management
of
EWSs of failures
focuses on risks that
shou
ld be managed effectively right from
the early project
stages. Hence, the EWSs will provide an anticipatory instrument

[27]

to manage the issues related to
failing projects early enough.

Managing
EWSs of failures
will help to reduce future efforts and sav
e time and
money for clients as
well as vendors
. EWSs will provide a framework to manage uncertainties in the early project s
tages
(see Figure 1
), especially in the offshore project environment where the risk
s are higher.
The effort
and intensity that go i
nto the
early planning
stages will reduce the number of changes that a
re required
after the development stages. This is because

corrective actions in the critical early project stages are
cheaper than the costly recovery measures in

the later stages [14, 2
8] as reworking on the system and
retesting it
will increase the project
efforts,
costs and time.


Among the three major empirical works that studied the concept of EWSs [21, 24, 28]
, two studies
[21, 24] concentrated on IT projects, whereas one study [28]

was based on industrial construction

Page
6

of
16

projects.

As opposed to the
works
that studied
EWSs during
the whole project life cycle

[24, 28]
,

Kappelman et al.’s work that is central to this research work [21]

studied the first 20 percent of the
project lifecycle.

These early project stages are relevant as the management of the EWSs in the early
stages would still allow the projects to complete within the original estimates, provided corrective
actions are take
n.

T
he concept of EWS that could help to avoid project failures in

the offshore environment is highly
relevant because of the higher risks involved in OSD projects than domestic projects.
The early stages
of offshore projects with high degree of uncertai
nties provide the
key to explain the EWSs of project
failures.

We study the EWSs of failures in ODS projects in this exploratory work and answer the
following research questions:

1.

What are the most important EWSs of failures specific to offshore software de
velopment projects?

2.

What are the causes of the EWSs specific to offshore software development projects?

3
. RESEARCH METHODOLOGY


W
e chose Delphi survey as the research method to answer our research questions

as it is the most
appropriate method considerin
g the ranking nature of the research questions as well as the exploratory
nature of the study
. This su
rvey method allows us to find the

EWSs
of failures
specific to OSD
projects and further generate the most important EWSs. As no single expert can possibly

generate all
the relevant EWSs related to OSD projects, the panels of experts will be in a better position to produce
a comprehensive list of EWSs

[29]
. We chose two expert panels for clients and ven
dors as these
stakeholders are
equally

important for the outcome of offshore

project
s.
Two
expert
panels of
clients
and vendors

can leverage their

years of experience in OSD

projects

and provide their input to elicit

the
EWSs specific to OSD projects
.

We employ ranking
-
type Delphi survey

[30]
to elicit the
offshore specific EWSs of
software
project

development

failures and to rank the most relevant ones. This method also allows us to provide
statistical analysis o
f the concensus among the panel
i
sts and make

comparisons between the two
expert pa
nels. The data regarding the EWSs are solicited by senior executives and project managers
(experts) with years of experience in the offshore software development environment.
We contacted
68

experts
by e
-
mail
f
rom the client and vendor sides

primarily from

the companies based or operating
in Switzerland and India, which are involved in
OSD projects
.
Out of 32 positive responses, we
selected 23 panel experts

with a minimum experience of 2 years in OSD projects

for this study. The 12
panel experts from the cl
ient side and 11 pan
el experts from the vendor side

had average OSD project
experiences of 7.2 and 8.5 years respectively. The client and vendor panel experts experienced on
average
2.3 and 1.1 OSD

project failures in their careers respectively.


Page
7

of
16

Figure 2

provides an overview of the four phases involved in our Delphi survey. In the first p
hase of
the survey, we ask
ed the panel experts to

list
all possible EWSs of
failures in
ODS project
s

based on
their career experience
. We also provided top 12 EWSs identif
ied
by Kappelman et al. [21]
, which
allowed the consideration of a maj
or work (not specifically in the
offshore development environment)
about EWSs in their inputs. In the second phase, which is progressing, the EWSs identified by the
clients and vendors a
re consolidated and the panel experts are asked to rate each EWS of project
failures according to its importance.
In the third phase, the experts will be asked to compare the
average ratings of each EWS with their own inputs and revise the rating if requi
red. This phase will
allow us to provide the ranking of EWSs based on statistical analysis. Further, we will compare the
responses of clients and vendors, and analyse the importance of the EWSs and their causes (Research
question 2) from the client and ven
dor perspectives in the unique onshore
-
offshore project
environment. The panelists will validate and provide feedback about the findings in the fourth post
-
Delphi feedback phase.

Phase
1
:
Identification of
EWSs
(
completed
)
Phase
2
:
Consolidation
and rating of
EWSs
(
in progress
)
Phase
3
:
Ranking and
comparison of
EWSs
Phase
4
:
Post
-
Delphi
feedback and
validation

Figure
2
: Delphi
survey phases

4
.
CATEGORIZATION OF EWSs

The client and vendor panel experts identified 35 and 48 EWSs of failures in the
first phase of
the
Delphi survey respectively. Analysis of the lists of EWSs of failures identified by clients and vendors
revealed similar patterns between them, which facilitated the categorization of EWSs by the distinct
characterisitics of OSD projects. The four cate
gories of EWSs are related to culture, knowledge
management, formal project management and informal project management. The categorized EWSs
that are identified by clients and vendors are listed in tables 1 and 2 respectively. Many EWSs
identified by panel
ists also appear as the causes of failures, which is consistent with the earlier studies
[24, 28]
. This results since the causes of problems will manifest as warning signs as the project
progresses. We will not provide a detailed discussion about each EWS
and its causes of failure in this
paper, which will be done after the third phase of the survey.

Culture
: Hofstede’s
seminal work

[31]

about cultural orientiations
explained the individual
-
level
cross
-
cultural differences in terms of cultural dimensions su
ch as power distance, individualism,
masculinity, and uncertainty avoidance
, which is important to explain the EWSs in the OSD project
context.
The
se cultural differences

of
project team members affect
communication, coordination and

Page
8

of
16

control in offshore pr
ojects

[32
-
34]
. The approaches and attitudes of team members from different
countries
,

who lack ‘cultural intelligence’

[35]

will

affect the project outcome.

Culture
-
related issues result from the lack of openness and transparency among team members to
d
iscuss problems (clients #1, vendors #3
1
), and the lack of cultural intelligence among team members
(clients #4, vendors #4). These cultural differences will show up as communication difficulties
between onsite and offshore team members during the project
(clients #3, vendors #1), less or no
questions being asked by vendor team members (clients #2) and the tendency to say ‘Yes’ (or the
reluctance

to say ‘No’) by offshore vendors (clients #5, vendors # 2).

Knowledge management
:

The
management
and transfer
of

knowledge in OSD projects are crucial for
successful outcome
[2]
.
Apart from the formalized technical and business knowledge that should be
mastered by offshore and onsite teams, tacit, informal and background knowledge are equally
important [2].

Knowled
ge management issues typically originate from the lack of business knowledge (clients #7,
vendors #6) and technical skills (clients #8, vendors #8), and the overload of subject matter experts
(clients #9, vendors #7). These problems surface with vendor tea
m members crosschecking
problems
with several client team members

(clients #6) and generally large amount of communication over E
-
mail (vendors #5) or telephone (vendors #10).

Formal
/informal

project management
: The management of both the formal and informal project
management measures are necessary to avoid failures because of the cultural, geographical and
linguistic distances between the team members of clients and vendors. These distances affect the
communic
ation, control and supervision, coordination, creation of social bonds and trust building in
OSD projects [36]. Several studies [33, 35] have shown the relevance of differentiated formal/informal
control mechanisms on the outcome of OSD projects.

Formal p
roject management measures are formally documented and prespecified, whereas informal
ones are less prespecified and unwritten [37]. Both these control measures in the team and individual
levels will influence the outcome of projects [35]. Formal project m
anagement measures include the
explicit project management processes, roles, responsibilities, documentation etc. and informal project
management measures include the implicit and unwritten group norms, values and expectations [37].
The intangible and info
rmal project management measures become particularly important in the OSD
project context as not every team member may meet all the dispered team members during the
offshore project lifecycle. Especially, the informal project management measures like infor
mal
‘corridor talks’ and spontaneous conversations that have influence on trust building and mutual
understanding among team members in the early project stages are missing in the globally distributed
software development scenario.





1


Clients #1‘
refer
s

to
EWS number 1 identified by clients in table 1 and ‘Vendors #3’ refers to EWS number 3
identified by vendors in table 2


Page
9

of
16

Troubles related to fo
rmal project management typically result from process issues such as the lack of
documented requirements (clients #12, vendors #15), unfrozen project scopes (clients #13, vendors
#28), ineffective schedule planning and management (clients #13, vendors #24)
, and lack of change
control processes (clients #26, vendors #34). Further, unclear roles and responsibilities (vendors #18),
underestimation of project efforts (vendors #29, 31), unclear business specifications (vendors #35),
wrong offshore
-
onshore organi
zational structures (vendors #36) also cause severe project troubles.
Troubles related to formal project management that typically result from people issues are the lack of
top management support and commitment (clients #16, vendors #22), high turn
-
over am
ong vendors
(clients #20, vendors #32) and missing stakeholder involvement and participation (clients #25, vendors
#23). Technology issues that cause troubles include the use of new technology (client #24), the use of
wrong technology (vendors #24) and ins
ufficient technical support for old technology (clients #25).

The formal project management problems will largely manifest when intermediate deliverables are
missing or late (clients #17), adequate feedback is missing from the offshore team (clients #21),

the
team consecutively fail to meet milestones/deadlines (vendors # 11), and too many
meetings/conference calls produce no visible progress (vendors #40).

Informal OSD project management related troubles typically originate from the misunderstanding of
r
equirements by the offshore team (vendors #48),
and
the weak commitment of team members to the
project scope and schedule (clients #33, vendors #47).
Further, the lack of efficient communication
between offshore and onsite team members (clients #30, 32, 34
, vendors #44) and the movement of
key project members to other projects (vendors #45) affect the project outcome. These problems show
up when the promises made by vendors that are known to the client as illusionary from the start are
not met (clients #30)
, the project manager fail to efficiently lead the team members (clients #35) and
the team members start to lose active interest or motivation in the project (vendors #42, 46).

Culture
-
related EWSs


1. Lack of open admission/communication about
problems/de
lays

2. No questions asked by vendor team members

3.
Communication difficulties between onsite and
offshore team members

4. Lack of cultural understanding among team
members

5. “Yes” syndrome of vendors


Knowledge management related EWSs


6. Vendor team
members cross
-
check problems
with several client team members

7. Project team members do not have required
business knowledge

8. Project team members do not have required
technical skills

9. Subject matter experts are overloaded


Formal project management

related EWSs


10. Review efforts start to increase
(exponentially)

11. Non
-
fulfillment of standard software
development guidelines by vendors

12. Lack of documented requirements

13. Project scope not clearly defined or changes
Informal project
management related EWSs


30. Lack of efficient communication (matrix
organization)


31. Promises known to the client from the start as
illusionary not met


32.
Onsite coordinator cannot communicate
effectively with the offshore team members


Page
10

of
16

constantly

14. Performa
nce problems based on Earned Value
Management technique

15. Lack of top management support and
commitment

16. Ineffective schedule planning and/or
management

17. No or late intermediate deliverables

18. Serious quality issues in deliverable items

19. Not fulfilling key assignments

20. High turn
-
over rates among vendors

21. Lack of adequate feedback from the offshore
team

22. Constantly shifting milestones

23. Failure to make right project estimates with
new technologies

24. Use of new te
chnologies

25. Stakeholder involvement and participation is
missing

26. No change control process

27. Resources assigned to a higher priority project

28. Many items on the risk log

29. No clear ownership of the open issues


33. Project t
eam members have weak
commitment to the project scope and schedule


34. Lack of communication between clients and
vendors


35. Project manager cannot effectively lead the
team



Table
1
:
EWSs of failures
identified by clients

Culture
-
related EWSs


1. Communication difficulties between onsite and
offshore team members

2. “Yes” syndrome of vendors

3. Lack of transparency and openness to discuss
problems

4. Lack of cultural understanding among team
members


Knowledge management r
elated EWSs


5. E
-
mail “ping
-
pong” between offshore and
onsite team members

6. Project team members do not have required
business knowledge

7. Subject matter experts are overloaded

8. Project team members do not have required
technical skills

9. Offshore d
evelopers struggle to understand the
application

10.
Many phone calls from the offshore team to
the onsite team about the application



Formal project management related EWSs


11. Consecutive failure to meet
milestones/deadlines

12. Deliverables do not seem to make sense

13. Clients do not provide feedback on time

14. Clients do not know what to get out of the
project

15. Lack of documented requirements

16. Client has no change control process

17. No business case for th
e project

18. Unclear roles and responsibilities

19. Issues not resolved in a reasonable time

20. Unsolved issues and further escalation of
issues

21. No follow
-
up from clients

Informal project manage
ment related EWSs


42. Client losing active interest in project


43. Project manager cannot effectively lead the
offshore team and communicate with clients

44. Lack of communication between clients and
vendors


45. Movement of key project members to other
projects


46. Low interest and/or sinking motivation of
team members in the project


47. Project team members have weak
commitment to the project scope and schedule


48. Misunderstanding of requirements by th
e
offshore team




Page
11

of
16

22. Lack of top management support and
commitment to the project

23
. Stakeholder involvement and/or participation
missing

24. Ineffective schedule planning and/or
management

25. Use of wrong technology

26. Milestones and deliverables not clearly
defined

27.
Insufficient technical support for obsolete
technology

28. Project scope not clearly defined or changes
constantly

29. Underestimation of project efforts

30. Proposal based on currently unavailable
technological
features

31. Tight offshore project schedule

32. High attrition rates among vendors

33. N
o quality assurance procedures in place

34. No change control process

35. Unclear and ambiguous business
specifications

36. Project organization structures (onsite,
offshore, clients) do not match

37. Degree of uncertainty and volatile
requirements


38. Likelihood of a project shutdown because of
market problems

39. Resources assigned to a higher priority project

40. Too many meetings/conference calls

without
making any visible progress


41. Pace of progress very slow

Table
2
:
EWSs of failures
identified by vendors

5
.
DISCUSSION AND CONCLUSIONS

The results from the first phase of this Delphi survey are premature to draw any major conclusions as
we aimed to identify all the possible EWSs of failures in the first phase. The vendor panel experts
identified 48 as opposed to 35 found by client panel e
xperts. This difference could result from more
OSD project experiences

of vendor panel experts (average of 8.5 years versus clients’
7.2

years
), even
though there was one panelist less for vendors (11 versus clients’ 12).

This survey aims to find out the

most important EWSs of failures specific to OSD projects.
Surprisingly, only 9 out of 35 (26%) EWSs of failures identified by clients and 11 out of 48 (23%)
EWSs of failures identified by vendors are specific to OSD projects. These results suggest that th
e
non
-
offshore specific EWSs of failures still remain highly relevant and can endanger OSD projects as
in domestically outsourced software development projects. The seeding of the first survey phase with
12 EWSs of failures [21] has an effect on the result
s; however, its effect is not quite significant. Only

Page
12

of
16

the third phase of this survey can provide the real proportion of offshore and non
-
offshore specific
EWSs of failures.

Among the nine offshore
-
specific EWSs identified by clients, four were culture
-
rel
ated (#1, 3, 4, 5),
one was knowledge management related (#6), two were formal project management related (#20, 21),
and two were informal project management related (#30, 32). And among the eleven offshore
-
specific
EWSs identified by vendors, three were c
ulture
-
related (#1, 2, 4), three were knowledge management
related (#5, 9, 10), three were formal project management related (#31, 36, 40), and two were informal
project management related (#43, 48). The presence of offshore
-
specific EWSs in each EWS categ
ory
for clients and vendors justify our EWSs categorization for OSD projects. Culture
-
related EWSs was
the most dominant offshore
-
specific EWSs category identified by clients. The vendors identified equal
number of offshore
-
specific EWSs of failures in the

categories culture, knowledge management and
formal project management.

Interestingly, most of the EWSs are in the formal project management category


20 out of 35 (57%)
identified by the client expert panel and 31 out of 48 (65%) identified by the vendo
r expert panel.
These high numbers of EWSs of failures identified by panel experts suggest the necessity of formal
and structured processes to avoid project failures in OSD projects.

The EWSs of failures provide an
anticipa
tory framework

that could improv
e project performance and
thus save significant amount of resources and efforts in the unique
OSD

project context.

The ratings of
offshore
-
specific EWSs of failures in the later phases of this survey will be the key to explain their
relevance in OSD
projects. A detailed analysis about the EWSs and their direct causes will be made
once the rankings of EWSs are completed in the third phase of this survey.


Page
13

of
16


REFERENCES

[1] Hirschheim, D. (2006), Offshore outsourcing: challenge to the information systems

discipline, in
Information systems outsourcing


enduring themes, new perspectives and global challenges,
Hirschheim,D., Heinzl, A. & Dibbern, J. (eds), Springer, Berlin.

[2]

Sahay, S., Nicholson, B. & Krishna, S. (2003),
Global IT outsourcing
, Cambridge

university
press, Cambridge.

[3]

Aspray, W., Mayadas, F. & Vardi, M. (eds) (2006),
Globalization and offshoring of software
,
ACM, Viewed 25 December 2008, <

http://www.acm.org/globalizationreport/pdf/fullfinal.pdf
>

[4]

McCarthy, J. (2007),
The state of development of the IT services global delivery model,
Forrester
Research Inc., Cambridge.

[5] Iacovou, C. & Nakatsu, R. (2008), A risk profile of offshore
-
outsourced development projects,
Communications of the ACM
, Vol. 51, No. 6,
pp. 89
-
94,
June 2008.

[6] Optaros (2007),
IT Development Offshoring in Switzerland: Myth versus reality
, Optaros white
paper.

[7] Standish Group (1995),
CHAOS Report
, The Standish Group International Inc., Viewed 25
December 2008, < http://www.projectsmart.co.uk/docs
/chaos
-
report.pdf>.

[8]
McManus, J. & Wood
-
Harper, T. (2007),
Understanding the sources of info
rmation systems
project failure
,
Management services
, Autumn 2007, pp.38
-
43.

[9]

Pinto, K. & Mantel, S. (1990), The causes of project failure,
IEEE transactions
on engineering
management,

Vol. 37, No. 4, pp. 269
-
276.

[10]
Dibbern, J., Goles, T., Hirschheim, R. & Jayatilaka, B. (2004),
Information systems outsourcing:
a survey and analysis of the literature,
The DATA BASE for advances in information systems
, Vol.
3
5, No. 4,
pp. 6
-
102,
Fall 2004.

[11]
Gonzalez, R., Gasco, J. & Llopis,J. (2006), Information systems outsourcing: a literature analysis,
Information & Management
, Vol.

43,

No. 7,

pp. 821
-
834.

[12]
Barthelemy, J. & Geyer, D. (2001), IT outsourcing: evidenc
e from France and Germany,
European management journal,
Vol. 19, No. 2,

pp. 195
-
202,

April 2001.

[13]
Sparrow, E. (2003),
Successful outsourcing: From choosing a provider to managing the project
,
Springer, London.


Page
14

of
16

[14]
Ewusi
-
Mensah, K. (2003),
Software
development failures
, MIT Press, Cambridge.

[15]
Ewusi
-
Mensah, K. & Przasnyski, Z. (1991), On Information Systems Project Abandonment: An
Exploratory Study of Organizational Practices,
MIS Quarterly
, Vol. 15, No. 1, pp. 67
-
86.

[16]
Brooks, F. (1986), No si
lver bullet, in
The mythical man
-
month,

2nd edn, Addison
-
Wesley.

[17]

Hoch, D., Roeding, C., Purkert, G., Linder, S. & Müller, R. (2000),
Secrets of software success
,
Harvard business press, Boston.

[18]
Apte, U. & Mason, R. (1995), Global disaggregation
of information
-
intensive services,
Management science,
Vol. 41, No.7,
pp. 1250
-
1262,
July 1995.

[19]
Heeks, R., Krisha, S., Nicholson, B. & Sahay, S. (2001), Synching or sinking: global software
outsourcing relationships,
IEEE software,
Vol. 18, No.2, pp. 54
-
60,
March/April 2001.

[20]
Dibbern, J., Winkler, J. & Heinzl, Armin (2008), Explaining variations in client extra costs
between software projects offshored to India.
MIS Quarterly,
Vol. 32, No. 2,

pp. 333
-
366,

June
2008.

[21]
Kappelma
n, L., McKeeman, R. & Zhang, L. (2006),
Early warning signs of IT project failure:
The dominant dozen,
Information systems management
,
Vol.23, No.4, pp 31
-
36, Fall 2006.

[22]
Ward, L. (2003), Recognizing project warning signs.
ESI International,

Viewed 25
December
2008, <http://www.esi
-
intl.com/public/publications/122003executivewarningsigns
.asp>

[23]
Cule, P., Schmidt, R., Lyytinen, K. & Keil, M. (2000), Strategies for heading off IS project
failure,
Information systems management,
Spring 2000.

[24]
Havelk
a, D. & Rajkumar, T. (2006), Using the troubled project recovery framework: problem
recognition and decision to recover,
E
-
Service journal,

Vol. 5, No. 1,
pp. 43
-
73, Fall 2006.

[25]
Keil, M
.

& Montealegre, R
.

(
2001
)
, Cutting your losses: extricating your
organization when a big
p
roject goes awry
,
Sloan management review,
Vol. 43, No.3, pp. 55
-
68,
Spring 2001.

[26]
Smith, J. (2001), Troubled IT projects.
The Institution of Electrical Engineers
, London.

[27]
Nikander, I., and Eloranta, E. (2001), Project man
agement by early warnings,
International
journal of project management,
Vol. 19,
No. 7,
pp. 385
-
399.

[28]
Flowers, S. (1996),
Software failure: management failure
, John Wiley & Sons, Chichester.

[29]
Kasi, V., Keil, M., Mathiassen, L. &

Pedersen, K. (2008),
The post mortem paradox: a Delphi
study of IT specialist perceptions,
European journal of information systems,
Vol. 17, No. 1, pp.
62
-
78.


Page
15

of
16

[30]
Schmidt, R. (1997), Managing Delphi survey using nonparametric statistical techniques,
Deci
sion
sciences,
Vol. 28, No. 3,
pp. 763
-
774, Summer 1997.

[31]
Hofstede, G 1984,
Culture's consequences
, Abridged edition,
SAGE Publications.

[32]
Krishna, S., Sahay, S. & Walsham, G. (2004), Managing cross
-
cultural issues in global software
outsourcing,
Communications of the ACM
, Vol. 47, No.4, pp.62
-
66.

[33]
Narayanaswamy, R. & Henry, R. (2005), Effects of culture on control mechanisms in offshore
outsourced IT projects, in
Proceedings of the 2005 ACM SIGMIS CPR conference on Computer
personnel research
.

[34]
Gefen, D. & Carmel, E. (2008), Is the world really flat? A look at offshoring at on online
programming marketplace,
MIS Quarterly
, Vol. 32, No. 2, pp. 367
-
384, June 2008.

[35]
Beck, R., Gregory, R. & Prifling, M. (2008), Cultural intelligence and pro
ject management
interplay in IT offshore outsourcing projects, in
Proceedings of the International Conference on
Information Systems,
Paris, December 2008.

[36]
Carmel, E. & Abbott, P. (2006), Configurations of global software development: offshore versus
nearshore, in
Proceedings of the 2006 international workshop on Global software development
for the practitioner
, International Conference on Software Engineering.

[37] Kirsch, L. (2004), Deploying common systems globally: the dynamics of control,
Informat
ion
systems research,
Vol. 15, No. 4, pp. 374
-
395, December 2004.


Page
16

of
16



LIST OF FIGURES

Figure 1:
Upstream
-
downstream framework

--------------------------------
--------------------------------
-----------

4

Figure 2: Delphi survey phases

--------------------------------
--------------------------------
----------------------------

7


LIST OF TABLES

Table 1:
EWSs of failures
identified by clients

--------------------------------
--------------------------------
------

10

Table 2:
EWSs of failure
s
identified by vendors

--------------------------------
--------------------------------
----

11