Stop IT Project Failures

Dan Remenyi

• Publisher: Routledge
• Year: 2010
• ISBN:
  9781136363498
• Edition: 1
• Topic: Betriebswirtschaft
• Subtopic: Business allgemein

This book is about information systems development failures and how to avoid them. It considers what goes wrong with information systems development projects and what actions may be taken to avoid potential difficulties.The reduction of the impact, or even the elimination of the problems, is discussed in terms of an information systems risk management programme. Stop I.T.Project failure helps to ensure that IS project managers are successful in helping to deliver application systems. However, IS development risk can never be entirely eliminated and consequently the practitioner needs to bear in mind that an IS development project is never without risk, and hence there is a continuing potential for something to go wrong. The book covers the key issues and variables and makes specific practical suggestions about the good management practice that is required to implement IS project risk processes. Dr. Dan Remenyi has spent more than 25 years working in the field of corporate computers and information systems. He has worked with computers as an IS professional, business consultant and user. In all these capacities he has been primarily concerned with benefit realisation and obtaining the maximum value for money from the organisations' information systems investment and effort. He has worked extensively in the field of information systems project management, specialising in the area of project risk identification and management. He has written a number of books and papers in the field of IT management and regularly conducts courses and seminars as well as working as a consultant in this area. Dr.Dan Remenyi holds a B.Soc.Sc., an MBA and a PhD. He is a Visiting Professor at Chalmers University of Technology in Gothenberg, Sweden and an associate member of faculty at Henley Management College in the United Kingdom.

1	Information Systems Project Risk Management

Risk management guides us over a vast range of decision-making, from allocating wealth to safeguarding public health, from waging war to planning a family, from paying insurance premiums to wearing a seatbelt, from planting corn to marketing cornflakes.

(Bernstein, 1996)

Building an information system, … an online, distributed, integrated customer service system, … is generally not an exercise in ‘rationality’. It is a statement of war or at the very least a threat to all interests that are in any way involved with customer service.

(Laudon, 1989)

In preparing for battle I have always found that plans are useless, but that planning is indispensable.

(Dwight D. Eisenhower)

1.1 Introduction to Information Systems Risks

Risk and the management thereof, in the context of information systems (IS) development, is an issue that has not received much attention. In general it has been assumed that the assumptions and estimates used in IS development plans would actually be realised and that there was no real need for much in the way of contingency provision or other courses of action to ensure success, or to prevent failure.

There have been many impressive information technology successes (Cash et al. 1992; Earl 1992). Some organisations have flourished because of the competitive advantages derived from the information systems that they have developed. Others have used information systems to improve the efficiency and the effectiveness of their organisation’s operation. But at the same time there has also been a plethora of failures.

1.2 Information Systems Development Failures

There have always been IS development failures, and some of these have been spectacular (Allingham et al., 1992). In the United Kingdom alone, the London Ambulance System, the Wessex Health Service, Taurus Financial Services are all well documented as suffering substantial failures costing huge amounts of money. However, there are many more instances that have not been brought to the public’s attention and have consequently not been ‘celebrated’. Of course it is not usual to celebrate failure, and in the process of sweeping the embarrassment of failure under the carpet, significant opportunity for learning is lost. It is difficult to obtain accurate statistics, but various sources suggest that a significant percentage of IS projects fail, of which the following are interesting examples.

During April 1994, insurance giant Prudential abandoned all further development of their five-year ‘Plato’ in-house project costing £40 million intended to downsize from mainframe to client-server architecture. A well-researched BBC documentary ‘The Net’ (broadcast on 18 May 1994) estimated that poorly managed and abandoned IT projects in British government departments alone had cost the taxpayer the equivalent of £5 billion over the previous twelve years. That is roughly £90 for every man, woman and child in the United Kingdom. The much vaunted ‘Operational Strategy’ project of the British Social Security department cost £2 billion and has delivered very little to date. One report states that: “the project performed badly on all principal expectations held by its early decision-makers” (Collins, 1994). Elsewhere in the United Kingdom, the Department of the Environment for Northern Ireland sued its supplier over a failed £8 million system. Ironically the dispute was settled by paying the supplier a further £1 million due to an extraordinary legal anomaly (Collins, 1994).

IS Project Risk

The bankruptcy trustee appointed to oversee the liquidation of FoxMeyer Corp. and FoxMeyer Drug Co. has sued the companies’ software supplier, for $500 million for alleged gross negligence. In papers filed in the US District Court in Delaware, Bart Brown said the software vendors’ alleged fraud and negligence, “led to the demise of FoxMeyer, a once-thriving $5 billion wholesale drug distribution company”. According to the lawsuit, although the vendor had historically made software for manufacturing, the Walldorf, Germany-based company, “assured FoxMeyer that its R/3 system was well suited to the needs” of the high volume and complex price structure of FoxMeyer’s distribution business. The system did not work and its failure, it is alleged, led to FoxMeyer going bankrupt. When the system was installed, its volume limitations made it useable at only six of FoxMeyer’s 23 distribution warehouses, court papers said. “The failure of the system to perform as the vendor had represented … was a significant factor contributing to FoxMeyer’s August 1996 bankruptcy and subsequent liquidation.”

