Information systems in organisations

Abstract

Successful system roll-out is not a task that can easily be achieved. As many organisations and governments have found to their cost, it is not simply the case that they can throw money at an information system in the hope that it will be successful. The primary case study used is that of the London Ambulance Service Computer Aided Despatch system. After looking at the background of the case the implementation and subsequent failure are discussed. The reasons for failure are explained, which show the project as essentially being doomed from the start. Although system failure is a common occurrence many organisations do not seem to learn from the mistakes of the past, resulting in several other high profile cases. There are some strategies, however, that can be adopted in order to combat against failure, which mainly side on the softer aspects of system design such as management, organisational culture and human relations.

What are the major causes of systems roll-out success or failure? What strategies can organisations take to ensure the success?

To answer this question fully we must first understand what an information system (IS) is; and more importantly, what constitutes the success and, or failure of an IS. “An information system in an organization provides processes and information useful to its members and clients” (Avison & Fitzgerald, 2003). Flynn (1992) also describes it as “An information system provides procedures to record and make available information, concerning part of an organization, to assist organizations-related activities.”

An IS is made up of a complex set of factors, including human, organisational, technical, political and financial factors (Flowers, 1996). The interaction between these can give rise to either the success or failure of a system roll-out. The success of an IS is measured mainly on whether or not it meets the productivity target of being developed on time and to budget, and the quality target of meeting the client’s requirements. “A successful system is one that meets its targets of quality and productivity” (Flynn, 1992). An IS is deemed unsuccessful if it fails either one, or both of its targets. In some instances the system is never actually delivered to the end user, which obviously is another case of system failure. “An unsuccessful system is one that fails to meet either its quality or its productivity targets” (Flynn, 1992).

Successful system roll-out is not the easiest of tasks, with many governments and companies finding this out to their cost. In some cases these cost have run into hundreds of millions of pounds. The latest Standish Group report “CHAOS Summary 2009” shows that more projects than ever are failing, and also that the number of successful projects is on the decrease. Only 32% of projects met their targets and could be classed as successful; with 44% of systems meeting either only some or none of their targets and 24% were never completed (The Standish Group, 2009). There are estimates that the cost of project failure in the U.S. alone is well in excess of $100 billion; emphasising just how costly a problem system roll-out can be if not done correctly.

One reason as to why there are so many instances of IS failure is partly due to the fact that a lot of the time they are constructed “without a full understanding or anticipation of reality” (Xalles Limited, 2005). This is known as the ‘Vacuum Mentality’ syndrome (Xalles Limited, 2005). These realities include changes in technology, changes made by the user community, reorganisations, changes of needs, change of key players and project sponsors, issues with resources and changes of processes (Xalles Limited, 2005). This idea is backed up by Maddison & Darnton (1996) who explain that “human issues are usually more important than technical ones in determining success or failure.” Highlighting the fact that it is not necessarily technical issues with an IS that are the main problems during the development process, but instead ones regarding human incompetence.

One of the most dramatic IS failures reported in recent years is that of the London Ambulance Service Computer Aided Despatch (LASCAD) system. The LAS is the biggest ambulance service in the world, dealing with over 2,500 emergency calls a day. This inevitably put massive strains on the manual paper-based system that was being used, which already had several major problems with it. This led to the standards of performance falling below the ones agreed to as part of the national standards for ambulance response.

It was, therefore, imperative that a new, more effective computer aided despatch system was introduced in order to meet the performance levels. The new system worked by a Control Assistant receiving an emergency call and entering the details given by the caller into the CAD system. Using call-box identifier and mapping systems, the exact location of the caller was calculated. Based on the information on the incident the CAD then worked out a level for the emergency, thus informing the Control Assistant on the appropriate specialist vehicles and skills that should be deployed to the emergency. The most appropriate and closest vehicle to the incident was then pinpointed via the use of mobile data terminals and the vehicle tracking system, and despatched to the emergency. The CAD system sent details of the incident to the vehicle via the on-board computer. Throughout dealing with the incident the crew were constantly updating the CAD system as to their arrival at the scene, their departure from it, their arrival at the hospital, and finally when they were free to deal with another call (Flowers, 1996).

