Reports of information systems projects going belly-up have become all too common in recent years. The biggest failures are household names: the London Stock Exchange, the London Ambulance Service and Wessex Regional Health Authority to name just three.

Yet for every big-name cock-up, there are many dozens of small projects that do not work out as their sponsors intended. According to Arthur Andersen partner Paul Williams, the chief reason for this is poor project management.

Speaking at a recent ACE conference on systems development, he said he had seen managers lose control of projects without realising they had done so.

‘Project management is, in my view, the next great profession,’ he said. ‘As a subject it is understood by relatively few people. I find they tend to get appointed to these roles with very little real understanding.’

If the managers responsible for a project are losing touch, what about finance directors? Don’t they have to sign off these projects?

According to Williams, they do. But they don’t get too involved unless it is a financial system or one which underpins the entire success of the organisation.

‘There is frequently ambiguity about who is responsible for a project,’ he said. ‘At the very least they should have a project sponsor or director who must be a very senior manager or board level director responsible and answerable for it.

‘Often that line of responsibility is quite unclear and it frequently comes down to the IT department rather than the end-user.’

Williams, a computer assurance partner and head of the English ICA’s IT faculty, was one of a three-man panel appointed by the former health secretary Virginia Bottomley three-and-a-half years ago to look into the collapse of the London Ambulance Service’s ambulance ordering system on the day it first went live.

The project report is a collection of classic ‘what-not-tos’, according to Williams.

One of the key solutions is to establish a rigorous internal audit department that can keep watch on current projects. This, however, is not a panacea, because project managers are not above submitting misleading or wildly over-optimistic progress reports.

Williams added: ‘One of the warning signs that should alert senior management to an imminent disaster is the quality of the progress reports. IT is so unlike any other major project – if you’re building a bridge, you can go and see how close the two ends are to meeting, but with software, it is very difficult to tell whether or not development is on track. It is not at all uncommon for senior management to be misled by the project manager’s progress report.

‘If I go to look at a project, I will ask for the current project plan. I have often found it is out of date, woolly or non-existent.’

Research by Coopers & Lybrand into IT project management last year found the length of reports can be inversely related to their success. The more at risk the project, the more rambling and incoherent the report can be. Often these so-called progress reports turn into little more than a justification for the project.

ACE’s conference was a two-day event. Delegates attended in order to obtain a comprehensive overview of the total systems development process and how they could ensure development and implementation success within their own companies and organisations.

Given the success of the public sector in managing major projects, it really is a wonder that conferences of this sort are not being run every week of the year with capacity audiences. Certainly the public sector, and a great many private sector organisations, could learn a thing or two from them.

Even after Williams’ report for the Department of Health, IT cock-ups in the NHS have continued apace. The National Audit Office produced a scathing review of the NHS’s hospital integrated support system (HISS) earlier this year.

HISS was a service-wide initiative to improve financial and clinical information management.

Intended to generate efficiency savings, the project overshot its original funding target of £58m by a not inconsiderable u50m. The NAO found £32m of this went to just three hospitals for a pilot initiative in 1988.

In projects such as these it is the over-ambitious and all encompassing nature of the schemes that proves to be their downfall. It is not uncommon for organisations to elect to go for a ‘big bang’ approach to new systems development, packing as much functionality as possible into their new software. Williams said this approach was laden with risk.

‘It’s all about risk management. You have got to break a project into manageable chunks. I have seen projects with two-year delivery cycles. It’s too long. ‘Businesses change drastically in that sort of time. A two-year delivery cycle is courting disaster.’

In any project, deliverables must be no more than six months apart. The best thing is to write delivery times into the contract, and expect parts of the system to be delivered at regular intervals. That way the organisation starts to reap the benefits of its investment quickly, and any potential problems soon show up.

IT disasters are nothing new. And Coopers’ research last year found that 60% of large organisations admitted to a major control failure with their computer systems in the previous two-year period.

More alarmingly, 85% had projects that were running late, over-budget or which had delivered no measurable business benefit.

Any IT directors worried about their career prospects after overseeing a disastrous implementation shouldn’t lose heart. There is no shortage of accountants and finance professionals trying to get to grips with systems development and, if all other career options fail, these same IT directors could find a useful place on the conference circuit, telling everyone else how they failed to stop a disaster in time. Then, at least, they might manage to salvage some good out of their own nightmare.