Scholarly article on topic 'Why Do Information Technology Projects Fail?'

Why Do Information Technology Projects Fail? Academic research paper on "Educational sciences"

Share paper
Academic journal
Procedia Computer Science
OECD Field of science
{"project management" / "IT project failure" / "UK e-borders" / LAUSD}

Abstract of research paper on Educational sciences, author of scientific article — Adam Alami

Abstract With developing technological possibilities, IT projects are becoming increasingly ambitious in both goals and scale. Although technology itself is enabling easy management of project execution, failure can still occur, particularly with respect to an ample number of unique projects. It is argued here that the ampleness and uniqueness of projects provide criteria for such projects to be treated differently from smaller-scale enterprises of the same type. Gaps can be identified in the literature with regards to exact definitions of project success and failure. It is proposed that three main issues can impact a project's ecosystem and determine its failure, namely, uncertainty, volatility, and unknowns. Based on these aspects, future project performance can be estimated and correspondingly managed. At the same time, retrospective assessment of success or failure may be made rigorous based on exact definitions. Two case studies of major technological projects are presented and discussed here as examples of theory application.

Academic research paper on topic "Why Do Information Technology Projects Fail?"


Available online at


Procedia Computer Science 100 (2016) 62 - 71

Conference on ENTERprise Information Systems / International Conference on Project MANagement / Conference on Health and Social Care Information Systems and Technologies, CENTERIS / ProjMAN / HCist 2016, October 5-7, 2016

Why Do Information Technology Projects Fail?

Adam Alami*

Melbourne, Australia


With developing technological possibilities, IT projects are becoming increasingly ambitious in both goals and scale. Although technology itself is enabling easy management of project execution, failure can still occur, particularly with respect to an ample number of unique projects. It is argued here that the ampleness and uniqueness of projects provide criteria for such projects to be treated differently from smaller-scale enterprises of the same type. Gaps can be identified in the literature with regards to exact definitions of project success and failure. It is proposed that three main issues can impact a project's ecosystem and determine its failure, namely, uncertainty, volatility, and unknowns. Based on these aspects, future project performance can be estimated and correspondingly managed. At the same time, retrospective assessment of success or failure may be made rigorous based on exact definitions. Two case studies of major technological projects are presented and discussed here as examples of theory application.

© 2016 The Authors.PublishedbyElsevierB.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.Org/licenses/by-nc-nd/4.0/).

Peer-review under responsibility of the organizing committee of CENTERIS 2016 Keywords: project management; IT project failure; UK e-borders; LAUSD

1. Introduction

According to a 2009 IDC (International Data Corporation) report on Improving IT project outcomes, 25% of IT projects experience outright failure1. Based on the same report, up to 50% of the projects require material rework,

* Corresponding author. Tel.: +0-000-000-0000; fax: +0-000-000-0000. E-mail address:

1877-0509 © 2016 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.Org/licenses/by-nc-nd/4.0/).

Peer-review under responsibility of the organizing committee of CENTERIS 2016 doi:10.1016/j.procs.2016.09.124

and 20% to 25% do not provide Return On Investment (ROI). Project management is documented to be a major cause of IT project failure, whereas it has been part of IT for a long period of time2.

A 2012 Garner study3 revealed that IT project risk increases with size, namely, that smaller projects are less prone to failure than larger ones. Further to this relation, the report sheds light onto the most probable reasons for failure. Thus, it was found that a quarter of the unsuccessful IT projects with a budget larger than $350,000 suffered due to uncontrollably increasing and non-forecasted budgetary costs. A comparison between such projects, those with smaller budgets, and those with budgets over $1M showed that the larger projects have an underperformance rate of approximately 50% or more. The definition of success in a project comes from the Standish Group. Successfully completed IT projects must be completed at a cost equal to the allocated budget, within the deadline, and with complete delivery of the required functionalities. The conclusion of the Gartner report was that only 16.2% of the projects met these requirements and partially unsuccessful projects accounted for 52% of the projects under investigation, whereas 31% have been declared complete failures.

