International Management Review

Vol. 5 No. 1 2009

A Taxonomy of an IT Project Failure: Root Causes Walid Al-Ahmad1 , Khalid Al-Fagih2, Khalid Khanfar3 Khalid Alsamara4, Saleem Abuleil5, Hani Abu-Salem6 New York Institute of Technology1, Al Albait University2, Arab Academy for Banking and Financial Sciences3, Chicago State University4,5, University of South Carolina-Aiken6 [Abstract] This article explores the root causes of IT projects failure of various IT application domains. The primary focus is to address the various issues responsible for IT projects failure to understand the root causes of the failure. The literature review indicates that failure of IT projects can be attributed to six generic root causes, the main categories of the taxonomy. This study investigates the root causes of failure from two major areas: common factors of failure and specific causes existing, which generalize the taxonomy. The study concludes that any reason of IT project failure can be related to one of the six categories in the taxonomy independent of the application domain. [Keywords] IT project failure; taxonomy; root causes

Introduction Failure has been synonymous with many IT projects over the last four decades. Reasons for failure have been attributed to technological difficulties, organizational and functional problems, managerial issues, and many other reasons. Traditionally, a project should deliver agreed upon functionality on time and within estimated budget according to Keider (1974) and Saleh (2005). A comprehensive study conducted by Standish Group International in 1995, which included several thousands of IT project revealed that only 16% of those projects were finished on time, and within the estimated budget; 32% were terminated before they were completed, while the remaining 52% involved costs higher than the original estimates and were completed behind their schedule (Standish Group, 1994). Another study conducted in the UK by Oxford University and Computer Weekly in 2003 reported, strikingly, that only 16% of the IT projects reviewed were considered successful (Sauer & Cuthbertson, 2003). IT projects have been considered a tough undertaking and have certain characteristics that make them different from other engineering projects and increase the chances of their failure. Such characteristics are classified in seven categories (Peffers, Gengler & Tuunanen, 2003; Salmeron & Herrero, 2005): 1) abstract constraints which generate unrealistic expectations and overambitious projects; 2) difficulty of visualization, which has been attributed to senior management asking for over-ambitious or impossible functions, the IT project representation is not understandable for all stakeholders, and the late detection of problems (intangible product); 3) excessive perception of flexibility, which contributes to time and budget overrun and frequent requests of changes by the users; 4) hidden complexity, which involves difficulties to be estimated at the project’s outset and interface with the reliability and efficiency of the system; 5) uncertainty, which causes difficulty in specifying requirements and problems in implementation of the specified system; 6) the tendency to software failure, which is due to assumptions that are not thought of during the development process and the difficulty of anticipating the effects of small changes in software; 7) the goal to change existing business processes, which requires IT practitioners’ understanding of the business and processes concerned in the IT system and good processes to automate and make them quicker. Such automation is unlikely to make a bad process better.

93

International Management Review

Vol. 5 No. 1 2009

One can categorically observe that project management in most IT organizations currently ranges from undisciplined to chaotic. Few organizations are armed with the necessary infrastructure, education, training, or management discipline to bring project initiatives to successful completion. Research indicates that more than half of all IT projects become runaways--overshooting their budgets and timetables while failing to deliver the expected outcomes. Project management of complex IT projects is challenging, even when measures of success are known and understood. The practical management of IT projects finds significant difficulties as follows (Rodriguez-Repiso, Setchi & Salmeron): IT projects are often poorly defined, codes of practice are frequently ignored, and, in some cases, not many lessons are learned from past experience. Market pressures demand delivery in the shortest time frame even if they may result in a lower quality product. The rapid pace of technological progress in IT hinders the expertise in a particular technique and creates a culture where the use of tools not completely tested is acceptable and commonplace. IT projects contain a greater degree of novelty than other engineering projects. In particular, IT projects related to product innovation development are extremely complex, risky, and expensive (Cormican & O’Sullivan, 2004). This article looks at the IT project failure phenomena in three main IT domains: traditional information systems (database-oriented), Web-based systems, and healthcare informatics systems. Commonalities among various domains regarding the root causes of failure will be argued so that broad conclusions may be suggested to see whether each domain has its own failure peculiarity characteristics or not. It is worth mentioning that the taxonomy presented in this article is only interested in projects during development, not post development, though the article mentions some factors that are related to post development. The article starts with introduction and proceeds with the main objectives of this study, definitions of the success and failure criteria, and then presents a literature review, domain specific root causes, the taxonomy of the root causes and a discussion, as well as conclusions. Objectives and Importance of the Study There are myriad reasons that make projects in various IT application domains fail. This study focuses primarily upon problematic issues that impede the success of many IT projects in order to provide a better landscape for understanding why IT projects fail. In fact, the literature lacks up-to-date summaries of such phenomenon regarding different IT application domains. We also found little in the literature about a generic taxonomy of project failure causes. Most researchers, experts, practitioners, and academics strongly believe that IT projects fail regularly. Projects, by far, miss expectations, overrun budgets, miss their deadlines, and far too often have to be abandoned altogether. Everyone in IT domains perceives that such failures are, to some extent, attributed to reasons that are already known, but many reasons are yet to be explored. As a result, many people are seriously investigating a variety of areas to pinpoint those reasons. One fact that stands out clearly is that reasons for failure can be totally attributed to project management methodologies. Studies, so far, have identified over 50 reasons for failure. However, practicing good project management in IT projects has proven to be useful. Admittedly, there are substantial losses to industry every year from poor IT project management. It is no wonder, then, the risks associated with IT project have become a critical issue for executives around the world. The phenomenon of IT project failure, therefore, has become a relevant topic calling for investigation and further study. 94

