# IS/IT Project Failures: A Review of the Extant Literature for Deriving a Taxonomy of Failure Factors

Yogesh K. Dwivedi, Karthik Ravichandran, Michael D. Williams, Siân Miller, Banita Lal, George V. Antony, Muktha Kartik

► To cite this version:

Yogesh K. Dwivedi, Karthik Ravichandran, Michael D. Williams, Siân Miller, Banita Lal, et al. IS/IT Project Failures: A Review of the Extant Literature for Deriving a Taxonomy of Failure Factors. International Working Conference on Transfer and Diffusion of IT (TDIT), Jun 2013, Bangalore, India. pp.73-88, 10.1007/978-3-642-38862-0_5 . hal-01467815

HAL Id: hal-01467815

https://inria.hal.science/hal-01467815

Submitted on 14 Feb 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# IS/IT Project Failures: A Review of the Extant Literature for Deriving a Taxonomy of Failure Factors

Yogesh K Dwivedi¹, Karthik Ravichandran², Michael D Williams¹, Siân Miller¹, Banita Lal³, George V Antony⁴ and Muktha Kartik⁵

¹The School of Business, Swansea University, Swansea, UK
ykdwivedi@gmail.com; m.d.williams@swansea.ac.uk; 669196@swansea.ac.uk

²Tractors and Farm Equipment Ltd, Bangalore, India
karthik_19@hotmail.com

³Nottingham Business School, Nottingham Trent University, Nottingham, UK
banita.lal@ntu.ac.uk

⁴Post Doctoral Fellow, Cochin University of Science & Technology, Cochin
drgeorgegevantony@gmail.com

⁵Mahindra Satyam, Bangalore, India
Muktha.kartik@gmail.com

**Abstract.** The majority of the existing literature is based upon the assumption that, by paying attention to success factors, failure will be avoided. In the case of challenged projects, where failure factors are overcome the projects go on to be delivered successfully. Hence, it is worthwhile to explore the key factors that determine failure, since this information may be useful in averting future project failures. This research aims to collate and classify existing research in order to: (1) understand the common failure factors; and (2) categorise identified factors pertaining to country, project stage and failure categories. In so doing, this research work goes beyond the identification of traditional factors since it further classifies them according to project stages, failure types and geographical regions. This research contributes to knowledge by identifying and synthesising existing understanding of the failure of IS/IT projects.

**Keywords:** IS/IT Project, Failure, Literature Review, Taxonomy of Factors

## 1 Introduction

Failure is a common phenomenon in projects. Bignell and Fortune (1984) defined failure broadly as the shortfall between performance and standards. In context of IS/IT, Ewusi-Mensah (2003, p.7) defined failure as "either the implemented system not meeting the user expectations or inability of creating working or a functioning
system”. According to Sauer (1993), if a project organization loses support and fails to manage the service, then ultimately the project will fail.

IS projects have been renowned for failures since before the 1990s, more than 75% of all projects were considered failures (Beynon-Davies, 1995, p. 171). Although the percentage of successful projects seems to have increased in the recent past, challenged projects remain constant at around 50% (Standish Group report, 2006 as cited in Nasir & Sahibuddin, 2011). The lack of improvement may be attributed to complexity in projects, size, movement of the project team and the organizations failure to look back at the past projects (Nelson, 2007). Project Management (PM) is the most efficient way of delivering projects (Avots, 1969). However, Lyytinen and Robey (1999) found that traditional PM practices and advancement in tools and methods has had little impact on failure and failure factors. Thus if tools cannot prevent failures, a careful understanding of failure factors is imperative. Analysis of project failures is still ambiguous since it is often reported post hoc. Proactive diagnosis remains primitive. Migration to leading rather than lagging indicators in PM would promote this (Stewart & Mohamed, 2004). Project Managers are further handicapped by the lack of commonality in reported failure factors. Focus on an understanding of common failure factors is essential to aid project managers in avoiding those mistakes which lead to failure.

The overall aim of this paper is to collate and classify existing research in order to: (1) understand the common failure factors; and (2) categorize identified factors by country, project stage and project category. This paper is structured into the following sections: categorization of failure; taxonomy of failure factors; failure factors according to project lifecycle stages; failure factors according to geography; types of failure, discussion; and conclusions outlining theoretical contributions and implications.

## 2 Categorising Failure

Existing literature has categorized IS failure using various approaches. For example, Ewusi-Mensah (2003, p.8) characterized failure as “Software Runaways” from original plans in cost and delivery. Another common approach classifies failed projects as challenged and impaired projects (Dalcher, 2003; Standish group, 1995; Yeo, 2002). Projects that were cancelled or abandoned during the project life cycle were considered ‘impaired’. ‘Challenged’ projects are those which have suffered the impact of failure but have survived (Standish group, 1995). Lyytinen and Hirschheim (1987) suggested four types of failure: correspondence failure, process failure, interaction failure and expectation failure. Correspondence failure refers to system’s inability to correspond to what is required. Process failure (similar to software runaways) leads to shortfalls in time and budget constraint is associated with poor Project Management. Interaction failure refers to where the developed system is unsatisfactory to the user (Lyytinen and Hirschheim, 1987). Sauer (1993) criticized these categories of failures for their limited scope. In response, Lyytinen and Hirschheim (1987) introduced the concept of expectation failure encompassing the three preceding categories where the project fails to meet stakeholder expectations in terms of correspondence, process and
interaction. Expectation failure was further divided into development failure and use
failure (Lyytinen and Hirschheim, 1987).