At this point, however, experts are divided over a complete and rigorous definition of success and failure4. Such a definition is typically made by each respective expert through subjective assumptions and conceptions. For most of them, success is equated to achievements, such as on-time and on-budget delivery. Failure, on the other hand, is described as a privative, respectively, the absence of success. However, achieving success is relative to each case through its dependency on parameters specific to each project. This mentality does not create perfect grounds for comparison between projects. Moreover, dichotomy is created by separating various states of success into mutually exclusive categories, either success or the lack thereof, namely, failed projects. The present paper proposes that success—or its absence—can be measured by using the following key parameters: the initial investment made by the sponsoring organization and whether the requirements defined in the beginning have been attained as forecasted. Following this proposal, failure occurs when at least a part of the investment must be forfeited (financial loss) and/or the agreed-upon deliverables have not been achieved.

Very little research has attempted an in-depth investigation of failed projects to identify exactly what the factors were behind the failure. In this article, we share the analysis of two high-profile projects' failures. The data was gathered from various public sources. Our analysis indicates that the reasons for the failure of some of these projects may have included the following:

1. Unbalanced ecosystems: Projects fail because they cannot survive in their ecosystems. Projects cannot be executed in unbalanced ecosystems. A project's ecosystem must be kept balanced. Signs of disturbance introduced to the ecosystem must be detected and managed accordingly5.

2. Delivering complex transformation is not about meeting the deadlines. Transformations are delivered with "roadmaps", not schedules, and by acknowledging and assessing the magnitude of the change to tailor a delivery strategy.

3. Poor project management practice.

2. Research methodology

Grounded Theory methodology employed in this study refers to a method of data collection used in gathering qualitative data from secondary sources6. Glaser7 defines Grounded Theory as the implications of signs in community relations and the interaction of these symptoms between subjects and their actions.

Discovering constructs or theories of IT projects' failures was of interest in this study, and the connection between the constructs was reviewed. Thus, the research outcome for this study rose from Grounded Theory. The theoretical concern in Grounded Theory involved the pillar of action and relationship among and between various types of the complex social units. The study was interested in understanding the whole process rather than individual stages or phases. Additionally, the study was concerned with the effect of dynamism in patterns depicted in conditions of action or interaction as either internal or external to the process.

2.1. Data collection

Two recent, publically known cases of IT project failure were selected to be the subject of this research study:

1. The e-Borders project

2. The Los Angeles Unified School District (LAUSD) Instructional Technology Initiative

This study utilized secondary sources that we initially validated before being engaged in the data analysis. Meriam8 distinguishes that materials of all types are helpful to the researcher as they aid understanding, bringing out the meaning and enabling discovery of perceptions related to the research problem. Data collection was mainly conducted by use of secondary sources bearing previous studies on the research topic, such as public records, news articles, published reports, and official statements.

Yin9 emphasized that secondary documents used should cover a long span of time, several events, and different settings. Furthermore, the materials used ought to be mutual and originating from the social usage and should be in an orderly manner10. Existing history and data on a project provide an understanding on which researchers work to rectify the failures experienced. Documents provide a firm background on historical understandings of the topic under study. The dynamic nature of projects requires the knowledge of the evolution of such projects over time. Different documents available to the researcher provide a basis for comparison of changes and the clear path of development6.

2.2. Data Analysis

This critical step involves results and selecting, appraisal, and interpretation of data contained in the data collection. The analysis provides data, extracts, or quotations, or the whole document can be organized into main categories via content being analysed under each category11. The analytical procedure commences with the keywords and giving out their meanings, identifying concepts and their magnitude as used in data, and creating subsections that mainly deal with a case study on a sub-phenomenon. Strauss and Corbin12 offer three methods of experimenting with the meaning of the keywords and phrases during data analysis: (1) open coding, which refers to a process where concepts are identified as well as discovering their dimensions and properties; (2) axial coding, a process of creating substances besides linking them with dimensions and properties; and (3) selective coding, which involves refining and integrating the theory by utilizing categories besides their linkage with the sub-categories to develop a type of case study of a particular sub-phenomena.

Additionally, Strauss and Corbin9 confirm that it is necessary to observe theoretical sampling to ensure that all categories are well represented in the survey. Again, there is the need for re-evaluation of themes and sub-themes at each section to ensure the samples are representative of the classes of Grounded Theory analysis. The categories and topics used in the study formed the hypothesis or research question via an approach called selective coding.

3. Case studies

3.1. Case I: The e-Borders Project