International Management Review

Vol. 5 No. 1 2009

The high rate of failed IT projects has become a real and relevant concern of the business environment. Businesses are dissipating their resources on failed IT projects. More often, IT projects fail to achieve most of their intended purpose of increasing productivity, lowering operating costs, improving the quality of work product, and shrinking the time to market. The IT industry is, to some extent, young if compared to most other industries. Therefore, the IT industry has yet to formulate the needed operational standards and procedures. This implies, clearly, that the IT industry does not yet possess the clear sets of rules and definitions associated with project failure phenomenon. Only recently the problematic issue of IT project management has become a topic of concern within the IT environment. Therefore, literature on this issue has only commenced addressing and reporting on the problem of IT project failure. One qualifying issue that stands out clearly is the manifestation of the fact that failure, as a concept related to varying IT domains, has not been categorically defined, and no definition has yet been universally accepted. Such definition, however, is highly crucial to serve as a benchmark to measure the level of success of an IT project. Success and Failure Criteria Billions of dollars have been wasted on failed projects, and many highly expensive projects had to be shelved after a short time due to massive resistance from end-users. The cost of IT failure has skyrocketed in recent years as development projects have become more and more complex. The body of knowledge that resides in literature which addresses this phenomenon is enormous. A hundred or more factors attributed to projects’ failure have been identified. One of the issues is the way IT Project failure is conceptualized. IT project failure is defined as any project that is set to support the operations of an organization by exploiting the resources of information technology that fails to deliver the intended output within the originally allocated cost, time schedule, or initially-approved functionality, as well as the project comfortably satisfying the stakeholders and being accepted and largely used by the end users after deployment. In fact, there are many ways to measure success and failure, but there is no strict dividing line between the two. It may be almost impossible to find agreement about whether a project succeeded or failed. When trying to make sense of the ambiguity of notions of success and failure, it may be useful to view them as being subjective judgments. Beauty is in the eye of the beholder. For example, Naughton and Peters (1976) discusses system failures as concerns of human perception and identification, thereby acknowledging that one person’s failure might be another’s success. The notion that a project failed may mean that it did not meet certain people’s objectives or that it produced what were seen by some as undesirable outputs. The impact and consequences of the project may not be fully appreciated before implementation. Robinson (1994) points out that a project’s failure or success is defined in relation to a particular group with its own roles, goals, interests, and expectations, which are assessed in the context of an organization and its political and social environment. Ewusi-Mensah (1997) states that IS projects are unique in that they are conceptual in nature and require the intense collaboration of several different groups of stakeholders, including IS staff, users, and management. IS projects are usually undertaken in teams and, therefore, are subject to the vagaries of group dynamics, interactions, coordination, and communication. The diverse backgrounds and training of the various team members and other people associated with the project make the ability to communicate and coordinate the activities of the group extremely important. 95

International Management Review

Vol. 5 No. 1 2009