A drawback of expectation failure is that it does not consider differences in situation. Both impaired and challenged projects (Standish group, 1995) can be categorized as expectation failure. Sauer (1993) offered the following criticisms of expectation failure: (1) Defining expectations and its relative importance to stakeholders is unclear. Factors beyond cost, time and quality need to be considered; (2) Intentional issues are missed in the scope of expectation failure. What the project is intended to do may be different from expectation; and (3) Differential capacities can manifest themselves as failure, for example the failed London ambulance project where users did not have the capacity to use the system (Sauer, 1993). Sauer (1993) argued that the interest of the most important stakeholder should be considered in defining project requirements and developed an alternative classification of failure to bring out the exchange between the organization and the project supporters. Sauer (1993) described termination failure which occurs when development or operation and maintenance ceases and all interests in the project have ceased with no continuing supporters. Ewusi-Mensah (2003) describes this as abandonment and termination failure is total abandonment, with substantial and partial being other classifications of failed projects. Total abandonment can be seen as an extreme example of an impaired project. Substantial abandonment is similar to the status of a challenged project where major stoppages occur and, at times, the changes to the original specification finally overcome the failure factors. Partial abandonment refers to a reduction in the original scope without modifying the original project specifications (Ewusi-Mensah, 2003). Escalation failure is introduced by Newman and Sabherwal (1996) where overshooting time and budget leads to failure.

Further classification is based on Project and PM levels. The project level will focus on failure factors that can occur after delivery of the project such as usability, maintenance and user feedback. The failure factor pertaining to PM occurs during the development and implementation of project and can be further classified as either within the PM scope covering limited and complete control and finally wholly outside the purview of PM (Schmidt et al., 2001). Atkinson (1999) classifies PM failures as ‘Type I and II’ errors. Type I relates to carrying out an activity wrongly, for example, planning, estimating or project control. Type II relates to ignorance, forgetting or not carrying out an intended activity resulting in a failure factor (Atkinson, 1999). This literature examining different criteria for failure will be used to classify and group the failure factors according to the above discussed classification and terminologies of failure.

## 3 Taxonomy of Failure Factors

This section identifies and classifies factors that contribute to a failure of project management (PM) and projects.
## 3.1 Project Management Factors

Verner et al. (2008) reveals that the majority of projects suffer failure factors arising from poor PM and organizational factors outside the project managers control. Avots (1969) revealed that PM techniques where used as a general tool may lead to more failure factors than where used towards specific objectives and with greater discipline such as in the aerospace sector. Many symptoms can indicate PM failures the most common being cost and/or time overruns and erosion of quality (Avots, 1969). Atkinson (1999) suggests that, in many cases it is difficult to achieve more than two out of the three familiar success criteria of time, cost and quality. Most PM failures occur due to a commonly occurring set of factors (Avots, 1969). The basis for undertaking a project is a complete understanding of the need for the project. The capability of the project manager is crucial since they are responsible for organizing and leadership throughout the PM life cycle. Even with the right project manager the failure can still arise from a lack of management support especially when management is unclear about the objectives. Projects can quickly descend into failure if the tasks and activities are not clearly defined and allocated. Management needs to understand the need for tools and techniques and to support the PM team to avoid failure caused by the misuse of tools and techniques. Project termination in the case of success or failure should be smooth with the full support of stakeholders, otherwise an apparently successful project can be deemed a failure. Atkinson (1999) argued that even after 50 years of research into Project Management, failure factors are still limited to the Iron Triangle elements of cost, time and quality. Furthermore, failure factors may commonly be seen as the Type I and II errors discussed above. However, errors of omission (Type II) remain a strong contender towards failure in Project Management (Atkinson, 1999).

More recently, Jones (2004) introduced the following factors relating to the failure of PM. Planning arise from inadequate time allocated for a detailed requirement analysis, ineffective change management, inappropriate human resource management and, finally, insufficient time for inspection, testing and defect repairs. A lack of correct sizing approaches and tools, projects tend to understate the scale of work resulting in failure (Jones, 2004). Inadequate milestone tracking and reporting are causes of PM failure. Change management and quality control are the final factors that are important in any kind of projects and omission of these activities will end up as failure (Jones, 2004).

## 3.2 Project Factors

There are many factors which affect project goals and objectives and emerge as factors leading to failure. Many studies give a wide range of failure factors. Failure factors are listed in Table 1 showing common and exclusive factors applicable to Project ('P') and Project Management ('PM'). According to Pinto and Mantel (1990) project failures are vague and observation-based the failure factor varies from initial stages of the lifecycle to final implementation. The first major group factors that contributes to failure are classified as 'project' covering size, value, span, uniqueness,
urgency and density of the project (Al-Ahmad et al., 2009; Belassi and Tukel, 1996; Schmidt et al., 2001; Tukel and Rom, 1998).

The size of the project is an important factor in planning resources and estimating the time. The chance of this becoming failure factor is high if not taken into account during estimation and planning (Tukel and Rom, 1998). The size of the project will have a direct impact on the complexity of the problem (Ewusi-Mensah, 2003). The project size factor is demonstrated through “scope creep”, in the number of suppliers and organizations involved in the project and it may be correlated with the team size (Schmidt et al., 2001).

Value can contribute to failure, with larger value projects being more likely to fail (Wallace et al., 2004). Closely associated with value is loose budgetary control that is often the reason for project failure. Although this is closely associated with PM failure, sub factors related to budget overrun fare worthy of mention. Three critical sub factors are: detailed line item follow-up, emphasis of short-term budget targets and the level of tolerance for budget revision (Conboy, 2008).