This section presents a case study of the e-Borders programme, initiated in 2003 by the Home Office with the purpose to implement a novel and superior border control in the United Kingdom. In 2007 the £750 million initiative was contracted to Raytheon Systems. Three years later, in 2010, the Home Office was unsatisfied with the project execution and initiated its termination.

The programme's goal was the creation of a technological border control system13, which allowed for addressing various legal issues that stopped inter-agency information sharing14. Another important aspect was to create a better base for the use of the existing resources, allocated at the time in disproportionate numbers to arrivals control. This would have resulted in increased capacity of airports15. The project had a demographic side that implied storage of information regarding the UK citizens crossing the border. At the same time, passengers could have been assessed in advance of physical arrival due to British inter-agency cooperation16. The main business requirements of the e-Borders project were a) increased effectiveness of border control resources in use through need-based allocation; b) identification, refusal of entry, and removal of inadmissible individuals; and c) inter-agency information sharing and

deployment regarding targets identified by the system as potential threats or persons of interest. Further, cost savings and reduced smuggled goods penetration into the country have been expected of the project17,18.

The environment of the project was structured around political and social needs, such as improved control of the safety of UK citizens. A cooperation of border control with intelligence services was seen as an improvement over the then-current practices. Within this environment, the Home Office was the stakeholder, and Raytheon Systems was the project supplier. Serco and IBM were enrolled as suppliers in e-Borders to replace Raytheon after contract termination.

The e-Borders project initiative originated from 2003, when it was intended for passenger data collection for all traffic going into and out of the UK. The precursor of the e-Borders deployment was the Semaphore pilot, which was deemed to be a success in 2006. Consequently, the HOGIB (Home Office Group Investment Board) released the funding for the full e-Borders version of the programme. In November 2007 Raytheon Systems won the contract that allowed the company to implement the programme for the next four-year period. Based in the United States, Raytheon focused its core business on defence and technology11. In 2010 the contract of £750 million had missed multiple successive milestones and had problems with the service quality, for which reason the Home Office decided to terminate it19.

The quantitative performance indicators that had not been achieved were a) 95% of data of incoming and outgoing passengers to be collected prior to arrival at the border for analysis by the end of 2010 and 100% by the first quarter of 2014 and b) integrate the two then-currently existing systems within one system by April 201116. In fact, not a single milestone had been delivered by the termination of the contract despite the scheduled timeline. Instead of the 95% target, the project only managed to track and record 86% of the data.

The requirement analysis was executed in detail only after Raytheon was awarded the contract, designs being in place before detailed requirements were known with exactitude. Overly ambitious promises were made, mostly based on lack of understanding of the precise project needs and sheer time pressure due to the Olympics. What the project involved was to collect, analyse, and compare data originated in 200 million transits per year and to coordinate data from 30 departments of the government and 600 rail, ferry, and air carriers. Moreover, key personnel left the project very often, a fact that combined with micromanagement from ministers and other officials of the government.

The project had to be fast-tracked due to the 2012 London Olympic Games, when a large supplementation of arrivals was expected. During the same period, Raytheon Systems sued the Home Office for wrongful termination. After four years of hearings, Raytheon received a favourable court decision that ordered them to be paid £224M representing wrongful cessation rights and accrued interest, a decision that was attacked by the Home Office. Finally, a settlement has been reached. While it can be argued that the sheer number of stakeholders made proper stakeholder management impossible, a similarly simple counterargument can point out that IBM and Serco succeeded in the same conditions.

3.2. Case II: LAUSD Instructional Technology Initiative

This section presents a case study of Instructional Technology Initiative (ITI) by the Los Angeles Unified School District (LAUSD). The challenges leading to the failure of the ITI project in the school district, the consequences resulting from the IT project failure, and the actions that have been taken to manage the effects of the failure are briefly discussed here.

Handing out of iPads as part of the Instructional Technology Initiative was considered to be one of the most ambitious rollouts of technology in schools. Through technology resources, ITI sought to offer lessons, assignments, assessment, and contents aligned to the Common Core State Standards20. As part of the initiative, the external vendors and internal district staff were to provide professional development to support school-based leadership for the initiative. LAUSD entered into a contract with Apple to provide iPad devices to 650,000 students in the district as part of a digital transformation in education through a bundled digital curriculum by Pearson Education21.