The intention of the CAD system was to eradicate the inefficiencies of the old paper-based system. However, as the LAS soon found out this was far from the case. On Monday 26th October 1992 the entire LASCAD system went live. It became quickly apparent, however, that it could note cope with the volume of calls. A number of calls were somehow getting ‘lost’ in the system, leading to duplicate calls being made (Flowers, 1996). This meant that people who were in emergency situations had to wait, in some cases, for 30 minutes for their call to be dealt with. Even when the calls were dealt with, the ambulance allocation system had also failed meaning this had to be done manually, resulting in further delays. Amidst the confusion, it was even reported in some cases that two ambulances turned up to a single emergency, or that one never turned up at all (Flowers, 1996).

As the day progressed, the number of calls increased, putting even more pressure on the already faltering system. The newer calls were now overwriting the earlier calls, resulting in even more incidents not being dealt with. The situation became that bad that all the queues were cleared in an attempt to decongest the system. However, this only succeeded in making the problem even worse, as a new flood of calls that were previously ‘lost’ came through (Flowers, 1996).

It was only Tuesday afternoon when the system was eventually shut down as a result of the escalating situation (Finkelstein, 1993). The LAS were instead forced to revert to a former part computerised system. Just over a week later they were back using the fully manual system.

It is impossible to consider all of the factors that contributed to the demise of the CAD system. However, there are several major issues which could, ultimately, be seen as the contributing factors towards its failure. Flowers (1996) states that the primary reasons behind the failure were those of the design of the system, the management ethos, the procurement process and the timetable to which the system was developed. The system had been designed without sufficient testing, and on the basis that it would be operating in a ‘perfect world’ where everything goes according to plan. It relied solely on the requirement that all the information received was perfect. In reality this was far from the case, and so the system was unable to sufficiently despatch resources to the incidents. As highlighted in the official inquiry into the failure:

“It is probable that the development team did not have full appreciation of the importance of these elements or, at least, of the consequences of failure, or less than perfect performance, of any one part” (Finkelstein, 1993).

The management ethos at the LAS was one that was “inward looking and old-fashioned” (Flowers, 1996). As a result of the recent restructuring which had been forced upon the LAS by the National Health Service, there were reported high levels of stress amongst senior management, which had seen a great number of previously loyal staff quitting (Mellor, 1994). In the years leading up to this there was a distinct lack of investment in areas such as the training and development of managers. During the implementation process a report was commissioned by the LAS into staff attitudes. It was clear to see from the results that staff had little faith in the management and were not satisfied with their jobs. This view had already been exposed from the result from a survey conducted in 1989 (Flowers, 1996).

The official inquiry also highlighted a culture within the organisation that bred a fear of failure amongst the employees; whereby the success of the system was the one and only consideration (Flowers, 1996). This created an atmosphere in which people were scared to mention any problems or doubts they had with the system. As a result the system had become a ‘sacred cow’, in the fact that it became unreasonably immune to criticism from anyone associated with it.

Senior managers believed that the system could be developed at a cost of just £1.5 million. To meet the stringent financial restrictions regarding the purchase of the system, it was recommended by the selection team that the LAS accept the lowest offer, no matter who the tender was; unless they believed they had “good and sufficient reason on the contrary” (Flowers, 1996). The consequence of being forced to accept a tender in this manner was that the one with the lowest offer was an inexperienced small software company that had gravely underestimated that task at hand; hence the reason for their offer being considerably lower than all others. Having never worked on a project of this kind the company’s resources were massively stretched, leading to falling standards in areas such as quality assurance, resulting in several mistakes being made with the development of the software.

The inflexible time scale of just 6 months to which the system was set was far less than the industry average of 18 months for a project of this scale. It was believed by a vast majority within the LAS that the time scale was highly unrealistic. Inquiry Team member Paul Williams stated that “The timetable was impossible” (Mellor, 1994).

Staff complained of the inadequacy of the training received for the system. There were major doubts about the quality of the training received and that it was provided long before the system was actually implemented; meaning it was not as effective as it could have been. The situation was made even worse by the fact that the control room staff were trained separately to the ambulance staff, which caused the potential for miscommunication.