<table><caption>**Table 1.** Failure factors for project (P) and project management (PM) identified in existing studies</caption><thead><tr><td>Failure Factors</td><td>P</td><td>PM</td><td>Reference</td></tr></thead><tbody><tr><td>Project: Size and Value; Uniqueness; Density of Project; Life cycle; Urgency</td><td>*</td><td></td><td>Al-Ahmad et al. (2009); Belassi and Tukel (1996); Schmidt et al. (2001)</td></tr><tr><td>Team (Covers Project team and Project manager Characteristics): Turnover; Staffing build-up; Knowledge; Motivation Levels</td><td>*</td><td></td><td>Wallace et al. (2004)</td></tr><tr><td>Project Team: Technical background; Communication Skills; Commitment</td><td>*</td><td></td><td>Belassi and Tukel (1996)</td></tr><tr><td>Absence of an influential champion and Change agent</td><td>*</td><td></td><td>Yeo (2002)</td></tr><tr><td>Improper definitions of roles and responsibilities</td><td></td><td>*</td><td>Al-Ahmad et al. (2009); Schmidt et al. (2001)</td></tr><tr><td>User: User conflicts</td><td>*</td><td></td><td>Wallace et al. (2004).</td></tr><tr><td>User involvement and Commitment</td><td>*</td><td>*</td><td>Attarzadeh and Ow (2008); Al-Ahmad et al. (2009); Brown and Jones (1998); Jiang et al. (1998); Johnson et al. (2001); Hartwick and Barki (1994); Schmidt et al. (2001)</td></tr><tr><td>User Resistance: Lack of Felt Need; Uncertainty; Lack of involvement in Change; Personal Characteristics</td><td>*</td><td></td><td>Field (1997); Hirschheim and Newman (1988); Jiang et al. (1998); Markus (1984); Yeo (2002)</td></tr><tr><td>Lack of user input: Did not Need It Any Longer</td><td></td><td>*</td><td>Attarzadeh and Ow (2008)</td></tr><tr><td>Conflict between user department: Failure to manage end-user expectations</td><td>*</td><td></td><td>Al-Ahmad et al. (2009); Schmidt et al. (2001)</td></tr><tr><td>Goal: Goals are ambiguous, too narrow and Conflicting</td><td></td><td>*</td><td>Dickson et al. (1978); Johnson et al. (2001); Lyytinen (1987)</td></tr><tr><td>Objectives and Value gap</td><td>*</td><td></td><td>Attarzadeh and Ow (2008); Heeks (2006); Munns and Bjeirmi (1996)</td></tr></tbody></table>
<table><thead><tr><td>Failure Factors</td><td>P</td><td>PM</td><td>Reference</td></tr></thead><tbody><tr><td>Ambiguous business needs and unclear vision</td><td>*</td><td></td><td>Yeo (2002)</td></tr><tr><td>Resources (Economic): Staffing and Skill gap; Time and Money gap</td><td>*</td><td>*</td><td>Attarzadeh and Ow (2008); Heeks (2006)</td></tr><tr><td>Unrealistic Time Frame</td><td></td><td>*</td><td>Attarzadeh and Ow (2008); Yeo (2002)</td></tr><tr><td>Requirement: Conflicting system requirement; Difficulty in defining input and output</td><td>*</td><td></td><td>Wallace et al. (2004)</td></tr><tr><td>Weak definitions of requirements and scope; Incomplete specifications when project started; Consultant/vendor underestimated the project scope and complexity</td><td>*</td><td>*</td><td>Attarzadeh and Ow (2008); Yeo (2002)</td></tr><tr><td>Misunderstanding the user requirements; Lack of frozen requirements; Changing scope and objectives</td><td>*</td><td></td><td>Al-Ahmad et al. (2009); Schmidt et al. (2001)</td></tr><tr><td>Planning and Control</td><td>*</td><td></td><td>Wallace et al. (2004)</td></tr><tr><td>Incomplete Requirements and Specifications; Changing Requirements and Specifications</td><td></td><td>*</td><td>Attarzadeh and Ow (2008)</td></tr><tr><td>Failure to apply essential PM practices</td><td></td><td>*</td><td>Dalcher and Drevin (2003); Evans et al. (2001)</td></tr><tr><td>Lack of effective PM methodology</td><td></td><td>*</td><td>Al-Ahmad et al. (2009); Schmidt et al. (2001); Verner et al. (2008)</td></tr><tr><td>Lack of effective PM skills</td><td></td><td></td><td></td></tr><tr><td>Preoccupation with Technology in project planning</td><td>*</td><td></td><td>Flower (1996); Yeo (2002)</td></tr><tr><td>Reactive and not pro-active in dealing with problems; Inadequate project risk analysis; Incorrect assumptions regarding risk analysis</td><td>*</td><td></td><td>Yeo (2002)</td></tr><tr><td>Technology and Technological High risk restricts choices</td><td></td><td>*</td><td>Ewusi-Mensah (2003); Lyytinen (1987)</td></tr><tr><td>Technology Gap</td><td>*</td><td></td><td>Field (1997); Heeks (2006)</td></tr><tr><td>Inappropriate Technology; Ignorance of IT</td><td></td><td>*</td><td>Mitev (1996)</td></tr><tr><td>Technology Focus over human relations</td><td>*</td><td></td><td>Flower (1996); Yeo (2002)</td></tr><tr><td>Technology Illiteracy; Chosen technology changes</td><td></td><td>*</td><td>Attarzadeh and Ow (2008)</td></tr><tr><td>New Technology failure</td><td>*</td><td></td><td>Al-Ahmad et al. (2009); Schmidt et al. (2001)</td></tr><tr><td>External Environment: Economy</td><td></td><td>*</td><td>Lyytinen (1987)</td></tr><tr><td>Political; Social; Nature Client Competitor</td><td>*</td><td></td><td>Belassi and Tukel (1996); Munns and Bjeirmi (1996); Pinto and Mantel (1990)</td></tr><tr><td>Process Features</td><td></td><td>*</td><td>Lyytinen (1987); Dickson et al. (1978)</td></tr><tr><td>Changes in design specifications late the project; Involve high degree of customization</td><td>*</td><td></td><td>Yeo (2002)</td></tr><tr><td>Organisation</td><td></td><td>*</td><td>Heeks (2006); Lyytinen (1987)</td></tr><tr><td>Organisational Environment</td><td>*</td><td></td><td>Verner et al. (2008); Wallace et al. (2004)</td></tr><tr><td>Top management support; Project organizational structure; Functional managers' support</td><td>*</td><td></td><td>Al-Ahmad et al. (2009); Belassi and Tukel (1996); Flower (1996); Heeks (2006); Schmidt et al. (2001); Yeo (2002)</td></tr></tbody></table>
<table><thead><tr><td>Failure Factors</td><td>P</td><td>PM</td><td>Reference</td></tr></thead><tbody><tr><td>Management Development; Motivation; Culture and Feedback</td><td>*</td><td></td><td>Irani et al. (2001)</td></tr><tr><td>Unrealistic management expectations and unwarranted optimism; Lack of proactive risk management; Untimely decision making; Lack of program management leadership</td><td></td><td>*</td><td>Dalcher and Drevin (2003); Evans et al. (2001)</td></tr><tr><td>Poor Management</td><td></td><td>*</td><td>Mitev (1996)</td></tr><tr><td>Hostile Company culture</td><td>*</td><td></td><td>Flower (1996); Yeo (2002).</td></tr><tr><td>Top down management style</td><td>*</td><td></td><td>Yeo (2002).</td></tr><tr><td>Managerial Influence; Poor stakeholder management</td><td>*</td><td></td><td>Flower (1996); Yeo (2002)</td></tr><tr><td>Organisational Consequences</td><td>*</td><td></td><td>Brown and Jones (1998)</td></tr><tr><td>Self Image</td><td></td><td>*</td><td>Lyytinen (1987).</td></tr><tr><td>Learning: Educational Barriers; Organisational Intelligence; Disincentives for Learning</td><td></td><td>*</td><td>Lyytinen and Robey (1999)</td></tr><tr><td>Managers ignore best practices and lessons learned</td><td>*</td><td></td><td>Field (1997)</td></tr><tr><td>IS related: IS operations Problem; IS Failure; IS implementation; Data Problems; Process gap</td><td>*</td><td></td><td>Davis et al. (1992); Heeks (2006); Jiang et al. (1998); Lyytinen (1987); Thong et al. (1994); Heeks (2006).</td></tr><tr><td>Not managing change properly</td><td>*</td><td></td><td>Al-Ahmad et al. (2009); Schmidt et al. (2001)</td></tr><tr><td>Conceptual Problem</td><td>*</td><td></td><td>Lyytinen (1987)</td></tr><tr><td>Complexity Problem</td><td>*</td><td></td><td>Lyytinen (1987); Wallace et al. (2004)</td></tr><tr><td>People Problem</td><td>*</td><td></td><td>Lyytinen (1987)</td></tr><tr><td>Factors related to the Project Manager</td><td>*</td><td></td><td>Belassi and Tukel (1996)</td></tr><tr><td>Communication; Workforce management conflicts</td><td>*</td><td></td><td>Yeo (2002); Irani et al. (2001)</td></tr><tr><td>Human Error</td><td></td><td>*</td><td>Mitev (1996)</td></tr><tr><td>Vested Interest</td><td>*</td><td></td><td>Flower (1996); Yeo (2002)</td></tr><tr><td>Outsourcing: More than one supplier; Poor Selection decision</td><td>*</td><td></td><td>Belassi and Tukel (1996); Flowers (1996); Schmidt et al. (2001); Wallace et al. (2004); Yeo (2002)</td></tr><tr><td>Weak management of Suppliers</td><td>*</td><td></td><td>Brown and Jones (1998)</td></tr><tr><td>Legal Issues</td><td>*</td><td></td><td>Munns and Bjeirmi (1996); Pinto and Mantel (1990)</td></tr></tbody></table>

