Understanding Information Systems Failures

Published Date: 02 Nov 2017

Adeyemi J. Ige

Introduction

Learning is a process of observing and correcting error, whereas the definition for error is any feature of knowledge or knowing, that makes an action ineffective [2].

The field of Information Systems (IS) has generated many failures thereby offering an opportunity for studies into these failures to learn from it and contribute to the building of methodologies and frameworks to guide against the repetition of such failures whenever possible.

Learning usually happens during the observation of a mistake and the subsequent identification of the procedures that led to the mistake for correction [1].

Research into information systems failures face challenges regarding access to intimate information relating to the circumstances under which such failures happened, as well as insufficient information about the type of methods and processes useful in garnering such information and its dissemination [5].

Project Aim

The aims of this MSc dissertation are the understanding of information system failures as well as contributing to the formulation of frameworks and methodologies that will guard against such occurrences.

This project will use the Information System (IS) failure at Heathrow Airport Terminal 5 on its opening day of March 27, 2008 as a case study while also looking at various other system failures around the world to see the similarities or otherwise in the causes and effects of these failures

Background Survey

Software development is usually characterised by being over budget, delivered behind schedule, having reduced functionality and quality that often results in their cancelations, reduced scope as well as significant re-work cycles [5].

System failure is widely used as a label to categorise a wide group of failures, which includes those with undesirable side effects. The Standish group classified failed projects as distinct from challenged projects with successful projects having a different classification. Figure 1 shows an illustration of the 2009 Standish report summary [7].

Background Survey (Cont.)

Successful projects classified as being the projects completed on time, within budget as well as having all the initially specified features and functions while failed projects are those cancelled before completion, never implemented or stopped after deployment.

Challenged projects on the other hand attain completed status but are over budget, delivered behind schedule and have reduced functionality.

The development of IS can be portrayed as an innovation process based on three components comprising of the project organisation, the information system and the project supporters (or stakeholders) as shown in Figure 2 [6].

2000 to 2008 Project Resolution

Triangle of Dependencies

Solutions

Using case studies:

Case study is a term used in different contexts to mean separate things that may include a wide range of evidence and analysis procedures.

The case study approach�s primary aim is the understanding of phenomena in terms of issues in the original problem context. It allows the researcher to emphasise on a particular instance or subject and attempt to identify the main interacting perceptions, issues and processes at play resulting in a more in-depth understanding.

The focus on relationships and processes aids a comprehensive perspective revealing underlying patterns as well as some emergent properties. A large number of these patterns stay hidden under typical conditions but are now viewable under this special focus.

Case Study: Terminal 5 System

This was supposed to be a large complex project that was due for delivery on time and on budget, going against previous trends of such scale and magnitude. On its opening operational day of March 27, 2008, there was a massive system failure.

A combination of problems led to chaotic scenes, as passengers were unable to check-in baggage thereby resulting into the cancellation of several flights. The rate of moving hold baggage into the Baggage Handling System (BHS) was much greater than the rate of being loaded onto aircrafts by the Baggage and Logistics Operations staff leading ultimately to a gridlock in the system.

These problems continued into the weekend with more lost baggage and flight cancellations. News reports about the failure incident were unsurprisingly, not flattering.

With the failure of the baggage handling system, luggage accumulated to such an extent that it needed moving to offsite areas in the vicinity of the airport and to other airports for the process of re-screening, sorting and subsequent return to their owners. Information gathered from BA sources affirmed that 23,205 bags needed manual sorting before their return [9].

Inadequate communication, staff training and familiarisation as well as insufficient system testing played a major part in the problems encountered on the operational opening day.

This dissertation examines the story behind this failure. Two theoretical approaches to understanding other disasters will be analysed � normal accident theory and high reliability theory. The events of the opening operational day disaster appear like a �normal accident� [4,8], which is unsurprising given the systems high complexity.

Problem Areas at Terminal 5

Additional Failure Cases

Denver Airport Baggage Handling System (DABHS)

National Air Traffic Services (NATS)

Taurus

Failure Categorisation Bases

Failure Case Studies Analysis