ITI implementation began in 2013. At that particular time, it was identified as the Common Core Technology Project. The expected results of the ITI project were to provide tools/devices to educators so as to advance the learning of the students and create a learning space designed and formulated to increase engagement of the learners22. The initiative was expected to offer support for the implementation of the Common Core State Standard

through the provision of an opportunity to all students so as to engage with interactive support and digital curricula together with adaptive assessments. Also, LAUSD sought to close the gap in the digital divide by ensuring that 21st century technology is accessible to all students25.

The expected outcomes were facilitated through the provision of technological resources to schools by the district. To ensure the safety of students, various policies and procedures were adopted. Also, resources were committed to supporting school teachers and leaders in using the technology for instruction23.

On behalf of LAUSD, Superintendent John Deasy—a year into his tenure and seeking to overturn the school system crisis—initiated talks with Pearson PLC with the intention to work on a digital transformation in public education in 2012. This was an urgent mandate because a) more than 10,000 students were dropping out of high school every year; b) fewer than half of students were reading at grade level; and c) teachers, librarians, and counsellors in Los Angeles lost their jobs as a result of the recession. Pearson showcased still under development software meant to revolutionize education through videos, games, and interactive elements19. In March 2013 LAUSD put the project out for public bid under the name of the Common Core Technology, where the $1.3 billion contract was won by Pearson and Apple on June 24, 2013. The two companies won after district school staff committees picked them from 19 total bids18. Under the contract, Apple was tasked with providing iPads bundled with Pearson-developed digital curriculum resources. The goal was to have the 650,000 students endowed with iPads.

Pearson was selected on the basis of curriculum samples based on the contract, respectively math and English only24. The bundling of the curriculum and the device contributed to the rising cost of the project, where an additional $200 was expensed per each iPad, which stood at $76825. The initial adoption of ITI through iPad rollout faced challenges from the initial adoption. The Pearson curriculum software was designed "in vitro", yet they gave assurance that the program works under certain implementation purposes21. Based on technological overview, it is hard to create a program that enhances learning while supporting all the practicalities25 of schools. Time-consuming distribution and collection of iPads each day and overnight security presented a tremendous challenge to most schools. Tracking who had returned the devices presented a formidable task, whereas loss would hinder children from learning25. Tablets breached school security, including websites access (e.g., YouTube or Facebook). Fewer than 5% of the students had access to content, a fact attributed to technical issues. Frequent disruption of access was common, whereas the provided materials were not suited for students with low English proficiency. Neither utilization guides nor progress tests were available online, whereas Pearson was not tracking the program usability19. In March 2014 nearly all schools had stopped the usage of Pearson curriculum due to crippling technical problems and incompleteness21.

Due to immense pressure and criticism, Deasy resigned from the school district in October 201418. In December 2014 LAUSD officially terminated the contract with Apple as a result of frequent problems on the daily use of the curriculum, which frequently interrupted normal learning in schools. Based on these problems and following the termination of the contract, LAUSD sought a refund from Apple. Through its attorneys, the district required a closed-door meeting to explore possible litigation against the two companies. Pearson was included as a subcontractor to Apple because they developed the curriculum18. In September 2015 Apple agreed to repay $4.2M to settle the litigation filed by LAUSD. Apple would have earned a total of $30M upon completion of the first phase26. The Board of Education agreed that the money repaid by Apple would be used to acquire computers within a new program.

4. Findings

Beyond a phenomenological description of project management as a process, the discipline should firstly be defined as the endeavour to produce deliverables in a complex ecosystem dominated by a) frequent changes in scope, b) uncertainty, c) unknowns, and d) complexity.

The failure of the e-Borders case was due to suboptimal management, adverse ecosystem conditions combined with poor risk management, and multiple failures in execution. Although LAUSD seemed to have a relatively balanced ecosystem, it failed to deliver its mandate. The project was a victim of its simplistic view on execution. It had a genuine idea but lacked the know-how of project execution.

4.1. Ecosystem survival

Structures that become manifest in the interdependencies between entities and resources can be described as ecosystems. Some of the entities may be persons, such as stakeholders, whereas the resources can originate in the business requirements or the culture of the organization. Due to their inherent differences, projects function within their unique ecosystems. Each part of an ecosystem has its own impact during the execution phase. At the same time, ecosystems have their own intrinsic dynamics, whereas certain parts of ecosystems can manifest unpredictability and volatility, particularly during transitions.