Kelly (2003) argues, rather provocatively, that “There is no such thing as a computer project. There are business change projects that involve IT. For projects to be successful, they must consider the people dimension, explaining what is entailed, motivating and training staff and making them aware that productivity will initially fall with the move from the old to the new way of doing things.” The high failure rate for the implementation of information technology projects is a world-wide phenomenon. Admittedly, information technology projects have unique characteristics that make them fragile against collapse. Project managers can never be sure how to position themselves in order to reduce the possibility for project failure because there are no scientific formulations that can be used as guides. However, some broad generalizations and recommendations have been suggested so that project managers can, to some extent, help them shrink the probability of project failure. Unlike other engineering projects, an IT application, once it has been developed and handed over to the exploitation team or packaged for commercialization, will not only have to be further maintained but it will also have to be enhanced, extended, and adapted to new or changing platforms. In the IT world, there is no such thing as a final product. The only way to make it final is to dispose of it. Literature Review There is a large number of studies written to pinpoint the causes of IT project failure. A vast number of recognized risk factors that have been identified to be responsible for IT project failure phenomena, including those concerning project leadership and management, organizational culture and structure, commitment and patterns of belief, user involvement and training, developer expertise, technology planning, scope and objectives setting, estimation and choice/use of methodology McFarlan (1981) and Cusing (2002). Many believe that the CHAOS report presented by Standish Group (1995) had struck the IT community by surprise because it had reported the unknown sad status of the IT project. As a result, the report was considered the landmark study of IT project failure. The Standish group made an extensive study in the US, which included large, medium, and small organizations across major industry segments: banking, healthcare, retail, wholesale, services, manufacturing, insurance, securities, and local and federal organizations. One of the most extensive studies that were deployed to study the root causes for IT project failure was conducted by group of researches (Schmidt, Lyytinen, Keil & Cule, 2001) on experienced project managers in three different settings: Hong Kong, Finland, and the United States. The three panels of experts identified initially a list of 53 IT project risk factors. The list was reduced to a set of 17 through ranking and paring down processes, as shown below: • • • • • • • • • • 96

Lack of top management commitment to the project Misunderstanding the user requirements Not managing change properly Failure to gain user commitment Lack of adequate user involvement Conflict between user departments Changing scope and objectives Number of organizational units involved Failure to manage end-user expectations Unclear / misunderstood scope and objectives

International Management Review

• • • • • • •

Vol. 5 No. 1 2009

Improper definitions of roles and responsibilities Lack of frozen requirements Introduction of new technology Lack of effective project management skills Lack of effective project management methodology Lack of required team knowledge / skills Insufficient / inappropriate staffing

Field (1997) analyzed pitfalls in IT project development efforts that resulted in establishment of a list of 10 signs of IT project failures, of which seven are fully determined before a design is developed or a line of code is written. The 10 signs of IT project failure are project managers don’t understand users’ needs; the project’s scope is ill-defined; project changes are managed poorly; the chosen technology changes; business needs change; deadlines are unrealistic; users are resistant; sponsorship is lost; the project lacks people with appropriate skills; managers ignore best practices and lessons learned. A leading research was conducted by Johnson (2001) who indicated that the success rate of IT projects actually increased since the emergence of the first Standish CHAOS report. This is, according to Johnson, attributed to the fact that project people using the Standish “Recipe for Success” that was established in 1998. Johnson reported that the overall project success had increased from 16% in 1994 to 28% in 2000. Johnson identified five factors that could hamper the IT project success. The first factor is the lack of executive support, which can and does jeopardize projects. The second factor is the lack of user involvement, which has been traditionally one of the main reasons for project failures. Johnson proposed that project professionals must handle these issues with extreme care to reduce their negative effect on project progression. The next factor is the experienced project manager, which seems to play a pivotal role in reducing the probability of the failure of the project. Johnson reported in his analysis that ninety-seven percent of successful projects had been managed by an experienced project manager. The fourth is the ever-important factor that has been reported by many researchers to be of paramount importance for making the project achieving its intended functionality with the estimated time and schedule: clear business objectives. The lack of them always push the project to overshoot time, functionality, and cost. Better control of objectives is normally attributed to experienced project managers. The last factor is a minimized scope, which prevents the scope from getting bigger and bigger. Johnson claimed that the minimized scope had replaced small milestones, which was considered an important factor in early studies. An investigative study was carried out by Coverdale Organization Fichter (2003) to reveal the root causes for project failure phenomenon. Seven major factors were reported to play a tremendous role in putting an IT project in trouble. Poor planning was spotted as having a negative effect on IT project success. In most cases, IT managers are not given the opportunity to focus more on planning due to time pressure from senior management, so the project starts before it has been clearly defined (New Zealand Management, 2003). The second factor is the unclear goals and objectives, where, sometimes, the goal of a project may be only somewhat clear due to a poor gathering of requirements in the initiation stage of the project (Glaser, 2004). Another factor of paramount vitality is the reality of having objectives change during project implementation. The idea of project creep is a dominant phenomenon in project management, which is heavily characterized

