University of Zurich · Early warning signs of failures in offshore software development projects...

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.

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

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

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]

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]

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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

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

University of Zurich · Early warning signs of failures in offshore software development projects...

Documents

Transcript of University of Zurich · Early warning signs of failures in offshore software development projects...