Span covers the period during which the project must be executed and is closely related to failures related to overshooting time and delivery, coupled with urgency. Uniqueness is important when compared with standard activities. More unique activities require more planning by the Project Manager (Belassi & Tukel, 1996). Density is the number of predecessor activities which need to be completed before beginning a new activity (Tukel & Rom, 1998). This is related to escalation which is a key Project Manager activity when they encounter problems with density which may impact resources planning.

The factor in the second category is the part played by the team involving the skills and attributes of the project team and project manager which are key in the planning and termination stages where commitment and energy play a major role (Belassi &
Tukel, 1996). Team turnover, staffing build-up, communication and motivation are additional sub factors (Wallace et al., 2004). The project manager should be an influential change agent (Yeo, 2002). According to Johnson (2001) 97 % of project which are successful are managed by skilled and experienced project managers (Johnson, 2001). Poor leadership is a failure factor especially affecting the early stages of a project (Morris and Hough, 1987).

User failure falls within the top three project failure factors (Attarzadeh & Ow, 2008). Users need to be carefully involved and become a part of quality assurance. Misunderstanding user requirements is one of the 17 failure factors identified by Schmidt et al. (2001). Further issues like conflict between user departments and lack of user responsibilities also contribute to failure (Wallace et al., 2004). Jiang et al. (1998) looks at failure through expectation failure theory and observes that failure can occur during development or during system use and is viewed differently by different stakeholders. The research discusses four types of failure namely IS failure, user involvement, user resistance and implementation failure. The research revealed that the failure factors are more common and frequent later in the development life cycle. The failure factor varies according to the IS users and IS professionals. User assistance, interviewing and resource commitment factors tend to have less impact on failure factors.

Unclear goals and business objectives lead to failure (See Table 1). Ambiguous business goals and unclear vision constitute significant factors in failure (Yeo, 2002) leading to failure in time, cost and quality (Al-Ahmad et al., 2009; Field, 1997; Johnson, 2001). Project creep and changes in goals and objectives during implementation affects many projects (Al-Ahmad et al., 2009; Schmidt et al., 2001). Narrow and conflicting goals can become failure factor (Lyytinen, 1987). Many projects fail due to the lack of stakeholder consensus (Ewusi-Mensah, 2003).

The requirement factor is closely associated with goals. Many projects suffer failure due to changing requirements, unclear, ambiguous and unusable requirements (Wallace et al., 2004) and misunderstood user requirements and the failure to freeze requirements (Al-Ahmad et al., 2009; Schmidt et al., 2001). Cost and delivery overruns are resource or economic factors. Cost overruns and missed delivery can result in project termination. Ewusi-Mensah (2003) includes escalation of costs and completion schedules, actual project expenditures and delivery below the estimates and finally lack of funds. These indirect factors may be the reason for the overrun. Failure can also be due to time and delivery below the estimates related to estimation issues in project management. Finally the depletion of funds can result in project termination

Content driven failure or the technology factor (Yeo, 2002) brings a high risk of failure since technology affects operational processes at a group or personal level (Lyytinen, 1987). Technology complexity refers to technology that is new to the project, technology linked to many other systems, immature technology and automation (Wallace et al., 2004). Technology incompetence and new technology may lead to a challenge which may be overcome whereas technology illiteracy will lead to an impaired project (Attarzadeh and Ow, 2008). Technological factors include inadequate process, high degrees of customization, computer hardware availability
and correct infrastructure and compatibility with the existing system (Ewusi-Mensah, 2003). Complexity is closely allied to the technology factor. This can be in the form of new technology and to which the organization has not been previously exposed (Wallace et al., 2004). By contrast, Kappelman et al. (2008) argues that no IS project fails due to the technology factor, but rather due to people and process which manifests as a technical issue. This is supported by Nelson (2007) who reveals that only 4 percent of the top ten failures listed technology as a factor compared with process and people.