97

International Management Review

Vol. 5 No. 1 2009

by being inescapably unstoppable. The unrealistic time or resource estimates is commonly a prominent factor that involves the unrealistic estimation of time or resource that causes project- related problems. The fifth factor is the lack of executive support and user involvement. Those two main difficulties have been found to be hard to manage during a project cycle (Jenster & Hussey, 2005). Failure to communicate and act as a team was considered being a hindrance factor for project success. Improper communication, especially for large projects, can make a project fail drastically. Last, the research revealed inappropriate skills as a key factor that put IT projects at risk. In fact, the challenge of global competition, the fast growth of knowledge, and the constant changes of technology make it hard to predict what kind of skilled people will be needed. Domain Specific Project Failures Information System (IS) Failure Causes Information System (IS) is developed to encapsulate and integrate a number of areas of business with an aim to increase efficiency and effectiveness of business practices. It is widely accepted that IS improves productivity through streamlining of process and boosts efficiency and effectiveness of individual worker and groups through connectivity that it offers. The implementation of an information system involves a number of challenges and difficulties that, in many cases, pose threats to the success of IS in achieving its objectives and providing its intended functionality within the constraints of time and cost. The Research on IS failure phenomena has been conducted in diverse perspectives. Some research has attempted to uncover the organizational factors related to IS project failure (Lyytinen & Hirschheim, 1997). Part of the research was performed to reveal the influence of organizational structure (Sauer, 1996) on IS project failure. Extensive research has been carried out to unveil the effects of culture, power, and context on the performance of project management and how they contribute to the IS failure profile (Cavaye & Christiansen, 1996; Gallivan, 1197). The literature related to IS failure has clearly identified a prominent factor that has attracted vast attention in recent years: the escalation of commitment to IT projects (Oz & Sosik, 2000; Newman & Sabherwal, 1996). Lyytinen and Hirschheim (1987) explored the reasons for IS failure and concluded that there are four major categories responsible for IS project failures: correspondence failure, process failure, interaction failure, and expectation failure. Sauer (1993) had criticized this model and proposed a more conservative description of information systems failure. According to his account, an information system should only be regarded as a failure when development or operation ceases, and end-users are disappointed with the extent to which the system has served their interests. A fundamental reason that causes IS projects to fail is that they are too complex (Murray, 2000). Inherently complex projects must handle both technological issues and organizational factors, which are far too often outside the project team’s control. In addition, both information technologies and business environments are evolving at an alarming rate, making technical specifications and business requirements increasingly uncertain and tough to manage. In addition, most IS organizations are under mounting pressure to deliver systems with fewer resources and in a very short development lifecycles (Williams, 1999).

98

International Management Review

Vol. 5 No. 1 2009