A highly stable ecosystem will favour flawless execution. Unstable dynamics, on the other hand, are prone to create environments unfavourable for delivery. A good example of such unstable dynamics inside a programme ecosystem is the e-Borders case. In that case, the instability was reflected in poor execution and difficulties in survival. Suboptimal management was performed on the volatility determinants, the unknowns, and uncertainty inside the programme27.

According to the National Audit Office report28, the desired outcome was to maximally strengthen the border security by the middle of 2011. For this reason, the Department "felt it was necessary to be ambitious on scope and timescale". The realism and proper risk management have been sacrificed in favour of political ambition. Consequently, the failure occurred through lack of acknowledgement regarding important parts of the programme ecosystem. An imbalanced dynamical ecosystem can easily be perturbed by further disturbances introduced by the participating actors. In this case, the pressure created by ambition and the neglect of realism introduced fragility into the ecosystem. The main actors have been further motivated and pressured to follow through with the original vision that had been set and carry on with its lack of realism.

The initial stages of requirements analysis and scheduling were impacted by the existing political ambition. Thus, the NAO23 analysis, based on the financial estimations of Raytheon, stated that the profit would have been reduced by 50% after a three-month delay. Even if the schedule was followed, the profit generation would have only started in 2012. Although the design proposal was included in the contract, it was based on insufficiently detailed requirements and therefore led to post-contract-awarding disputes generated by lack of confidence over whether the needs could be covered by the proposal or not. Despite the undoubtedly good intentions of the Home Office, ambition has overthrown realism, a fact attested to by this behaviour.

4.1.1. Volatility

Many projects are impacted by scope creep and frequent requirement modifications. These aspects are all encompassed by the concept of volatility. Insufficient predictability creates dynamics that impact execution and deliverables. Processes aimed at finding and developing solutions suffer most from volatility, a phenomenon that typically is directly proportional to the volatility degree. Although little control can be exerted on volatility, some instances may be managed or averted.

The NAO report23 noted that multiple and significant functionality changes impacted the border security project during a period of twelve years. Unforeseen technical aspects have proved challenging for the programme, which was unable to adjust to the constraints and requirements. As is the case when requirements are insufficiently documented, design work was performed prior to the project team being fully aware of the technical specifications. Under-developed requirements were wrongly used as a working assumption throughout the design phase, which amplified the background dynamics of the ecosystem.

Major transformations are equivalent to complex projects and are consequently exposed to more vulnerability to volatile conditions. The volatility is proportional to the amount of information that requires processing and integration. Another reason behind volatility in complex projects is the possibility to see discrete jumps between one requirement eliciting stage and the next. The working assumption is always that the requirements have been fully extracted and documented before moving on to the design stage, and therefore they will not be modified. In fact, this is not the case for all projects. The most complex projects always imply a minimal modicum of unpredictability and uncertainty during execution stages.

4.1.2. Uncertainty

Typically, projects execution implies working with known unknowns. These can be defined as the uncertainty level of the project. For example, this category encompasses the known risks that may impact the project while at the same time lacking a clear estimation of the consequences of the impact. The e-Borders case saw organizational transformation, variability within the working ecosystem29, and the termination of the Raytheon contract, among other events. Lacking a clear understanding of the impact of these events on the execution phase rendered them unmanageable.

4.1.3. Unknowns

The e-Borders and LAUSD projects faced multiple unknowns throughout their lifecycle. The unknowns typically are expected to be unexplored business needs or project-specific constrains and rules. A large density of unknowns trailing into the design stage increases the future volatility of the business requirements.

4.2. Execution

A delivery process staged and run with the purpose of supplying the required beneficial outcomes is the execution phase. In the case of the e-Borders programme, the delivery did not follow textbook recommendations on project management. Notably, the NAO23 report describes the execution of the e-Borders programme as lacking strategy. The Home Office did not carry out the project as a business transformation due to simplified ideas and an outline-only approach to the implementation of a complex situation.

LAUSD, on the other hand, seemed to have a chaotic and relaxed approach to the execution of the program. LAUSD did not take ownership of the execution. It had a simplistic understanding of delivering such a complex "digital transformation".

4.2.1. Business transformation