External failure factors include economic, political, social and competitor factors. Frequently the project manager cannot control these factors since they are outside the organization (Belassi & Tukel, 1996). These factors are evident in the planning stage, although Pinto and Mantel (1990) find that some of these factors may affect all stages of the project. Organizational factors include top management support, management decision making, organization structure, motivational factors and organizational culture. Top management support is critical, especially where a champion support the project manager in meeting the project goals. A functional organizational structure, rather than a pure project or matrix structure, facilitates better resource sharing (Belassi and Tukel, 1996). Wallace et al. (2004) add organizational politics, lack of stability and resource redirection. Unrealistic management expectations and the absence of leadership are identified by Evans et al. (2002).

Of the studies that have looked at failure, only few (for example, Lyytinen and Robey, 1999) identified a lack of learning from previous failures as a major failure factor in IS projects. Failures in hospital and health care projects can derive from organisation-al consequences such as redundancy and loss of status, complex bureaucratic proce-dures, unrealistic expectations, lack of resource, uncooperative customers and weak supplier management (Brown and Jones, 1998; Sauer et al. 1997). Gauld (2007) sug-gests that discontinuity of key management staff, ill-defined needs and objectives and no appointed chief information officer all contribute to failure. People factors relate closely to the team factor and is ranked in the top three IS failure factors (Lyytinen, 1987). Human error, conflicts and communication inside and outside the organization contribute to failure. A lack of education and user training were found by Irani et al. (2001, p.58) to lead to "noise" in the system, impacting other factors like cost, deliv-ery times and productivity.

With outsourcing, risk factors multiply with more suppliers (Wallace et al., 2004). Multi-supplier projects encounter coordination and integration issues (Schmidt, 2001) stemming from unclarity in objectives and scope, coupled with control and progress monitoring of suppliers. Near shore and local outsourcing face fewer failure factors compared to offshore outsourcing (Miller, 2008). Chen et al. (2009) discussed the impact of poor buyer preparation including inadequate supplier information and a lack of understanding of procurement. Legal issues, which can be categorized as a part of the external environment can hinder projects (Munns and Bjeirmi, 1996; Pinto and Mantel, 1990).

Using four major reports on project failure (Chaos Report, KPMG survey, Computer Weekly programme survey and Align IT group), Miller (2008) suggested the follow-ing top failure factors: (1) Incomplete Requirements; (2) User Factor; (3) Planning
failure; (4) Lack of management support/ involvement; (5) Lack of resources; (6) Weak business case; and (7) Unclear Objectives.

## 4 Failure Factors According to Project Life Cycle

Most projects are developed using a life cycle model coupled with a PM methodology. This provides stability and predictability and controls the development stages (Lyytinen, 1987). Based on the project stages a comparison has been drawn against the failure factors (see Table 2) to illustrate the relative importance of selected factors according to the stages of a project.

<table><caption>**Table 2.** Failure Factors (as derived from Table 1) across Project Life Cycle Stages that are adopted from the PRINCE2 Methodology [Legend: C = Critical; LC=Less Critical; MC=Mildly Critical]</caption><thead><tr><th>Failure Factors</th><th>Conception</th><th>Planning</th><th>Production</th><th>Handover</th><th>Utilisation</th><th>Close down</th></tr></thead><tbody><tr><td>Project</td><td>C</td><td>C</td><td>C</td><td>C</td><td>MC</td><td>MC</td></tr><tr><td>Team</td><td>LC</td><td>C</td><td>C</td><td>C</td><td>LC</td><td>LC</td></tr><tr><td>User</td><td>C</td><td>LC</td><td>C</td><td>C</td><td>C</td><td>LC</td></tr><tr><td>Goal</td><td>C</td><td>C</td><td>MC</td><td>MC</td><td>LC</td><td>LC</td></tr><tr><td>Resources (People, Time and Money)</td><td>MC</td><td>C</td><td>C</td><td>C</td><td>LC</td><td>LC</td></tr><tr><td>Requirement</td><td>C</td><td>C</td><td>C</td><td>C</td><td>LC</td><td>LC</td></tr><tr><td>Planning and Control</td><td>LC</td><td>C</td><td>C</td><td>C</td><td>LC</td><td>LC</td></tr><tr><td>PM</td><td>LC</td><td>C</td><td>C</td><td>C</td><td>LC</td><td>LC</td></tr><tr><td>Technology</td><td>LC</td><td>C</td><td>C</td><td>C</td><td>C</td><td>MC</td></tr><tr><td>External Environment</td><td>LC</td><td>C</td><td>C</td><td>C</td><td>C</td><td>C</td></tr><tr><td>Process Features</td><td>LC</td><td>C</td><td>C</td><td>C</td><td>C</td><td>LC</td></tr><tr><td>Organisation</td><td>C</td><td>C</td><td>C</td><td>LC</td><td>LC</td><td>LC</td></tr><tr><td>Learning</td><td>LC</td><td>C</td><td>C</td><td>C</td><td>C</td><td>MC</td></tr><tr><td>IS</td><td>LC</td><td>C</td><td>C</td><td>C</td><td>C</td><td>LC</td></tr><tr><td>Conceptual</td><td>C</td><td>C</td><td>LC</td><td>LC</td><td>LC</td><td>LC</td></tr><tr><td>People</td><td>LC</td><td>C</td><td>C</td><td>C</td><td>C</td><td>LC</td></tr><tr><td>Complexity</td><td>C</td><td>C</td><td>C</td><td>LC</td><td>LC</td><td>LC</td></tr><tr><td>Outsourcing</td><td>LC</td><td>C</td><td>C</td><td>C</td><td>MC</td><td>MC</td></tr></tbody></table>

## 5 Failure Factors According to Geography

