**3. Methodology**

Given the immense cost of these high levels of failure [2, 3], it is puzzling that greater progress has not been made to ensure that IT Projects are more consistently delivered to specification

One of the reasons for explaining this high rate of failure is that it has been assumed that IT project failure is due to shortcomings in generic project management capability, rather than due to attributes of IT projects in particular. For example, 'most of the improvement efforts have focused on advancing variations of the traditional project management paradigm, such

Two questions arise regarding IT project failure research. First, why is the success rate of IT projects so poor? And secondly, why, despite the efforts of many, the situation fails to improve? This problem is known as 'Cobb's Paradox' [5], which states: 'We know why projects fail; we know how to prevent their failure—so why do they still fail?'. Cobb made the observation in 1995 while attending a presentation by the Standish Group (authors of the Chaos series of reports) while working at the Secretariat of the Treasury Board of Canada. Cobb's observation that 'we know why projects fail' should not be taken in a literal, completely black and white sense, rather it should be considered to be a reference to the collective body of expert commentary, opinion, research and project practitioners that have offered solutions. Despite the successful implementation of major IT projects, repeatable success

Cobb was not alone in observing that there is a great deal studied and written about project failure, and that consulting firms propose methodologies and remedies but little actual progress appears to have been made. The International Federation for Information Professionals (IFIP) Working Party 8.6 ran a conference to address this specific issue asking 'why our scholarship has not been more effective. Is the fault one of theory and inadequate understanding? Or is the problem one of knowledge transfer, the failure to embed research knowledge in the

For the purposes of consistency this research has adopted the widely understood term for project failure as being projects that fail to be delivered on time, on budget and with the

Previous research has identified high-level issues, in particular lack of senior management involvement [8] or a lack of clearly identified deliverables. The 'problem of poor requirements engineering and management has been repeatedly and widely discussed and documented for at least 10 years as a contributing cause of project failures' [9] yet the continuous research and new technologies on these topics 'has not resulted in a practical solution to the problem'. IT project failures 'have been extensively documented and studied' but with little progress actually being achieved makes 'Cobb's paradox as topical today as it was a decade ago' [10]. It is clear that despite decades of industry experience and practice, decades of research, consulting and advice, there exists little consensus as to why projects continue to run over-budget,

as (that which) is embodied by the Project Management Body of Knowledge' [4].

and customer satisfaction.

30 Dark Sides of Organizational Behavior and Leadership

continues to be elusive [6].

**2. What is project failure?**

required scope and functionality.

working practices of managers and policy-makers' [7].

The primary focus of this research was to address the lack of clinical studies in the literature on IT project failure, and to understand the failings that have occurred in a 'sticky, practicebased problem' [12].

The primary case study documents comprising the raw data collection were drawn from two sources:


The total number of pages of witness statements amounted to 3850. In addition there was a collection of project documentation gathered through Freedom of Information requests that exceeded 5000 pages of emails, reports, project plans and other data.

The data and its collection were independent of the researcher and have been drawn directly from the project and from a Government led inquiry into the project. Witness Statements were taken under Oath by representatives of a Court.

The data collection was rigorous and extensive, with thousands of pages of material examined thus supporting 'triangulation and sampling' [14]. The large amount of data collected allowed the researcher to minimise influences that might occur in a small data-set. The large volume of both project data and witness testimony ensured that bias had been removed from the source data (as far as practicable), and that subsequent observations could be compared and contrasted across the multiple statements and project records providing, as far as possible, a balanced perspective to emerge.