Web-Based Project Failure Causes The explosive popularity of the World Wide Web has compelled its usage in numerous commercial ventures. It has become the predominant means for communicating and presenting information on an extensive scale. Web-based systems and applications deliver a complex array of content and functionality to a broad population of end-users. Therefore, it has become a must to develop high-quality Web applications because the norm is, nowadays, that businesses cannot survive without deploying their business online. Web applications have attributes that are unique to software engineering and are encountered in the vast majority of Web applications, such as short time-to-market, concurrency, performance, availability, and continuous evolution, just to mention a few. These general attributes apply to all Web applications, but with different degrees of influence. However, such attributes have added great pressures upon Web application developers to deliver Web infrastructure that is capable of fully taking care of these attributes in order to reduce the probability of implementation failures. Building successful Web-based applications requires close coordination among various efforts involved in the Web development cycle. Many studies, however, reveal that poor project management is the major cause of Web failures during development and subsequently in the operational phase. Poor project management will defeat good engineering; good project management is a recipe for success. Successfully managing a large, complex Web development is a challenging task requiring multidisciplinary skills and is, in some ways, different from managing traditional IT projects. A study by http/www.bookpublishingsoftware.com/Ecommerce03.htm was conducted to reveal why a large percentage of Web projects are doomed to failure. The causes of failures have been attributed to the following reasons: lack of a project plan, the site takes too long to implement, which increases the time to market, the developers fail to study the competition, and the Web project fails to thrust itself into the market, hiring the wrong designers, building the Web project from scratch, failing to consider the ongoing costs of maintaining a Web site, and management’s ignoring the viewing habits of the customers, which generate inappropriate sites. Ranganathan, Teo, Dhaliwal, Ang and Hyde (2001) launched an extensive literature review to reveal the factors that are responsible for e-commerce projects failures. The analysis of data revealed nine categories of factors affecting the deployment of business to business ecommerce. Healthcare Informatics Failure Causes The introduction of information technology into the realm of healthcare in order to transform healthcare quality through information technology has been a very challenging issue for many health systems worldwide. However, the use of computers to assist health professionals in their activities has been going on since the 1950s. In the 1980s, personal computers were commonly found in hospitals and physicians’ practices. This has helped extensively the use of computers to present clinical information, such as laboratory results. It is a fact that healthcare informatics has not enjoyed much reception due to the fact that failure to deliver silver-bullet solutions to resolve perpetual healthcare ills. Many studies have clearly revealed that there are problematic issues associated with the application of information technology in healthcare environments, and information technology projects have been facing stumbling blocks and are fraught with uncertainties and difficulties. This is because the health care environment is frequently described as hyper

99

International Management Review

Vol. 5 No. 1 2009

turbulent and information intensive. Therefore, one can safely say that the healthcare systems environment is significantly different from the information systems environment in other industries. In addition to the fact that the state of clinical information technology in application to healthcare setting has become increasingly more complex, and as it supports increasingly complex medical science, research and practices, the number of ways that failures and mishaps can occur from errors in judgment, inadequate knowledge, mismanagement, and related factors increases markedly. Competence, excellent management, logical decision making, and the wide-angle view of true cross-disciplinary expertise have, therefore, become imperatives for leadership and success in this field. Therefore, there is a general impression that computerized health information systems are prone to failure. After having said all that, many countries are still pursuing IT solutions to enhance the quality of healthcare deliverables in order to offer a better health forum to improve the quality of healthcare services and promote the safety of patients. Many studies of healthcare IT successes and failures have pointed to the need to engage clinicians in all aspects and phases of the project. Sauer, Southon and Dampney (1997) conducted a case study in Australia in 1999, reviewing the failure factors of healthcare information system. They concluded that organizational issues were keys to IT success. A more elaborate study by Gauld (2006) has recently been conducted comprehensively to find out what causes information system failures in the public healthcare setting in New Zealand. The author arrived at a host of factors that have been identified as the most prominent factors responsible for impeding the success of information systems in healthcare. Some of the key failure factors are large and multifaceted project; information system project needs are not well defined; information system project objectives are not defined; discontinuity of key management staff; and no chief of information officer was assigned through entire project. Most of these characteristics are routinely found in Bussen, Myers (1997) and Taylor (2000). General Taxonomy The figure below presents all the generic types of root causes factors. For each root cause, we list two examples belonging to that category. In principle, any symptom of a project failure should belong to one of the root causes in the taxonomy. From the literature review, it is clear that most of the symptoms of IT project failure belong to the project management root cause.

100

International Management Review

Vol. 5 No. 1 2009

IT Project Failure Root Causes

Project Mgt Factors

Organizational Factors

Top Mgt Factors

- User involvement - Scope and objectives -…

- Lack of a champion - Lack of commitment -…

Technology Factors

- Developer expertise - Lack of commitment -…

- Culture / structure - Conflicting interests -…

Complexity Factors

/ Size

Process Factors

- Large and multifaceted project - Complex project -… - No/unsuitable project mgt process - Conflicting interests -…

