Terminal failures

Computer system disasters have cost billions. And dinosaur bosses must take the blame

DURING 1985, a pounds 16.5m project to computerise the Inland Revenue was abandoned. In 1993, the London Stock Exchange abandoned its Taurus automation scheme after spending pounds 50m. The 17-year project to automate the Department of Social Security is likely to overrun its original budget by four times - an overspend equivalent to a penny on basic rate income tax. And only last Monday, it was reported that the pounds 100m system designed to open the domestic electricity market to competition was unlikely to start on time in April 1998.

These are computer disasters that have made the headlines. But they are just the rubbish we can see atop a great landfill site of overrunning, overspending and out-and-out failure in the trea- cherous world of information technology.

Coopers & Lybrand recently reported that 85 per cent of large UK organisations have installed systems that are late, over budget, or have not done what they were supposed to. C&L will unveil another study in the New Year which will reveal that almost 20 per cent of organisations worldwide have had to abandon IT projects and that more than 10 per cent say they have suffered "significant damage" as a result.

Computerisation has been the great organisational development of the past 20 years. Every organisation of any size has a network of computers running specialist software.

But it is this software - which turns a computer from a dumb box into an intelligent tool - that has landed so many people in so much trouble. Complex organisations need, or think they need, specially designed or customised software; they commission a project to develop it, and that is when the fun starts.

"Major IT projects offer the potential for huge returns, yet very few seem to come to successful conclusions," says Catherine Griffiths, research fellow at Imperial College's IC-Parc in London.

It is impossible to gauge accurately the scale of losses on IT schemes. But according to Leslie Willcocks of the Oxford Institute of Information Management, there is hardly a big organisation in the world that does not have - or has not had - a "dinosaur project". "Many companies have put in complete systems and ripped them out unused," Ms Griffiths says.

Some of the most grotesque waste has been in the defence sector. GEC's contract to produce an early-warning aircraft, scrapped when it was several years late, was in essence a software project; the US Department of Defense has had its share of hi-tech catastrophes.

Smaller projects are less likely to go wrong, but when they do the effect can be cataclysmic. The Performing Rights Society attempted to automate its procedures for collecting royalty payments; the scheme overran by pounds 18m.

With each system costing millions, the cash that has slipped down this technological drainpipe must run into billions. Yet it is largely an unreported story. Whereas big public sector overruns will be picked up by the National Audit Office and publicly displayed, most disasters are swept under the carpet.

Among measures of senior management competence, the ability to handle new technology receives scant attention. Yet in almost every case, it is not the failure of the technology or the technologists that leads to disaster. It is the bosses' inability or unwillingness to understand what must be done to make sure the system works. Worse, there are few signs that they are prepared to grasp the nettle: the recent spate of "outsourcing" (handing over IT operations to another company) sidesteps the problem in the short run - but could be storing up trouble.

Why do computerisation schemes so often fail? In a report, Ms Griffiths and Mr Willcocks have identified typical problems: a failure to define the project's aim; supplier problems; a failure to change the organisation - and the thinking within it - in line with the technology; and too much faith in a "technical fix" for its own sake. Of these, all but supplier problems are managerial failures.

Two of the cases in the study show what can go wrong; one shows how it should be done.

Taurus (the Transfer and Automated Registration of Uncertified Stock) was conceived in 1987 by the London Stock Exchange to replace share certificates with electronic data. Not everyone was keen - registrars, for example would lose their role - so the Exchange set up a series of committees to produce a system that kept everyone happy. The result was that the specification grew like Topsy.

It was never properly established exactly what Taurus was supposed to do, and there was no central co-ordinating group to bash heads together. Committees came and went, and arguments raged over fundamental design. Nevertheless the go-ahead was given to buy a pounds 1m off-the-shelf software program from the US. Another pounds 14m was spent rewriting it - a process that was never finished. Some basic functions, including overnight reconciliation, were omitted or labelled as not urgent. In 1993, after pounds 50m had been spent, Taurus was abandoned.

The DSS's operational strategy is designed to install 40,000 terminals in 1,000 offices. It is probably the largest computerisation programme ever undertaken in Europe, and it is still going - it was started in 1982, and is scheduled to be completed in 1999. When it was started, the cost was put at pounds 700m; by 1993 the estimated cost was pounds 2.6bn.

