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 1 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.
Software 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 an 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 India. We compare the
EWSs of failures identified by client and vendor panel experts in the first survey phase. Four offshorerelevant EWS categories are presented in this paper, namely, culture, knowledge management, formal
project management and informal project management.
Keywords: Offshoring, Global software development, Project failure, Delphi survey, Early warning
sign, Project management
Page 2 of 16
1. INTRODUCTION
The increased globalization and the resulting emergence of a global IT market have made IT
offshoring 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 currently 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 rate in the next five years and this growth will largely come from applications
development 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 software 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 definition of project failure [9].
Review of IT outsourcing literature shows 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 we 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 project team’s failure
to deliver operational information system to the users. The project team in offshore software
development (OSD) projects includes client and vendor 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 ‘impaired’ 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 requires
intensive coordination and control throughout the development stages. Ewusi-Mensah’s [14]
Page 3 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 factors.
Success 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
intensity, 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 offshore-related risks, such as, cultural, linguistic
and time-zone differences, communication difficulties, and knowledge transfer complexities [2, 19,
20].
Uncertainty from the project start is another characteristic of software development projects that
makes 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 (Figure 1), which they refer to as ‘upstream
phase’. The high uncertainties result because of unclear customer requirements, not entirely
predictable design, changing requirements and changing technology. The uncertainty gradually
reduces as the project progresses towards the later stages or the ‘downstream phase’. For the
companies that engage in offshore projects with low organizational project maturity, the degree of
uncertainty will be even higher.
Degree of uncertainty
Requirements analysis
Downstream phase
Design
Coding
Integration and testing
Maintenance
Upstream phase
Time
Figure 1: Upstream-downstream framework [17, p. 98]
2. EARLY WARNING SIGNS
Page 4 of 16
Although there is no silver bullet to overcome the poor performance of software projects [16], the
postmortem examinations done at failed IT projects showed that before failures happened, there were
significant symptoms, indications or warning signs of trouble in the early project stages [21]. An early
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 leveraged for better project outcomes.
Failures do not happen overnight [16] since they are dynamic and their ‘opportunities for occurrence
are both ever-present and cumulative’ [23, p. 72]. The project troubles before the failure are hardly
detected early enough in the IT industry [24]. Identifying and managing those troubles provide an
effective solution to save project efforts. In order to put the troubled projects back on track, an early
warning control mechanism seems to be necessary, especially in the early project stages. Keil and
Montealegre [25, p. 65] have recommended the following:
At the earliest possible stage, managers need to ask themselves whether any “red flags” … 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 stages 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 whole project life cycle, the management of
EWSs of failures focuses on risks that should 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 save time and money for clients as
well as vendors. EWSs will provide a framework to manage uncertainties in the early project stages
(see Figure 1), especially in the offshore project environment where the risks are higher. The effort
and intensity that go into the early planning stages will reduce the number of changes that are 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, 28] 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 5 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 taken.
The 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 uncertainties 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 development projects?
2. What are the causes of the EWSs specific to offshore software development projects?
3. RESEARCH METHODOLOGY
We chose Delphi survey as the research method to answer our research questions as it is the most
appropriate method considering the ranking nature of the research questions as well as the exploratory
nature of the study. This survey 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 vendors as these
stakeholders are equally important for the outcome of offshore projects. 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 of the concensus among the panelists and make comparisons between the two
expert panels. 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 from 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 client side and 11 panel 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 6 of 16
Figure 2 provides an overview of the four phases involved in our Delphi survey. In the first phase of
the survey, we asked the panel experts to list all possible EWSs of failures in ODS projects based on
their career experience. We also provided top 12 EWSs identified by Kappelman et al. [21], which
allowed the consideration of a major 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 are 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 required. 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 vendor perspectives in the unique onshore-offshore project
environment. The panelists will validate and provide feedback about the findings in the fourth postDelphi 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 categories 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 panelists 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 such as power distance, individualism,
masculinity, and uncertainty avoidance, which is important to explain the EWSs in the OSD project
context. These cultural differences of project team members affect communication, coordination and
Page 7 of 16
control in offshore projects [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
discuss problems (clients #1, vendors #31), 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].
Knowledge 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 team members crosschecking problems
with several client team members (clients #6) and generally large amount of communication over Email (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
communication, 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 project 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 management 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 informal 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 informal
‘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‘ refers 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 8 of 16
Troubles related to formal 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 organizational 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 among 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 insufficient 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
requirements 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
Knowledge management related EWSs
1. Lack of open admission/communication about
problems/delays
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
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
Informal 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
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 9 of 16
constantly
14. Performance 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 technologies
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 team 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
Knowledge management 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
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 developers 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
Informal 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 the 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
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 the
offshore team
Page 10 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. No 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 experts. 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 the
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 results; however, its effect is not quite significant. Only
Page 11 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-related (#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 culture-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 category
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 vendor 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 anticipatory framework that could improve 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 12 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 information 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.
35, 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: evidence 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 13 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 silver 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] Kappelman, 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] Havelka, 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
project 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 management 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 14 of 16
[30] Schmidt, R. (1997), Managing Delphi survey using nonparametric statistical techniques, Decision
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 project 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, Information
systems research, Vol. 15, No. 4, pp. 374-395, December 2004.
Page 15 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 failures identified by vendors -------------------------------------------------------------------- 11
Page 16 of 16