Actually, the root causes shown in the figure above can be further divided into subcategories. For example, we can define a subcategory as communication factors, and place user involvement and many other causes under this subcategory. This taxonomy is set to explore the common themes between failure factors for IT projects in all domains, including the three application domains investigated: traditional information system, Web-based systems, and healthcare informatics. The taxonomy shows clearly that there are commonalities in failure factors in all domains. The unique failure factors in specific domains can easily be mapped to one of the major causes. For example, the short-time-to-market symptom for failure in web-based systems can be either mapped to Process Factors, if a non-suitable development process, such as an agile process adapted to web-based systems has been used, or the Project Management Factors, if time management was the reason for failure. Failure factors for individual projects can span multiple categories. Also, each specific case has different types of failure factors. However, projects within the same domain can exhibit similar failure factors. An issue that seems to be appearing in all IT domains is that a full agreement with all people involved in the objectives of the project is lacking which causes the project to fail. This symptom belongs to the Project Management Factors root cause, as it is part of the scope of the project. Since conventional information systems have been around for many decades, they have become, to some extent, highly mature, more developed, and more elaborate. Therefore, their root causes have been identified and classified. On the other hand, web-based and healthcare informatics applications are in their infancy, and their methodologies, tools, practices, procedures, theories, concepts, guidelines, and alignment strategies are still evolving. Therefore, the six generic root causes can be extended in the future to include new ones. Also, new advances and developments in the software engineering field may eliminate some root causes, such as the PM/Development Process Factors.

International Management Review

Vol. 5 No. 1 2009

Conclusion The primary focus of this paper is to investigate and understand the reasons for IT project failure. It shows clearly that IT project failure rates are a high and widely noticeable phenomenon. It is clear, however, success and failures are complex concepts, and their perceptions are complicated, unstructured, and not readily quantifiable. The fact is that IT projects, in general, have certain attributes that make them prone to failure and are different from and potentially more difficult than other engineering projects. Some of these issues that characterize IT projects are still unknown and may be cumbersome to pin down. Additionally, from the results concluded in this study that each individual case has different unknown reasons for failure, even in the same application domain. Furthermore, this study has indicated that the different faces of IT project failure causes forms a taxonomy. We believe that understanding the taxonomy and focusing efforts on addressing the causes in the taxonomy will improve the success rate of IT projects. We also believe that all meaningful causes are covered in the taxonomy. References Keider, S.P. (1974). Why projects fail. Datamation, 20. Boehm, B.W. (1981). Software engineering economics. Prentice Hall, Englewood Cliffs, NJ. Pinto, J.K., Slevin, D.P. (1988). Project success: definitions and measurement techniques, Project Management Journal, 19, 67–72. Jones, C. (1995). Patterns of large software systems: failure and success, IEEE Computer, 28, 86–8. Baccarini, D. (1999). The logical framework method for defining project success. Project Management Journal, 30, 25–32. Linberg, K.R. (1999). Software developer perceptions about software project failure: a case study. Journal of Systems and Software, 49, 177–192. Saleh, Y., & Alshawi, M. (2005 ). An alternative model for measuring the success of IS projects: the GPIS model, Journal of Enterprise Information Management, 18(1). Standish Group, The Chaos Report (1994). www.standishgroup.com. Sauer, C., & Cuthbertson, C. (2003). The State of IT Project Management in the UK, Templeton College, Oxford. Peffers, K., Gengler, C.E., & Tuunanen, T. (2003). Extending critical success factors methodology to facilitate broadly participative information systems planning. Journal of Management Information Systems, 20(1), 51–85. Salmeron, J.L., & Herrero, I. (2005). An AHP-based methodology to rank critical success factors of executive information systems. Computer Standards & Interfaces, 28(1), 1–12. Rodriguez-Repiso, L., Setchi, R., & Salmeron, J.L. ( 2007). Modeling IT projects success with Fuzzy Cognitive Maps, Expert Systems with Applications, 32(2). Cormican, K., & O’Sullivan, D. (2004). Auditing best practice for effective product innovation management Technovation, 24(10), 819–829. McFarlan, F. W. (1981). Portfolio approach to information systems. Harvard Business Review, 59, 5. Block, R. (1983). The politics of projects, Yourdon Press. Prentice-Hall, Englewood Cliff, New Jersey. Boehm, B. (1991). Software risk management: principles and practices, IEEE Software, 8(1), 32-41. Barki H., Rivard S., & Talbot, J. (1993). Towards an assessment of software development risk, Journal of Management Information Systems, 10(2), 203-225. Willcocks L., & Margetts, H. (1994). Risk assessment and information systems. European Journal of Information Systems, 3(2), 127-138. Keil, M., Tiwana, A., & Bush, A. (2002). Reconciling user and project manager perceptions of IT project risk: a Delphi study. Information Systems Journal, 12, Blackwell Science Ltd.