Other reasons include the fact that it had been decided by management that there was to be a trade off between the performance of the system and usability. The system was developed with little input from system users such as ambulance crews, with no LAS staff being assigned full time to the project (Mellor, 1994).

These, therefore, were not ideal conditions in which to launch the new CAD system. Flowers (1996), on the other hand, argues that “there is never an ideal time to introduce a major new computer system.” However, he does also go on to say that rarely has such a large scale information system ever been introduced under such difficult circumstances (Flowers, 1996). This was not the first time that the LAS had tried to implement a CAD system for ambulances. Beginning in the early 1980’s the system was doomed after tests revealed it would not be able to deal with the sheer volume of calls and so was abandoned in 1990 at a cost of £7.5 million.

For a system roll-out to be successful it must contain these “four phases: Implementation Planning, Implementation Delivery, Post-Implementation Support, Post-Implementation Analysis” (Xalles Limited, 2005). These implementation methods are based on a number of principles and assumptions. The approach by management to the project should be disciplined. As the case of the LASCAD has shown; strong and effective management is essential for the success of a system. Managers should be able to competently handle and issues or problems that develop during the implementation of the system. Accurate and concentrated documentation is needed in order to effectively communicate throughout each of the implementation phases. The end user(s) should be kept in mind throughout the development process so that the System Requirement Specification can be met. It is essential that organisations learn from the mistakes of others regarding the roll-out of an information system. However, this can pose quite difficult as many organisations, if they have difficulties, tend to keep these problems ‘in-house’, as not to bring any negative press to themselves.

In conclusion it is clear to see that the roll-out of a successful IS is not an easy achievement, with organisations not always learning from the mistakes of others. After reading several case studies of high profile IS failures including LASCAD, TAURUS and Heathrow Terminal 5, it shows that the price of failure are extremely high with these companies losing tens of millions of pounds between them, and in the case of the LASCAD people losing their lives. These cases also highlighted that the main contributing factors towards the demise of each project were in fact from poor management, rather than technical difficulties. It is argued that the main factors for success comprise of timing and budget, perceived usefulness and ease of use, fitting the organisation’s business strategy and objectives, the management culture and human relations, and lastly acceptance of the system by the user(s) (Maddison & Darnton, 1996). In order for a system roll-out to be successful all of this must be taken into consideration.

Bibliography

• Avison, D. & Fitzgerald, G. (2003). Information Systems Develolpment: Methodologies, Techniques and Tools Third Edition. Mcgraw Publishsing
• Flynn, D. J. (1992). Information Systems Requirements: Determination and Analysis. McGraw-Hill International
• Flowers, S. (1996). Software Failure: Management Failure: Amazing Stories and Cautionary Tales. John Wiley & Sons Ltd.
• Finkelstein, A (1993). “Report of the Inquiry Into The London Ambulance Service”. International Workshop on Software Specification and Design Case Study. The Communications Directorate.
• Finkelstein, A & Dowell, J. A Comedy of Errors: the London Ambulance Service case study. School of Informatics, City University.
• Lin, A (2009). Information Systems in Organisations. Department of Information Studies, The University of Sheffield.
• Maddison, R. & Darnton, G. (1996). Information systems in organizations: improving business processes. Chapman & Hall.
• Mellor, P. (1994). CAD: Computer-Aided Disaster (High Integrity Systems). Vol. 1, 2, pp. 101-156.
• The Standish Group (2009). “New Standish Group report shows more project failing and less successful projects” [Online]. http://www.standishgroup.com/newsroom/chaos_2009.php [Accessed 1 January 2010].
• University College London (2009). “Unit 3: Case Study London Ambulance
• Service CAD System” [Online]. http://www.cs.ucl.ac.uk/staff/A.Finkelstein/advmsc/3.pdf [Accessed 5 January 2010].
• Xalles Limited (2005). “Successful Systems Implementation” [Online]. http://www.xalles.com/reports/Successful%20Systems%20Implementation.pdf [Accessed 30 December 2009].