The proposed technique for categorisation of IS failure reasons is applied to the main case study of T5 and the additional three failure case studies. Figure 5 highlights how the categorisation technique affects the process of exploring the failure reasons. It displays the situation of the case study projects before applying the categorisation technique.

The v implies the non-discovery of failure reasons or the existence of criteria for success while X implies the discovery of failure reasons. The result that appears is made up of eight categorisation bases and 27 subdivisions, and shows how the proposed technique affects the process of detecting IS failure or success reasons.

This technique may help in moving projects from a failure state to a success state and elucidates reasons that may be difficult to discover. Figure 6 highlights the impact of the categorisation technique on moving from a failure state to a success state using an assumed hypothetical scenario implementation on the main case study project of T5 and the additional case studies. It shows the status of the case study projects after applying the categorisation technique.

Failure Case Studies Analysis (Cont.)

The analysis of the failure case studies is done with the aim of integrating the various reasons responsible for IS failures. The two figures shown below (Figure5,6) identify the presence or absence of failure reasons in the respective subdivision of the categorisation bases for the case studies examined.

The X�s indicates that inadequacies were present in the project life, thereby creating the background for the type of failure experienced. The two case studies that suffered eventual cancellations had the lowest scores on Figure 5 with the presence of failure reason present in many subdivisions. Taurus had failure problems in 25 subdivisions, with DABHS having 23. NATS had 22 instances while T5 had 18 instances.

After applying the categorisation technique as shown in Figure 6, improvements can be seen with Taurus now having nine instances still present, with DABHS also having nine instances. NATS meanwhile had improvements with its failure instances falling to eight while T5 had five occurrences.

The figures allude to inadequate risk analysis implementation creating room for failure occurrence. After the discovery of failure reasons and the subsequent application of the categorisation technique, a more informed decision will help to reduce the chances of failure occurring in IS projects.

Case Studies: Before

Case Studies: After

Conclusions

Case studies are useful in transmitting knowledge about previous incidence of failures, but with a need for additional refinements and richer alternatives. From the analysis, it shows that larger IS projects stand the greater risk of failure especially with the large number of stakeholders involved. It is clear that failures result in a cost burden on the society, job losses, bad publicity from the media, loss of stakeholder confidence etc. Shorter project durations with incremental delivery of software components tend to give IS projects a better chance of success.

The case of T5 is slightly different to the other three additional case studies examined because of its completion on budget and according to schedule whereas the other projects were over budget and delivered late. Despite the problems of the operational opening day and some subsequent days, things look to be running as well as planned now with the baggage handling system. DABHS and Taurus projects suffered cancellation but the NATS system is still in use after several modifications despite its challenges.

IS development is a high-risk venture with the risks involved often causing drastic repercussions. Despite the fact that learning from experience can be a long and difficult undertaking because of the challenges involved, it looks to be the best way to overcome the vicious cycle of IS failures. Organisations must recognise the need to acquire more knowledge about their activities, and device mechanisms for documenting and transferring the knowledge gained. IS developments must be seen as a value adding process that serves the needs of various stakeholders.

The problems encountered by T5, DABHS, NATS, Taurus, and many other IS projects could have been avoided if the respective organisations paid more attention to their own experience, and the experience gained from other previous projects similar to the one they embarked on, and acted based on this knowledge. Learning from failure implies the discovery of new ways toward the understanding and analysis of recurrent problems in the development of IS and it offers hope for future improvements.

Conclusions (Cont.)

This dissertation provided a perspective on understanding information system failures, and proposed the use of a categorisation technique of IS failure reasons to help in the identification of failures and the reasons behind them.

The IS failure reasons have been organised with the categorisation technique to reduce the time and effort needed to overcome the failure reasons, and facilitate the process of detecting more failures, and the reasons behind them.

The application of the categorisation technique on the main case study presented in this report as well as the three additional failure cases described in different contexts and environments produces some interesting results. The case studies show that the proposed categorisation technique may help in detecting further failure occurrences that are hidden or unexpected.

There is a need for more case studies to estimate the efficiency and effectiveness of the technique. This project used a qualitative approach to characterise IS failures and a prioritisation technique may be applied further to complement the categorisation technique.