102

International Management Review

Vol. 5 No. 1 2009

Cusing, K. (2002). Why projects fail. Computer Weekly. Schmidt, R., Lyytinen, K., Keil, M., & Cule, P. (2001). Identifying software project risks: An international Delphi study. Journal of Management Information Systems, 17(4), 5–36. Field, T. (1997). When BAD things happen to good projects, CIO, 55-62. Johnson, J., et al. (2001). Collaborating on project success. Retrieved from http://www.softwaremag.com/. Fichter, D. (2003). Why web projects fail, [Online Journal], 27(4), 43. Retrieved Oct. 6, 2007 from http://www.ebscohost.com. New Zealand Management. (2003). When IT projects fail, [Online Journal], 50(2), 18. Available at http://www.ebscohost.com. Glaser, J. (2004). Management's role in IT project failures. Healthcare Financial Management. Jenster, P., & Hussey, D. (2005). Create a common culture between IT and business people to reduce project failures. Computer Weekly. Lyytinen, K., & Hirschheim, R. (1987). Information systems failures—a survey and classification of the empirical literature. Oxford Surveys of Information Technology, 4, Oxford University Press, Oxford. Sauer, C. (1993). Why information systems fail: A case study approach. Alfred Waller, Oxfordshire. Cavaye A., & Christiansen, J. (1996). Understanding IS implementation by estimating power of subunits. European Journal of Information Systems, 5, 222–232. Gallivan M. (1997). The importance of organizational culture fit: a technology implementation success story. Journal of Failure and Lessons Learned in Information Technology Management, 1(4), 243–257. Oz E., & Sosik, J. (2000). Why information systems projects are abandoned: a leadership and communication theory and exploratory study. Journal of Computer Information Systems, 41(1), 66–79. Newman M., & Sabherwal, R. (1996). Determinants of commitment to information systems development: a longitudinal investigation. MIS Quarterly, 20 (1), 23–54. Lyytinen, K., & Hirschheim, R. (1987). Information failures—a survey and classification of the empirical literature, Oxford Surveys in Information Technology. Murray, J.P. (2003). Reducing IT project complexity: Information strategy. The Executive's Journal, 16, 3. Williams, T.M. (1999). The need for new paradigms for complex projects. International Journal of Project Management, 17(5), 269-273. Ranganathan C., Teo, T. S. H., Dhaliwal, J., Ang, J. & Hyde, M. (2001). A study of facilitators and inhibitors for deploying business-to-business e-commerce applications: A multi-method, cross-cultural study. Proc. of International Conference on Information Systems, New Orleans. Sauer, C., Southon, G., Christopher, N., Dampney, G. (1997). Fit, failure, and the house of horrors: toward a configurational theory of IS project failure, ICIS. Gauld, R. (2006). Public sector information system project failures: Lessons from a New Zealand hospital organization. Government Information Quarterly, 102–114. Bussen, W., & Myers, M. (1997). Executive information system failure: A New Zealand case study. Journal of Information Management, 12, 145–153. Lemon, W. F., Liebowitz, J., Burn, J., & Hackney, R. (2002) Information systems project failure: A comparative study of two countries, Journal of Global Information Management, 10(2), 28– 39. Natovich, J. (2003). Vendor related risks in IT development: A chronology of an outsourced project failure. Technology Analysis and Strategic Management, 15(4), 409–419. Pan, G. S. C. (2005). Information systems project abandonment: A stakeholder analysis. International Journal of Information Management, 25, 173–184. Royal Academy of Engineering and British Computer Society. (2004). The challenges of complex IT projects. London: The Royal Academy of Engineering.

103

International Management Review

Vol. 5 No. 1 2009

Standish Group. (2001). Extreme Chaos. The Standish Group International, Inc. Taylor, A. (2000). IT projects: Sink or swim. The Computer Bulletin, Jan., 24–26. Whittaker, B. (1999). What went wrong? Unsuccessful information technology project. Information Management and Computer Security, 7(1), 23–29. Robinson, B. (1994). Social context and conflicting interests. Second BCS conference on Information System Methodologies, Edinburgh, (pp. 235-249). Ewusi-Mensah K. (1997). Critical Issues in Abandoned Information System Development Projects, Communications of the ACM, 40, 9. Naughton, J., & Peters, G. (1976). Systems and failures. Open University Press, Milton Keynes.

104