In the United States, the General Accounting Office found that the development of three ‘severely flawed’ government systems continued for periods ranging from three to eight years at a cost of more than £19 million to US taxpayers before they were scrapped (Betts, 1992).

Although it is acknowledged that IS failure has become a common problem, there is no agreement on the actual percentage of projects that fail. This is complicated by difficulties with the definition of IS failure. Keil (1994) contends that the definition of computer failure depends on whom you ask. He reports that DeMarco (1982) says there is a 15% failure rate; Gladden (1982) found 75%, Lyytinen and Hirchheim (1987) say 50%; Crescenzi (1988) says 85% and Wilbern (1992) says 60%.

1.3 Definitions of information systems development failure

It is hard to establish a consensus of exactly what constitutes IS failure. There is little if any consistency in the literature as to the exact extent, or for that matter, the actual nature of IS failure. However, broadly stated, IS failures occur when IS projects do not achieve the expectations or objectives of the original user or system owners. But this explanation is too simple as the real problem lies in deciding when, and to what extent, those expectations or objectives have been met. However these issues are defined, failure is generally agreed to have occurred when a project has:

• commenced development, but was abandoned before completion;
• been fully developed, but never used;
• been fully developed and commissioned, but abandoned within a very short period of time;
• not been fully developed as originally envisaged, but substantially down-scaled until it no longer provides the originally envisaged functionality.

Of course there are lesser forms of failure i.e. degrees of failure, which occur when an unsuccessful IS project can still be rescued by additional, but unplanned application of resources. Then again the success of projects is sometimes measured by whether they are on-time, to budget and according to specification. Using these criteria Beam (1994) suggests that only 2% of IT projects ever succeed. Of course, there are many successful projects which have been both late and significantly over budget. Thus these two criteria alone are not sufficient to indicate success or failure.

Failure is a major problem in IS projects as it is especially costly, not only because of the resources invested, or rather spent on the failed system, but also because such failure frequently causes disruption to the organisation’s mode of business.

Furthermore failure can sometimes have serious adverse effects on the morale of the information systems staff and other individuals in the organisation.¹

1.4 Definition of risk

Risk is a challenging concept to define, understand and ultimately to manage. This is primarily because the idea of risk can mean different things to different people. In terms of a formal definition, risk is described as the probability that the actual input variables and the outcome results may vary from those originally estimated (Remenyi et al.1993, Correia et al.1989). This implies that the extent of the possible/probable difference between the actual and expected values reflects the magnitude of the risk.

Another way of looking at the definition of risk is provided by Chapman and Ward (1997) who state that:

A broad definition of project risk is ‘the implication of the existence of significant uncertainty about the level of project performance achievable’.

There is always uncertainty about any estimates of IS project development performance, as these estimates attempt to predict how complex work activity will be performed in the future. As the future is always unknown, estimates are always therefore vulnerable to error.

Of course risk is ubiquitous in every aspect of life. Economic theory suggests that risk is at the heart of the economic process and this body of theory suggests there is no profit without some level of risk and that in fact the more risky the investment the higher the profit potential from that investment should be. However Boyadjian and Warren (1987) point out that:

Risky investments may indeed carry a ‘premium’ reward but the existence of a precise relationship between the two cannot be demonstrated or verified as there is no objective and generally accepted method of evaluating risk.

However, Frank (1987) clarified the relationship between risk and profits quite succinctly when he pointed out that:

Profits are due not to risk, but to superior skill in taking risks. They are not subtracted from the gains of labour but are earned, in the same sense in which the wages of skilled labour are earned.

Although the word risk is usually used in the context of a potential hazard or the possibility of an unfortunate outcome resulting from a given action (Correia et al. 1989), intrinsically risk can be either positive or negative. For example, projects may finish either early or late, or be under or over the financial amounts budgeted. Unfortunately information systems developers sometime neglect the positive side of risk.²

1.5 Uncertainty and Risk

Sometimes the term uncertainty is also used in connection with projects and investments and thus it is important to note that the terms ‘risk’ and ‘uncertainty’, although sometimes used interchangeably, are in fact quite different notions. However, it is true to say that risk is the result of a situation having an uncertain outcome as is inherent in most investment projects. The risk of a project is frequently known and can be measured and managed. Uncertainty on the other hand refers to situations where there is little or even no knowledge of what the outcomes might be.

Correia et al. (1989) state that there is a formal difference between uncertainty and risk. In their definition of these concepts they point out that:

uncertainty implies that either all the alternative possible outcomes cannot be identified, or that no probability can be attached to the alternative possible outcomes.

Risk on the other hand implies that it is possible to attach probabilities to identified expected outcomes.

For the purpose of this book the authors have focused on the issues related to risk as defined above rather than to uncertainty. In the context of IS development, risk is defined as the chance that the system will not deliver the planned and expected benefits due to problems encountered during its production. Thus the concept of risk is directly related to the notion of the chance or probability of particular type of problem arising. The most important feature about the notion of chance is that it relates to future events and thus the issue of risk is entirely to do with what will happen in the future.

1.6 IS project risk management

To be successful, IS project risk management needs to be tackled as a sub-set of IS project management.

IS risk management is a technique that can reduce the possibility, or more correctly the probability, of information system failure...