The cultural perspective has been examined as a contributor to project failure (Cam- prieu, et al., 2007; Rees-Caldwell and Pinnington, 2012). Hofstede's framework looks at national preferences along the dimensions of Power-Distance, Individualism, Un- certainty-avoidance and Long term orientation (Hofstede, 1991). Uncertainty- Avoidance (U-A) may be predictor of failure in some geography. Hofstede (2012)
found that with a greater acceptance of uncertainty in the West, there may be more user related failures. A high score on the U-A index, demonstrates a willingness to accept that some things may need to be agreed later but the project can proceed without these being made explicit. If this is not dealt with until later in the project, then there may be a failure due to this uncertainty having not been resolved. However, where there is a low U-A score, the project is unlikely to proceed until these have been agreed.

Cultural factors impact technological, environmental and social failure factors. The UK and USA both tend to be more individualistic in comparison with Singapore and other eastern countries. Where the PM is individualistic the temporary task becomes the main focus and a collectivist culture may experience problems created by cultural incompatibility and ‘lose their work identity’ (Rees-Caldwell & Pinnington, 2012). The table below shows results from the literature survey comparing failure factors by country. It is interesting to note, irrespective of geography, organization ranks as a top failure factor, followed by user, goal, requirement and PM control factors (Table 3).

<table><caption>**Table 3.** Failure factors significance ranking country wise (Source: See Table 1 for sources) Note: Number in cells represent number of studies that reported a particular factor in context of a particular country</caption><thead><tr><th>Failure Factors</th><th>US</th><th>UK</th><th>FINL AND</th><th>SINGA PORE</th><th>HONG KONG</th><th>CAN ADA</th><th>MALA YSIA</th></tr></thead><tbody><tr><td>Project</td><td>-</td><td>-</td><td>11</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Team</td><td>7</td><td>-</td><td>3</td><td>-</td><td>7</td><td>-</td><td>-</td></tr><tr><td>User</td><td>3</td><td>1</td><td>5</td><td>7</td><td>2</td><td>-</td><td>7</td></tr><tr><td>Goal</td><td>6</td><td>6</td><td>12</td><td>-</td><td>3</td><td>1</td><td>-</td></tr><tr><td>Resources (People, Time and Money)</td><td>2</td><td>7</td><td>6</td><td>-</td><td>5</td><td>-</td><td>-</td></tr><tr><td>Requirement</td><td>5</td><td>4</td><td>7</td><td>-</td><td>4</td><td>-</td><td>-</td></tr><tr><td>Planning and Control</td><td>-</td><td>-</td><td>4</td><td>1</td><td>8</td><td>-</td><td>2</td></tr><tr><td>PM</td><td>4</td><td>-</td><td>1</td><td>3</td><td>-</td><td>2</td><td>1</td></tr><tr><td>Technology</td><td>8</td><td>5</td><td>10</td><td>6</td><td>6</td><td>-</td><td>4</td></tr><tr><td>External Environment</td><td>-</td><td>-</td><td>-</td><td>8</td><td>-</td><td>-</td><td>6</td></tr><tr><td>Process Features</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Organisation</td><td>1</td><td>3</td><td>2</td><td>2</td><td>1</td><td>3</td><td>3</td></tr><tr><td>Learning</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>IS</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Conceptual Problem</td><td>-</td><td>-</td><td>-</td><td>4</td><td>-</td><td>-</td><td>-</td></tr><tr><td>People Problem</td><td>-</td><td>2</td><td>8</td><td>5</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Complexity Problem</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>5</td></tr><tr><td>Outsourcing</td><td>-</td><td>8</td><td>9</td><td>-</td><td>-</td><td>-</td><td>-</td></tr></tbody></table>

## 6 Failure Factors According to Types of Failure

Failure factors are complex, layered and interdependent. External factors as well as internal issues play a major role in impacting failure. The literature analysis demon-
strated that failure in most impaired projects is due to more than one factor which are often interrelated. In order to prevent these factors or to detect them before they become catastrophic it is important to understand the classification and measure the failure factors. Type of Failure vs. Failure Factors from the literature is presented in Table 4.