Typically, transformations are endeavoured according to road maps instead of schedules. For e-Borders, the focus was to obtain a specific outcome rather than to operate a change at a structural level. No road map has been developed for the vision of the programme or for the transformation. The NAO reported an overly ambitious timeframe and no clearly defined scope and implementation strategy. Furthermore, there are signs that the Home Office did not have a good estimation of the magnitude of the change applied to its operational model. At the same time, the project dynamics and unstable ecosystem needed a well-developed strategy to implement the transformation in the ranks of the employees and into the technology, risk and data management, and process aspects.

Similarly, LAUSD had no strategy to deliver its "digital transformation". Its idea of delivering a transformation implied selecting the vendors to provide the hardware and the software. The simplistic view of "plug it in and it will work" was suicidal.

4.2.2. Managing complexity

The success of a project is a direct consequence of the organisation's ability to understand, anticipate, and successfully find ways to overcome the complexity of a project. The e-Borders project failed by not managing complexity carefully enough, as noted by the NAO report, which mentions "poorly understood complexities". The complexity increases with uncertainty and limiting factors. Another important aspect particularly visible in the case of e-Borders was the uniqueness of the attempt.

Of utmost importance, a coherent vision and its implementation define the capabilities and maturity of a project's organisation. Maturity and capabilities develop while the organisation integrates experience into knowledge by learning. The novelty of a project is a major challenge when the experience with similar endeavours is on the low

side of the spectrum. While failing to acknowledge the uniqueness that posited a challenge for the e-Borders case, the Home Office contributed yet another factor to the final failure.

4.3. Project management practice

The practices and knowledge related to project management are widely documented and accessible to all, and yet most projects are not managed with these principles in mind30. The project management practice areas neglected by e-Borders were as follows: (1) proper practice of stakeholder management, (2) feasibility assessments, and (3) the extraction and analysis of requirements. Much in the same way, LAUSD provider Pearson Education accepted the plug-and-play mentality behind the simplistic requirements of the management of schools. Consequently, they offered nothing in the way of an integrated and manageable experience that could have offered support to the users.

4.3.1. Stakeholder management

Sponsors and stakeholders that are not maintained close and engaged with the project are prone to contribute to the failure rather than the success of the endeavour. On the contrary, involving a wide variety of end users and attempting to engage key stakeholders is critical for projects. Improper stakeholder management will result in alienation and resentment of the stakeholders towards the project.

The e-Borders project clearly lacked a focused strategy for managing stakeholders since stakeholders critical for the project did not receive proper rapport management and communication. For instance, a critical relation that was given insufficient attention was that with the transportation carriers. This was acknowledged in the NAO report, which noted that the project base of assumptions did not include proper stakeholder management. Similarly, LAUSD failed to engage the end users of the project output: teachers and schools. The district ran the programme in silo.

4.3.2. Feasibility

The Home Office and LAUSD had concepts rather than a well-developed set of requirements. As opposed to requirements, concepts have to be compared against the realities of the situation. Although a pilot project was in place with the purpose to perform a realistic evaluation and a feasibility study, this did not cover the wide range of implications and solutions that the project involved23. Thus, some areas were neglected, and the final deployment was made with only approximate knowledge, leading to disputes.

4.3.3. Requirements

In both cases, the programmes' execution was based on a proposed blueprint design rather than real needs or a realistic and tested concept. In cases where the exact needs cannot be identified and documented, the requirement analysis will always suffer. This is a major shift from ideal conditions, where precise business requirements can be pinpointed. Although the Home Office was able to present a concept in the e-Borders case, this concept was not accompanied by precise requirements. This has been noted by the NAO report, which stated that the project was not guided by clear ideas regarding which modifications should be operated on the business processes.

When the requirements are complex, a significant amount of time must be invested in the initial need collecting and analysis phase. The time investment is beneficial and can be recovered since the subsequent complexity will be reduced by this analysis. During the period in which requirements are defined and evaluated, stakeholders have the opportunity to explore their consequences and the unknowns, thus increasing the possibility to reach an informed decision31. As noted by NAO, the design suggested by Raytheon was attached to the contract, although it was not clear whether it could satisfy all the needs of the project, and it was founded on high-level analyses of requirements. Consequently, it can be argued that e-Borders lacked in the area of a stable and well-defined requirement management process. This created a volatile ecosystem containing two oppositely working partners: Raytheon often perceived the requirements as shifting, whereas the Department considered the provider's solutions to be insufficient. This background generated disputes and conflict in the interpretation of various parts of the agreement.