Mr Willcocks and Ms Griffiths identify a raft of mistakes. One was that DSS managers failed to prepare for staff resistance. After a seven-month strike, half the internal programmers were moved to other areas. They were replaced by consultants, who cost nearly five times as much per head.

There was apartheid between policy makers and computer experts, too. When the Government decided to over-

haul the social security system, the first the IT people knew about it was when a Green Paper was published. Unsurprisingly, long delays followed.

The Singaporeans have shown complex computerisation projects can work. By 1985, Singapore's role as a trading centre was being threatened by fierce competition, and a high-level committee was set up to find a way of improving the efficiency of using the port. It recommended a computerisation strategy that would speed up documentation processes, to make the port more attractive. The TradeNet system started operating on time in 1989, and reduced document-processing time from four days to fifteen minutes. Singapore's future as a port was secured.

TradeNet worked because the project was well-managed, although the backing of an authoritarian government undoubtedly helped. A central body made sure everyone understood what was needed, and agreed with it. "They said if Singapore didn't succeed as a trading nation, the whole country would suffer," Ms Griffiths says. "It was vital that so many top people, including the Prime Minister's son, were closely involved from start to finish."

During the decision-making, the managing committee realised there was no point in just automating an over-complex system - so a lot of time was spent simplifying it first. It also acknowledged that there would be demands for changes once the project was under way, but said they could be made only if a detailed analysis had been made first. Whereas in Taurus or the DSS the programmers had to work frantically to make every change demanded, Singapore switched the priority: they would be made only if there was a solid case for doing so.

The lessons of these three projects ring bells with anyone who has been involved in a large IT project. For one thing, says Geoff Smart, partner with Coopers & Lybrand in charge of systems quality assurance, "it is surprising the number of projects that don't have clearly stated objectives".

Constant changes are a perpetual bugbear. "It's very easy for a project to grow and grow to the point where it can't possibly be implemented," one systems engineer says. "The specifications change faster than the programmers can implement them, so they might find they have put in five days' efforts and slipped six."

Computer projects do have certain features that make them riskier than, say, a bridge. Technology is changing so fast that it may be impossible to resist demands to upgrade it when the project is under way. Conversely, the business may decide to hurl itself into an upheaval that makes the entire project redundant. The fashion for "re-engineering" has left many IT projects stranded on the beach. "Anyone putting out a four-year IT project is taking a risk," says John Coveney, director of systems solutions in Price Waterhouse's management consultancy.

Software projects are also invisible. "You are reliant on progress reports that tell you you are on course," Mr Smart says. "Then you get to the testing and get slippage reported. The fact is that defects have been introduced all the way through, but no one has been testing for them."

The answer to all these problems lies in management. "Large projects can be like Himalayan expeditions," Mr Smart says. "They can be very risky, but they can also be safe if you take them in steps, and if you have good leadership and control risks." Ideally a project should be chopped up into manageable chunks, he says, and there should always be a monitoring system. It sounds an obvious precaution but, it seems, it is one managers often do not take.

Managers also frequently fail to realise computerisation projects are going to change the way a company operates, generating resentment and possibly redundancies. "If people see it's going to demolish their department, you can't expect them to co-operate unless you give them incentives," Mr Smart says. "You have to either retrain them, or give them cash incentives to stay on until the new technology is in."

This all comes back to the role of top management, and its failure to grasp the significance of an IT project. IT directors rarely make it to the main board, which can mean the computer department has too little power - or too much. If it is dangerous to ignore the computer department's pleas, it is lunacy to give it full rein for its most grandiose plans. The answer, as Singapore has proved, is for the strategic and IT sides to be indivisible.

This is why the trend to outsourcing is worrying, Mr Willcocks says. Several government departments, as well as the likes of Rolls-Royce and Lucas, have handed over their IT operations to specialist management groups. "A lot of these deals have little to do with business value and everything to do with saving money in the short term," he says. He has studied seven deals in the US and concluded that only two were successful. They often look good in the short term when the contractor can cut costs, then the lack of strategic involvement starts to damage the company.

o 'Are Major Information Technology Projects Worth the Risk?' by Catherine Griffiths and Leslie Willcocks (Oxford Institute of Information Management/ IC- Parc Imperial College).