<table><caption>**Table 4.** Type of Failure vs. Failure Factors (Source: Factors Adopted from Munns and Bjeirmi, 1996; Types of Failures from Ewusi-Mensah, 2003) [Legend '*' Significant '- No significant relation from literature]</caption><thead><tr><th>Failure Factors</th><th>Challenged Project</th><th>Impaired Project</th><th>Correspondence Failure</th><th>Process Failure</th><th>Interaction Failure</th><th>Expectation Failure</th><th>Escalation Failure</th><th>Termination Failure</th></tr></thead><tbody><tr><td>Project</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Team</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>*</td><td>-</td><td>-</td></tr><tr><td>User</td><td>*</td><td>-</td><td>-</td><td>-</td><td>*</td><td>-</td><td>-</td><td>*</td></tr><tr><td>Goal</td><td></td><td>*</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Resources (People, Time and Money)</td><td>*</td><td>-</td><td>-</td><td>*</td><td>-</td><td>-</td><td>*</td><td>-</td></tr><tr><td>Requirement</td><td>-</td><td>*</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Planning and Control</td><td>-</td><td>*</td><td>-</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>PM</td><td>-</td><td>*</td><td>-</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Technology</td><td>-</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>*</td></tr><tr><td>External Environment</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Process Features</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Organisation</td><td>-</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>*</td></tr><tr><td>Learning</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>IS</td><td>-</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>*</td></tr><tr><td>Conceptual Problem</td><td>-</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>People Problem</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>*</td><td>-</td><td>-</td></tr><tr><td>Complexity Problem</td><td>*</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Outsourcing</td><td>-</td><td>*</td><td>-</td><td>-</td><td>-</td><td>*</td><td>-</td><td>-</td></tr></tbody></table>

# 7 Discussion

Early warning signals are critical in identifying potential project failures. The failure of IS can be classified into development and user level failures (Lyytinen, 1988). This classification is helpful in categorizing failure factors and understanding the commonality of factors between users and other stakeholders involved in the development. An important distinction is the difference between the Project and PM since the scope of involvement between the project team and the users differ. Munns and Bjeirmi (1996) define project team involvement in planning, development and handover stages, whereas the user or client is involved in all stages of the project.

The iron triangle measures of cost, time and quality has been a powerful influence on project management in all sectors. Cost and time are difficult to measure during the
early stages of a project and may continue to shift over the project life cycle. Quality
measurement is highly dependent on perception, and will also change during the
lifecycle (Atkinson, 1999). When these measures are mapped against the classifica-
tion criteria, cost, quality and time factors are related mostly with PM. The PM falls
into the subset of project factors and it is important to capture failure factors at the
PM stage since they may provide an early warning for factors that might arise later.
PM might be successful without any apparent failures, but nonetheless, a project can
be deemed a failure, with failure factors emerging at a later stage (Munns & Bjeirmi,
1996). Many studies have focussed on Project failures but few studies specific to PM
failures. Common failures are missed budgets, time and user expectations. With diffi-
culty in defining failure or success the project may avert failure by grouping the fac-
tors based on the Project Life cycle stages.

Many studies have focused on the identification of the factors leading to IT failures. Early studies focused on individual explanations, with later studies finding behavioural and social factors. Later research focuses on success and failure factors in PM, organisation and process (Attarzadeh & Ow, 2008; Sauer et al., 1997). An additional factor is the role of cultural differences. Hofstede's dimensions are valuable but are the subject of few studies (for example, Schmidt et al., 2001; Shore and Cross, 2005). This paper attempted to classify the cultural element mapped across the project life cycle stages.

Many works have analysed and listed failure factors from impaired projects, stating what may have gone wrong pointing to the “Lesson Learnt” registers which exist to prevent such failures in the future. However, further focus on early warning indicators of failure factors would be beneficial. Charette (2006) sees a metaphor with an airplane crash where there are many levels of safety warnings, and after a crash, extensive investigation seeks to identify the failure factors. Similarly, in IT failure, greater focus on early warning indicators and the learning from failure need to be incorporated into the PM process (Charette, 2006).

8 Conclusion

This paper sought to identify factors contributing to IS/IT project failure by reviewing
relevant literature. These are the conclusions drawn from the literature analysis and
categorisation of IS/IT project failure literature: (1) It is important to distinguish be-
tween factors impacting the project and PM. The project involves a longer time
whereas PM is only until project handover; (2) The majority of project failure factors
occur in combination rather than in isolation; (3) Failure factors are complex and
interdependent; (4) External factors play a major role in impacting failure. Recent
studies focus on behavioural and social factors and project management, organisation
and process framework covering success and failure factors; (5) Failure factors in the
West differ in prioritisation compared with the East, with more focus on failures of
PM and planning factors in the East compared organisation and user related factors
which are more prevalent in the West; and (5) Early warning signals have taken on a
new importance to prevent the major failures from occurring.
## 8.1 Theoretical Contributions and Implications

This research contributes by identifying, collating, analysing and synthesising existing research on the failure of IS/IT project and project management. It provides a list of large number of factors highlighting those that are reported in more than one study. This study also attempts to identify failure factors by a particular geographical location. In brief, this paper offers a one-stop source for literature on failure of IS/IT project for both researchers and practitioners. Based on synthesis of findings from existing literature, the following recommendations can be formed: (1) Training and usage of standard Project Management tools can be the key to avoiding failure factors; (2) Dedicated focus on requirements, project management and learning and knowledge management is required to avoid failures with requirement aspect being most critical; (3) User experience and feedback should be sought throughout the Project Lifecycle; (4) Supplier selection, evaluation and management can be critical to avert failures and ensure success in outsourced projects; and (5) Project Managers should focus on governance, risk management and regulatory factors to stay ahead of competition.

## 9 References

Al-Ahmad, W., Al-Fagih, K., Khanfar, K., Alsamara, K., Abuleil, S., & Abu-Salem, H. (2009). A Taxonomy of an IT Project Failure: Root Causes. International Management Review, 5 (1), 93-104.

Atkinson, R. (1999). Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. International Journal of Project Management, 17 (6), 337-342.

Attarzadeh, I. & Ow, S.H. (2008). Project Management Practices: The Criteria for Success or Failure. Communications of the IBIMA, 1, pp. 234-241.

Avots, I. (1969). Why Does Project Management Fail? California Management Review, 12 (1), 77-82.

Belassi, W., &Tukel, O. I. (1996). A new framework for determining critical success/failure factors in projects. International Journal of Project Management, 14 (3), 141-151.

Beynon-Davies, P. (1995). Information systems 'failure': the case of the London Ambulance Service's Computer Aided Despatch project. European Journal of Information Systems, 4, 171-184

Bignell, V., & Fortune, J. (1984). Understanding Systems Failures. Manchester: Manchester University Press.

Brown, A. D., & Jones, M. R. (1998). Doomed to Failure : Narratives of inevitability and conspiracy in a Failed IS Project. Organisation Studies, 19 (1), 73-88.

Camprieu, R., Desbiens, J., & Feixue, Y. (2007). 'Cultural' differences in project risk perception: An empirical comparison of China and Canada. International Journal of Project Management, 25, 683-693.

Charette, R. N. (2006, August 29). Why Software Fail. Retrieved July 02, 2012, from IEEE Spectrum : http://www.spectrum.ieee.org/print/1685

Chen, J., Xu, L., & Whinston, A. (2009). Managing Project Failure Risk Through Contingent Contracts in Procurement Auctions. Advance, 1-17.

Conboy, K. (2008). Project Failure en Mass: A Study of Loose Budgetary Control in ISD Projects. Sprouts: Working Papers on Information Systems, 8 (40), 1-14.

Dalcher, D. (2003). Understanding Stories of Information Systems Failures. Action in Language, Organisations and Information, (pp. 221-236). Sweeden.

Dalcher, D., & Drevin, L. (2003). Learning from Information Systems failures by using narrative and ante-narrative methods. Proceedings of SAICSIT, (pp. 137-142). UK.

Davis, G., Lee, A., Nickles, K., Chatterjee, S., Hartung, R., & Wu, Y. (1992). Diagnosis of an information system failure: a framework and interpretive process. Information and Management, 23, 293-318.

Dickson, G. W., Senn, J. A., &Cherv, N. L. (1977). Research in Management Information Systems: The Minnesota Experiments. Management Science, 23, 913-934.

Evans, M. W., Abela, A. M., &Beltz, T. (2002, April). Seven Characteristics of Dysfunctional Software Projects. The Journal of Defense Software Engineering, 16-20.
Ewusi-Mensah, K. (2003). Software Development Failures: Anatomy of Abandoned Projects. London, England: The MIT Press.

Flowers, S. (1996). Software failure: management failure. Chichester, UK: John Wiley.

Field, J. (1997). *Passive or Proactive? Adults Learning* 8, no. 6 (February 1997): 160-

Gauld, R. (2007). Public sector information system project failures: Lessons from a New Zealand hospital organization. *Government Information Quarterly*, 24, 102–114.

Hartwick, J., & Barki, H. (1994). Explaining the role of user participation in information system use. *Management Science*, 40 (4), 440-465.

Heeks, R. (2006). Health information systems: Failure, success and improvisation. *International Journal of Medical Informatics*, 75, 125–137.

Hirschheim, R., & Newman, M. (1988). Information Systems and User Resistance: Theory and Practice. *The Computer Journal*, 31 (5), 398-408.

Hofstede, G. (1991). *Cultures and Organisations: Software of the Mind*. UK: McGraw Hill Book Company.

Hofstede, G. (2012, April). *National Culture. Retrieved April 20, 2012, from Geert Hofstede: http://geert-hofstede.com*

Irani, Z., Sharif, A., & Love. (2001). Transforming failure into success through organisational learning: an analysis of a manufacturing information system. *European Journal of Information Systems*, Vol 10, 55–66.

Jiang, J. J., Klein, G., & Balloun, J. (1998). Perceptions of system development failures. *Information and Software Technology*, Vol 39, 933-937.

Johnson, J., Boucher, K. D., Connors, K., & Robinson, J. (2001, February/March). Collaboration: Development & Management Collaborating on Project Success.

Jones, C. (2004, October). Software Project Management Practices: Failure Versus Success. *The Journal of Defense Software Engineering*, 5-9.

Kappelman, L. A., McKeeman, R., & Zhang, L. (2008, Fall). *Early Warning Signs Of IT Project Failure: The Dominant Dozen*. *Information Systems Management*, 31-36.

Lyytinen, K. (1987). Different Perspectives on Information Systems: Problems and Solutions. *ACM Computing Surveys*, Vol. 19, No. 1, 1-46.

Lyytinen, K., & Hirschheim, R. (1987). Information systems failures: a survey and classification of the empirical literature. *Oxford surveys in information technology*, 4(1), 257-309.

Lyytinen, K., & Robey, D. (1999). Learning Failures in Information Systems Development. *Journal of Information Systems*, 9, 85-101.

Markus, M. (1984). Power, politics, and MIS implementation. *Communications of the ACM*, 26 (6), pp. 430-444.

Miller, J. (2008). A total benefits strategy is a valuable approach in HR outsourcing. *Employment Relations Today*, 34(4), 55-61.

Mitev, N. N. (1996). More than a failure? The computerized reservation systems at French Railways. *Information Technology &People*, Vol. 9 No.4, 8-19.

Morris, & Hough, G. (1987). *The Anatomy of Major Projects*. New York: John Wiley and Sons.

Munns, A. K., & Bjeirmi, B. F. (1996). The role of project management in achieving project success. *International Journal of Project Management*, 14(2), 81-87.

Nasir, M. H. N. M., & Sahibuddin, S. (2011). Addressing a critical success factor for software projects: A multi-round Delphi study of TSP. *International Journal of Physical Sciences*, 6(5), 1213-1232.

Nelson, R. R. (2007). *IT Project Management: Infamous Failures, Classic Mistakes, and Best Practices*. MIS Quarterly Executive, 6 (2), 67-78.

Newman, M., & Sabherwal, R. (1996, March). Determinants of Commitment to Information Systems Development: A Longitudinal Investigation. *MIS Quarterly*, 23-54.

Pinto, J. K., & Mantel, J. S. (1990). *The Causes of Project Failure*. *IEEE Transactions On Engineering Management*, 37 (4), 269-275.

Rees-Caldwell, K., & Pinnington, A. H. (2012). National culture differences in project management: Comparing British and Arab project managers' perceptions of different planning areas. *International Journal of Project Management*, 20, 1-16.

Sauer, C. (1993). *Why information systems fail: A case study approach*. Oxfordshire: Alfred Waller.

Sauer, C., Southon, G., & Dampney, C. N. (1997). Fit, failure, and the house of horrors: toward a configurational theory of is project failure. *Proceedings of the eighteenth international conference on Information systems (pp. 349-366).* Atlanta, GA, USA: ICIS.
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.

Shore, B., & Cross, B. J. (2005). Exploring the role of national culture in the management of largescale International Science Project. International Journal of Project Management, 23, 55-64.

Standish Group Report (1995, July 01). Chaos Report. Boston, Massachusetts, USA: Standish Group. Retrieved from www.standishgroup.com

Stewart, R. A., & Mohamed, S. (2004). Evaluating web-based project information management in construction: capturing the long-term value creation process. Automation in Construction, 13 (4), 469-479.

Thong, J. Y., Yap, C.-S., & Raman, K. S. (1994). Engagement of External Expertise in Information Systems Implementation. Journal of Management Information Systems, 11 (2), 209-231.

Tukel, O. I., & Rom, W. O. (1998). Analysis of the characteristics of projects in diverse industries. Journal of Operations Management, 16, 43-61.

Verner, J., Sampson, J., &Cerpa, N. (2008). What factors lead to software project failure? Research Challenges in Information Science. Second International Conference, pp. 71-79. Marrakech: RCIS.

Wallace, L., Keil, M., &Rai, A. (2004). Understanding software project risk: a cluster analysis. Information &Management, Vol 42, 115-125.

Yeo, K. (2002). Critical failure factors in information system projects. International Journal of Project Management, Vol 20, 241-246.