Session 5 Information Systems Failure and Success

Programme for this session Risks around Information Systems

A critical review of Information Systems failure How do we define it? Why does it happen? How do we avoid it? INFORMATION SYSTEM FAILURE What is failure? How frequent? Causes? Solutions? Most Information Systems Fail... Only large failures are publicised Toll Collect, Germany, 2005/6. Going down. Taurus, Stock Exchange London Ambulance (failed 1993, enhanced 1997+) European Space Agency Ariane Rocket System Chinook helicopter software, allegedly. UK air traffic control (ATC) system is 10 years late, 700m increased budget. Recent New York ATC system was similarly problematic. Many systems limp along with failings concealed The Standard Definition of Success Pressman, (1993, 2004, 2010) - Success is compliance of the end product with the written system specification This definition is still accepted by many

What are the limitations of this definition? 3 Definitions of IS Failure Correspondence Failure

 not meeting pre-defined objectives Process Failure not meeting budget and cost objectives Interaction Failure Low user satisfaction Expectation Failure inability of an IS to meet a specific IS stakeholder groups expectations Lyytinen, various publications Critique of Expectation Failure Some expectations are more reasonable than others Expectation failure ignores intention - does a stakeholder have private goals? Some stakeholders have greater capacity than others. How much say does the ultimate system beneficiary have? (e.g. the external customer) Problem Areas Causes of Information System Success & Failure User-designer communication gap Degree of management support Level of complexity & risk Implementation issues Managing change User-designer Communications Gap

Differences in backgrounds, interests, and priorities impede communication and problem solving among end users and information systems specialists User Concerns: Will system deliver information I need? How quickly can I access data? How easily can I receive data? How much clerical support will I need for data entry? How will system operation fit into my daily business schedule? Designer Concerns:

How much disk space will system consume? How many lines of program code will this function take? How can we reduce processor consumption? What is the most efficient way of storing this data? What database management system Degree Of Management Support Backing & commitment of manager More funding & resources Gives project status with users & technical staff High level attention & priority Better chance of recognition & reward Backing for organisational realignments Can cause problems if project is failing Level of Complexity & Risk PROJECT SIZE larger project=greater risk PROJECT STRUCTURE highly structured=lower risk EXPERTISE WITH TECHNOLOGY low expertise=higher risk Implementation Issues should we use?

All activities leading to the adoption and management of innovation. For IT Systems this involves Planning & controlling all aspects of introducing the system. Anticipating potential problems. Applying appropriate strategies for project management, & managing organisational change. The Implementation Process

The activities needed to transform a newly developed IS into an operational system for endusers: Acquisition of hardware & software services Software development or modification End User Training

System documentation Conversion: Parallel, Pilot, Phased, Plunge Standish Group Report: Theres Less Development Chaos Today

Software development shops are doing a better job creating software than they were 12 years ago, according to figures contained in the as-yet unreleased 2006 Chaos Report from The Standish Group. The new report, details of which were previewed with SD Times, reveals that 35 percent of software projects started in 2006 can be categorized as successful, meaning they were completed on time, on budget and met user requirements. (2009 figure 32%). Rubinstein, D., March 1 2007, Standish Group Report, http://www.sdtimes.com/article/story20070301-01.html, accessed Sep 2010 www.sdtimes.com/link/30262 accessed Sep 2010 www.mahai.com/dimensions/docs/issue24/The_Samborn_\report-Spring%20_2010.pdf, accessed Sept 2010 Standish report, contd.