The Pearson curriculum software, on the other hand, was designed in a vacuum. The schools' needs were not analysed and documented. The schools had different ways of running curricula. Consequently, the software could not have dealt with all the practicalities taking place in schools32.

5. Conclusion

In the context of increasingly more complex Information Technology projects being supported by developing technology, endeavours undertaken by programme management experts have become larger and more ambitious. As one would expect, better technology creates a strong support for such large-scale projects to be executed. However, unique or massive projects still see frequent failure.

There is no consensus about how project failure and success should be defined. It is either subjectively defined or left to assumptions and interpretations. There have been various failed projects in the IT industry that memorably began as game-changers in the industry but instead failed to achieve all their objectives, resulting in significant losses by the respective companies.

Only a few research papers have attempted an in-depth investigation of failed projects to identify the exact factors behind the failure. In this article, we analysed two high-profile projects' failures. The data was gathered from various public sources. Grounded Theory was used to perform this research using the qualitative data collected from documents' analysis.

The present paper discussed some theoretical considerations and applied them to two case studies involving massive public service sector projects in the United States (LAUSD ITI) and the United Kingdom (e-Borders).

The e-Borders project failed when its ecosystem became unbalanced; hence survival became difficult. Projects' ecosystems are a reflection of the real world and are characterized by volatility, uncertainty, complexity, and unknowns. We can safely assume that when a project fails to manage one or more of these characteristics, its ecosystem becomes unbalanced. However, projects lack self-awareness of their ecosystem and its troubles.

LAUSD did not perform well in the areas of research and development, where the stakeholders focused on involving two companies to provide a one-size-fits-all solution18. The school district failed to understand that technology does not work in this miraculous and simplified way22. Instead, the project should have been about implementing a transformation, which requires thorough planning and good project management practice.

Organizations improve their delivery capacity by acquiring knowledge from past experiences. Each project failure must be investigated to deduce the true causes of the failure and hence a lesson(s) learnt for future projects33. Organizations' future projects will have similarities in their ecosystems' compositions as projects' ecosystems are instantiated partially from the organization ecosystem.

Organizations prefer to turn the page after a failure. The assumption that each project is a unique instance is true. However, the project's ecosystem will be, to a great extent, similar for future projects. What made a project fail in its ecosystem is a survival lesson for a future project.

Failures are opportunities to learn and improve. Each failure should be investigated and lessons drawn for future projects' executions. Knowledge about failure will strengthen an organization's project management execution and practice. What future research is needed to understand why projects fail? How can failure be converted into a learning opportunity? And how can lessons learnt be implemented into future projects?


1 Pucciarelli, Joseph C., Wiklund, Dana. "Improving IT Project Outcomes by Systematically Managing and Hedging Risk". IDC report (2009)

2. Gulla, Joseph. "Seven reasons why information technology projects fail." In SHARE Conference. 2011.

3. Mieritz, Lars. "Gartner survey shows why projects fail." Gartner Survey Shows Why Projects Fail. Gartner Survey Shows Why Projects Fail

501. 2012: G00231952.

4 Pankratz, Oleg, and Dirk Basten. "Ladder to success-eliciting project managers' perceptions of IS project success criteria." International

Journal of Information Systems and Project Management 2, no. 2 (2014): 5-24. 5555 Boonstra, Albert, Jan de Vries, Thomas Murphy, Kathryn Cormican, Leif Marcusson, and Siw Lundqvist. "Information system conflicts: causes and types." Information system conflicts: causes and types (2015).

6. Strauss, Anselm, & Corbin, Juliet. Basics of qualitative research: Procedures and techniques for developing grounded theory. The Qualitative

Research Journals, 17 (12) 458- 487. 1998

7. Glaser, Ronald, Janice K. Kiecolt-Glaser, Robert H. Bonneau, William Malarkey, Susan Kennedy, and John Hughes. "Stress-induced

modulation of the immune response to recombinant hepatitis B vaccine." Psychosomatic Medicine 54, no. 1 (1992): 22-29.

8. Merriam, Sharan B. Case study research in education: A qualitative approach. Jossey-Bass, 1988.

9. Yin, Robert K. Case study research: Design and methods. Sage publications, 2013.

