The words 'late' and 'over budget' are depressingly familiar prefixes to the term 'IT project'. Remember Taurus? The doomed electronic trading system for the City never saw the light of day. Or the project to link the computers at the DSS, which started 13 years ago and was costed at £713 million? At last count, the project was still ongoing with costs at £3.35 billion. Or what about the Home Office's Case Record Administration and Management System (Crams), criticised by probation officers as expensive (£23 million over budget), user-unfriendly and late? Taking private industry, local government, defence and health spending together, billions are lost every year as computer contractors fail to meet deadlines and budgets.
'Running late and over budget has always been endemic to IT projects, partly because the technology itself is changing so fast,' says Karl Schneider, managing editor of Computer Weekly. 'If your business is bridge-building, you have hundreds of years of relevant experience to look back on and learn from, but with computing that's not the case.' As he points out, a major project will take years to implement. Typically, two or three years into a project, it will be more than seven years since it was specified. 'If you think about what you were using seven years ago, if given the opportunity to start over again, the chances are you would choose to do it with a different technology.'
Changing techno horses in mid-stream is a recipe for disaster but, conversely, the attempt to avoid that by 'future-proofing' a system can lead to the same sorry conclusion. Successful projects tend to be those where management is confident that it can build it to time and budget. 'Things that work in laboratories often don't when rolled out to 5,000 people in the field, so over-reaching existing technology is a common cause of over-running,' says Schneider.
The answer to the problem is always 'good management' - but managing what? The Wessex Regional Health Authority's judgment on its own failed computer scheme to centralise its information offers some clues. When the authority was asked how it could have placed so much reliance on so many consultants without properly controlling their activities, it replied that the consultants had been allowed to determine the service that they were to provide. The authority had not been sufficiently educated. It had not known what it wanted to do, and had not followed proper financial and procurement procedures. It was felt that lack of supervision and an over-cosiness in the authority had caused a dramatic loss of resources - a system abandoned at a cost of £20 million.
If knowing what you want is the first step, making sure your contractors are bound to deliver it is the next. 'Project management is a very rare skill and not one generally addressed in computer contracts, where the expectation gap between what is awaited and what is supplied is substantial,' says Rachel Burnett, a partner at City law firm Masons. 'If the contract is drawn up properly, that won't necessarily be a problem but, typically, not enough time is given for negotiation, particularly when it comes to specifying realistic service levels,' she adds. 'Detailed discussion at the outset will always pay off in the implementation, since a good contract is not a negative thing but a facilitator, giving a project a better chance.'
So there you are. The key to avoidance is a blend of realism, supervision, project management and control - oh yes, and go light on the consultants but heavy on the contract.