Upload
buitu
View
214
Download
0
Embed Size (px)
Citation preview
University of ZurichZurich Open Repository and Archive
Winterthurerstr. 190
CH-8057 Zurich
http://www.zora.uzh.ch
Year: 2009
Early warning signs of failures in offshore software developmentprojects
Philip, T; Schwabe, G; Wende, E
Philip, T; Schwabe, G; Wende, E (2009). Early warning signs of failures in offshore software development projects.In: Third Global Sourcing Workshop, Keystone, USA, 22 March 2009 - 25 March 2009.Postprint available at:http://www.zora.uzh.ch
Posted at the Zurich Open Repository and Archive, University of Zurich.http://www.zora.uzh.ch
Originally published at:Third Global Sourcing Workshop, Keystone, USA, 22 March 2009 - 25 March 2009.
Philip, T; Schwabe, G; Wende, E (2009). Early warning signs of failures in offshore software development projects.In: Third Global Sourcing Workshop, Keystone, USA, 22 March 2009 - 25 March 2009.Postprint available at:http://www.zora.uzh.ch
Posted at the Zurich Open Repository and Archive, University of Zurich.http://www.zora.uzh.ch
Originally published at:Third Global Sourcing Workshop, Keystone, USA, 22 March 2009 - 25 March 2009.
Early warning signs of failures in offshore software developmentprojects
Abstract
Increased globalization and the consequent dispersion of IT activities across the world have driven thegrowth of global IT outsourcing. The share of offshore software development (OSD) in the high-costcountries 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 theirinherent complexities and the uncertainties involved from the start. Although OSD projects offer costadvantages, the unique risks related to cultural, linguistic and geographic differences, knowledgetransfer and project management make OSD more vulnerable to failure than domestically outsourcedprojects. This paper explores the early warning signs (EWS) of failures in OSD projects, a concept thatcan be employed as an early warning system to avoid failures. Using the Delphi survey method, weintend to find out the most important EWSs specific to OSD projects. Our panelists include 23 expertsprimarily from the offshore client and vendor companies in Switzerland and India. We discuss fouroffshore-relevant EWS categories and the preliminary results of this ongoing research from the thirdsurvey phase.
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
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.
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 discuss four
offshore-relevant EWS categories and the preliminary results of this ongoing research from the third
survey phase.
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 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. The distinct
characteristics of offshore projects that make them more difficult to manage and the growing relevance
of offshoring call for more research to successfully manage offshore outsourced projects.
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 before the information system becomes
operational. The failure to deliver information system can happen at any development phase before
the system becomes operational. Cancellations of offshore software development (OSD) projects,
which have client and vendor team members that work at offshore and onshore sites, can result from
several project internal and external factors. 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 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, which can
be of technical, cultural, organizational, political, managerial, sociological, and economic natures.
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]. Hoch
et al.’s [17, p. 97] upstream-downstream metaphor illustrates how the inherent uncertainty follows the
project. In the early project stages, the degree of uncertainity will be higher in terms of the
deliverables, schedule, budget and other project parameters. This high uncertainity during the early
stages (figure 1) is referred to as ‘upstream phase’. They 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’, which will not completely disappear even after the information system becomes operational.
For the companies that engage in offshore projects with low organizational project maturity, 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-downstream framework [17, p. 98]
Page 5 of 16
2. EARLY WARNING SIGNS
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 in the critical early stages.
Managing EWSs of failures will help to reduce future efforts and thus 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 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.
Page 6 of 16
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
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 their high degree of uncertainties provide the key to explain the EWSs of
project failures. We study the EWSs of failures specific to ODS projects in this exploratory work and
answer the following research question:
What are the most important EWSs of failures specific to offshore software development projects?
3. RESEARCH METHODOLOGY
We chose Delphi survey as the research method to answer our research question as it is the most
appropriate method considering the ranking nature of the research question 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 consensus 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. Table
1 shows the average career experiences of the panelists. 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
Page 7 of 16
respectively. The client and vendor panel experts experienced on average 2.3 and 1.1 OSD project
failures in their careers respectively.
Panelist Experiences Clients Vendors
IT-related (years) 16.2 13.4
Project management (years) 10.1 8.5
OSD projects (years) 7.2 8.5
No of OSD project failures 2.3 1.1
Table 1: Client and vendor panelists
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. The 23 panelists have identified 44 EWSs in the first phase (see
appendix). In the second phase, the panelists were asked to validate the EWSs identified in the first
phase and choose their top 20 EWSs to narrow down the EWSs. This phase has resulted in 21 EWSs,
which was a manageable number for ratings in the third phase.
In the third phase, the client and vendor panel experts were asked to rate 21 EWSs of project failures
according to their importance. This phase, which is progressing, will continue until a consensus is
reached among the ratings of clients and vendors. The agreement among panelists will be measured
using Kendall’s coefficient W. 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 provide the rankings of EWSs
based on statistical analysis. Further, we will compare the responses of clients and vendors, and
analyse the importance of the EWSs 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 post-Delphi feedback phase.
Phase 1:
Identification of EWSs(completed)
Phase 2:
Validation and narrowing-down of EWSs(completed)
Phase 3:
Rating and comparison of EWSs(in progress)
Phase 4:
Post-Delphi feedback and validation
Figure 2: Delphi survey phases
Page 8 of 16
4. FINDINGS
The client and vendor panel experts selected 21 EWSs in the second phase of this Delphi survey,
which are being rated in the third phase. The first round of the third phase showed weak agreement
among the panel experts as the clients and vendors had the Kendall coefficients W of 0.34 and 0.27
respectively. In order to have a strong consensus among a group, the Kendall coefficient W should be
above 0.7 and the coefficient value between 0.5 and 0.7 signifies moderate consensus [30]. Therefore,
the survey will continue until a reasonable consensus will be reached.
The 21 EWSs of failures identified by clients and vendors in the second phase revealed similar
patterns between them, which facilitated the categorization of EWSs. We found four groups of EWSs
by subsuming particulars into more general categories [31]. The four groups of EWSs (see table 2) are
the following: communication- related, people-related, formal process related and formal output
related.
Communication-related EWSs: The cultural and geographical distances between the onshore and
offshore team members cause a lot of communication problems in OSD projects. Further,
communication in English, which is mostly not the native-language of the team members analyzed in
the survey, affects the communication and thus the knowledge transfer in projects. The different
cultural orientations [32] of project team members require different coordination and control strategeis
in offshore projects [33-35]. The approaches and attitudes of team members from different countries,
who lack ‘cultural intelligence’ [36] will lead to misunderstandings, especially when the opportunities
for informal communication are less in OSD projects. 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.
Communication-related EWSs issues result from the lack of transparency and openness to discuss
about problems/delays as well as the communication difficulties among team members, which mostly
result from different cultural orientations. Indian vendor team members may not ask questions openly
because of the importance of Indian team hierarchies. This can also cause misunderstandings among
project team members. The lack of effective communication possibilities is also an EWS of OSD
project failure. The communication limits of onsite coordinators and project managers also affect the
project outcome.
Page 9 of 16
People-related EWSs: Commitment and skill sets of project team members are cruical for successful
project outcome [21]. As weak project team members affect the progress of projects, the performance
of key project team members provides important EWSs of project failures.
People-related EWSs include project team members’ lack of business domain knowledge and
technical skills. The lack of top management support and the missing participation of the stakeholders
are further signs of projects heading for failures.
Formal process related EWSs: Formal project management processes will be indispensible to avoid
OSD project failures because of the cultural and geographical 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 [37]. Several studies [34, 36] have shown
the relevance of differentiated formal and 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 [38]. Both these control measures in the team and individual
levels will influence the outcome of projects [36]. 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 [38].
Troubles related to formal project management typically result from process issues such as unfrozen
project scopes, ineffective schedule planning and management, and lack of change control processes.
Further, unclear roles and responsibilities, consecutive failures to meet deadlines, issues not resolved
in reasonable time, and lack of quality assurance procedures in place result in critical issues that lead
to OSD project failures.
Formal output related EWSs: The issues related to the results of the formal project management
processes [39] provide indications about the direction to which the projects are heading. The failure to
deliver outputs or results by project members in the desired quality will lead to further troubles in
projects.
The typical formal output related EWSs show up as serious quality issues in deliverable items. This
can result from the lack of documented requirements as well as unclear and ambiguous business
specifications.
Page 10 of 16
Communication-related EWSs 1. Lack of transparency and openness to discuss about problems/delays 2. No questions asked by vendor team members 3. Communication difficulties between onsite and offshore team members 4. Onsite coordinator cannot communicate effectively with offshore team members 5. Lack of communication between clients and vendors 6. Project manager cannot effectively lead the offshore team and communicate with clients 7. Misunderstanding of requirements by the offshore team
People-related EWSs
8. Project team members do not have required business knowledge 9. Project team members do not have required technical skills 10. Lack of top management support and commitment to the project 11. Stakeholder involvement and participation are missing
Formal process related EWSs
12. Project scope changes constantly 13. Ineffective schedule planning and/or management 14. Consecutive failures to meet deadlines 15. No change control process in the project 16. Issues not resolved in a reasonable time 17. Unclear roles and responsibilities 18. No quality assurance procedures in place
Formal output related EWSs 19. Lack of documented requirements 20. Serious quality issues in deliverable items 21. Unclear and ambiguous business specifications
Table 2: 21 EWSs of failures after phase two
5. DISCUSSION
The results from the third phase of this Delphi survey are premature to rank the most important EWSs
of OSD project failures. It showed weak agreement among the panel groups of clients and vendors
with Kendall coefficients W 0.34 and 0.27 respectively. The better agreement among clients could be
because of longer IT career experience of client experts compared to vendor experts. These figures are
expected to increase in the following rounds as the average ratings of each EWS will be made
available to each panelist.
This survey aims to find out the most important EWSs of failures that are specific to OSD projects.
Surprisingly, only 6 out of 21 (29%) EWSs of failures were found to be specific to OSD projects. And
they were all communication-related EWSs (#1,2,3,4,6,7). 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 high proportion of EWSs in the formal project management related categories (10 out of 21 -
48%) show the relevance of formal control mechanisms to offset the disadvantages in terms of cultural
and geographical distances. It suggests the necessity of formal and structured processes to avoid
project failures in OSD projects.
Page 11 of 16
Most 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. Only 3 EWSs (#2, 14, 16) were found to be the pure indicators or events prior to
failure, which can be termed as shallow EWSs. The rest of the EWSs (18 out of 21) were found to be
the indicators or events prior to failure as well as causes of OSD project failures, which can be termed
as deep EWSs.
6. CONCLUSIONS
As this Delphi survey is still in progress, only the final results will reveal the most important EWSs of
failures specific to OSD projects. The relative importance of EWSs varies slightly between clients and
vendors because of their different perspectives in OSD projects. A comparison of the relevant EWSs
for clients and vendors will be made after the completion of this survey.
The relatively low number of EWSs specific to OSD projects (6 out of 21 - 29%) in the third phase
point out that the offshore projects are fundamentally not too different from domestic outsourced
projects. However, the higher proportion of formal project managemet related EWSs underline the
need for more structure and better planning to avoid OSD project failures.
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
importance in OSD projects. A detailed analysis about the EWSs will be made once the ratings of
EWSs are completed and validated at the completion 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.
[14] Ewusi-Mensah, K. (2003), Software development failures, MIT Press, Cambridge.
Page 13 of 16
[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] Miles, M. & Huberman, M. (1984). Qualtitative data analysis. Sage Publications.
[32] Hofstede, G 1984, Culture's consequences, Abridged edition, SAGE Publications.
[33] 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.
[34] 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.
[35] 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.
[36] 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.
[37] 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.
[38] Kirsch, L. (2004), Deploying common systems globally: the dynamics of control, Information
systems research, Vol. 15, No. 4, pp. 374-395, December 2004.
[39] Applegate, L., Austin, R. & McFarlan, F. (2003). Corporate information strategy and management, Third edition, McGraw Hill.
Page 15 of 16
APPENDIX
Early warning signs identified in the first survey phase
1. Lack of transparency and openness to discuss 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” mentality of vendors 6. Project team members do not have required business knowledge 7. Project team members do not have required technical skills 8. Subject matter experts are overloaded 9. E-mail “ping-pong” between offshore and onsite team members 10. Many phone calls from the offshore team to the onsite team about the application 11. Review efforts start to increase exponentially 12. Non-fulfillment of standard software development guidelines by vendors 13. Lack of documented requirements 14. Project scope changes constantly 15. Lack of top management support and commitment to the project 16. Ineffective schedule planning and/or management 17. Serious quality issues in deliverable items 18. High attrition rates among vendors 19. Lack of adequate feedback from the offshore team 20. Clients do not provide feedback on time 21. Consecutive failures to meet deadlines 22. Use of new technologies 23. Stakeholder involvement and participation are missing 24. No change control process in the project 25. Resources assigned to a higher priority project 26. Issues not resolved in a reasonable time 27. Unclear roles and responsibilities 28. Business case and prospects not known 29. Insufficient technical support for obsolete technology 30. Proposal based on technological features that will be available in the future 31. Tight offshore project schedule 32. No quality assurance procedures in place 33. Unclear and ambiguous business specifications 34. Project organization structures (onsite, offshore, clients) do not match 35. Likelihood of a project shutdown because of market problems 36. Too many meetings/conference calls without making any visible progress 37. Use of wrong technologies 38. Onsite coordinator cannot communicate effectively with offshore team members 39. Project team members have weak commitment to the project scope and schedule 40. Lack of communication between clients and vendors 41. Project manager cannot effectively lead the offshore team and communicate with clients 42. Project team members’ low interest and/or sinking motivation in the project 43. Movement of key project members to other projects 44. Misunderstanding of requirements by the offshore team
Page 16 of 16
LIST OF FIGURES
Figure 1: Upstream-downstream framework ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 4 Figure 2: Delphi survey phases ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 7
LIST OF TABLES
Table 1: Client and vendor panelists ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 7 Table 2: 21 EWSs of failures after phase two ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 10