10. Coffey, Steve, and Horst Stipp. "The interactions between computer and television usage." Journal of advertising research 37, no. 2 (1997):


11. Labuschagne, Adri. "Qualitative research-airy fairy or fundamental?." The qualitative report 8, no. 1 (2003): 100-103.

12. Strauss, Anselm, and Juliet Corbin. "Basics of qualitative research: Procedures and techniques for developing grounded theory." The

Qualitative Research Journals, 17 (12) 458- 487. 1998

13. Foxton, W. Government IT projects fail because of politicians, not programmers. [online] Technology - Telegraph. 2014. Available at: [Accessed 5 Feb. 2016].

14. Vaz, K. UK Border Agency. London: Stationery Office. 2010

15. Hampshire, James. "13. The future of border control: risk management of migration in the UK." Migration and mobility in Europe: Trends,

patterns and control (2009): 229.

16. GOV.UK. Home Secretary letter on the e-Borders programme arbitration. [online] 2014: Available at: [Accessed 5 Feb. 2016].

17. BBC. Home Office criticised over £830m 'failed' borders scheme. [online] BBC News. 2015. Available at:

34988913 [Accessed 5 Feb. 2016].

18. Press Association. E-Borders scheme to boost security 'wasted £830m'. [online] Mail Online. 2015. Available at: [Accessed 5 Feb. 2016].

19. Khan, Asad Ali. "Failure to Deal with the Issues: The e-Borders Award and 'Serious Irregularity' under the Arbitration Act 1996."Available

at SSRN 2604612 (2015).

20. Orlando, Joanne. "Educational technology: a presupposition of equality?." Asia-Pacific Journal of Teacher Education 42, no. 4 (2014): 347-

21. Margolin, Jonathan, Erin Haynes, Jessica Heppen, Kristin Ruedel, John Meakin, Alison Hauser, Jarah Blum, Suzette Chavez, and Alexandra

Hubbard. "Evaluation of the Common Core Technology Project." 2014.

22. Blume, H. L.A. school district demands iPad refund from Apple. [online] 2015. Available at: [Accessed 25 Feb. 2016]. 23 Lin, Hong. "Implementing Large-Scale Mobile Device Initiatives in Schools and Institutions." In Emerging Technologies for STEAM

Education, pp. 179-198. Springer International Publishing, 2015. 24. LAUSD Superintendent John Deasy says he is not scrapping district's $1 billion iPad program. [2016: online] Available at: [Accessed 29 Feb. 2016]. 25 Blume, Howard. "L.A. school district demands iPad refund from Apple". Los Angeles Times. 2015. Online: 26. Schaffhauser, Dian. Los Angeles Unified Cancels iPad Contract -- THE Journal. [2016: online] Available at: [Accessed 26 Feb. 2016]. 27 Arviansyah, A., Ton Spil, and Jos Hillegersberg. "Development and assessment of an instrument to measure equivocal situation and its causes

in IS/IT project evaluation." International journal of information systems and project management 3, no. 3 (2015): 25-45. 28. National Audit Office (NAO). E-borders and successor programmes. [online] Available at: [Accessed 5 Feb. 2016]. 2015

29 Huysegoms, Tom, Monique Snoeck, Guido Dedene, Antoon Goderis, and Frank Stumpe. "A case study on variability management in software

product lines: identifying why real-life projects fail." International Journal of Information Systems and Project Management 1, no. 1 (2013): 37-48.

30 Murphy, Thomas, and Kathryn Cormican. "Towards holistic goal centered performance management in software development: lessons from a

best practice analysis." Information system conflicts: causes and types (2015).

31. Alami, Adam. "Can Agile Reduce Complexity?" Project Smart. 2015. [Accessed 18 Jan. 2016].

32. Cherner, Todd, Judy Dix, and Corey Lee. "Cleaning up that mess: A framework for classifying educational apps." Contemporary Issues in

Technology and Teacher Education 14, no. 2 (2014): 1-61. 33 Chaves, Marcirio Silveira, Cíntia Cristina Silva de Araújo, Laura Ribeiro Teixeira, Debora Virginio Rosa, Irapuan Gloria Júnior, and Cláudia Dias Nogueira. "A new approach to managing Lessons Learned in PMBoK process groups: the Ballistic 2.0 Model." Developing and enforcing internal information systems standards: InduMaker's (2016).