This is a marked improvement from the first, groundbreaking report in 1994 that labelled only 16.2 percent of projects as successful; that report galvanized an industry of development tools vendors selling everything from requirements management solutions to modelling tools and turned software architecture into a cottage industry. Further, the 2006 study shows that only 1 9 percent of projects begun were outright failures, compared with 31.1 percent in 1994. The 2006 report is the sixth published by The Standish Group, and chairman Jim Johnson said that with the exception of a lapse in 2004, weve seen consistently better software p rojects. Projects described as challenged, meaning they had cost or time overruns or didnt fully meet the users needs, declined to 46 percent in 2006 from 52.7 percent in 1994. Why IS Projects Fail Incomplete Requirements 13% Lack of user involvement 12% Inadequate resources 11% Unrealistic user expectations 10% Lack of Management support 9% Requirements keep changing 9% Inadequate Planning 8% System no longer needed 8% The Computer Bulletin, July 1998, p26.

Top 10 reasons for success Standish Group, 2006, Chaos report

User involvement Executive management support Clear business objectives Optimising scope Agile Development Process Project manager Expertise Financial management Skilled resources Formal methodology Standard tools and infrastru cture Standish report, contd. - Successes

Johnson cited three reasons for the improvement in software qualitybetter project management, iterative development a nd the emerging Web infrastructure. There is better project managemen t expertise and technique, he noted. Managers have a better understanding of the dynamics of a project. Iterative development, Johnson said, makes it easier for people to get what they want. Part of the education process [for iterative development] is that people are better able to articulate what they want out of a project. Finally, Johnson added that the emergence of the Web plays a fairly significant role. The idea that you can get things out quickly and people can learn it, touch it and give feedback creates a more dynamic experience. The 2006 report also shows what Johnson called a stunning improvement in the metric used to measure project value. If the assets of a failed project can all be considered waste, in 2006, software value was measured at 59 cents on the dollar. In 1998, that figure was 25 cents on the dollar. You can look at that as a 24 percent compound average growth rate since 1998, Johnson said. BSkyB sues dishonest' IT group for 709m

Performance by EDS was 'woeful' - Hearing set to exceed six months By Nikki Tait, Law Courts Correspondent The broadcaster BSkyB yesterday accused EDS, the US IT outsourcing company, of making a "deliberate, cynical and dishonest" sales pitch for a multi-millionpound contract to build a customer service system.

In one of the largest commercial cases seen in London's technology and construction court, BSkyB is suing for 709m in damages, claiming EDS failed to comply with contractual obligations undertaken in 2000, and that its subsequent performance was "woeful". The scale of the claim - which alleges deceit, negligent misrepresentation and breach of contract by EDS - contrasts sharply with the value of the original contract, which was 48m. The contract also included a 30m liability cap, but this is overridden because of the allegations of deceit. BSkyB refused yesterday to comment publicly on the breakdown of the claim, but the damages figure is said to be based on profits allegedly lost. EDS said it would be refuting BSkyB's allegations over the course of the trial, which is scheduled to last more than six months. "EDS will vigorously defend its position," the company commented. Contd.

Opening the case forBSkyB, Mark Howard QC said EDS had failed to use any recognised form of time and cost estimation system when tendering for the work, and simply produced a reflection of what it thought BSkyB wanted. The Texas-based company, he alleged, "put forward a sales pitch knowing that it was being done in a misleading way". By July 2000 BSkyB had selected EDS as systems integrator for the project, beating out a competing bid from PwC. But, said Mr Howard: "If the misrepresentations had not been made, Sky would not have selected them [EDS]". The barrister went on to describe performance of the contract over the next nine months as "woeful". In the summer of 2001 there was an effort to renegotiate the deal. However, this failed to resolve matters and BSkyB claims the contract was then terminated in March of the following year. EDS, on the other hand, has said that while it stepped down as systems integrator at that stage, it continued to provide contractors to BSkyB until it terminated the contract in January 2003. Yesterday, as he set out BSkyB's case, Mr Howard quoted from documents written by some of the other companies working on the project with EDS. One, written in March 2001, assessed the project as being "in free-fall", and commented that the EDS team's ability to deliver was "exceedingly low". The case continues. Now you should be able to View IS success and failure in context Assess and address the causes of system failure Explain practical implementation examples.