OPINION

To many NHS managers, computer projects and problems go together like ham and eggs.

This is mainly because disasters make excellent news copy, whereas things that succeed are taken for granted.

The only feel-good IT story I saw last year was the one about the Inland Revenue losing 10 years of tax records.

But there are, of course, many successful computer projects.

This is about one of them and why it worked.

The project was to computerise a medium-sized acute trust with 2,500 staff and 650 beds. The system included a patient administration system, electronic patient record, results reporting, case-note tracking, clinical information, accident and emergency, and an integration engine to tie in seven third-party systems. It was a large and complex project involving many people across a wide range of disciplines.

Both procurement and implementation were carried out at breakneck speed. The trust's legacy system had to be switched off at a certain date. So if the new system did not go live on time, there would be no patient management system in place at all. The deadline for the project was 11 months from the European Journal advertisement and just five months from the date the contract was signed.

That is a tight timetable by anybody's standards. In the event, the system was implemented on time and within budget. Hey presto! Another NHS IT success story hides its light under a bushel.

Let's look at the key factors in this success:

The deadline required focus.

Decisions that needed to be made were made promptly - not made once, changed, made again, shelved, revisited and all of the other Parkinsonian time-wasting manoeuvres that so often characterise protracted projects.

The short timescale meant that the same team saw the project through from specification to implementation. This provided stability.

There was not enough time for the ground to keep shifting during planning and implementation. Over the four years that many NHS procurements take to complete, anything can and does happen.

Technology, national guidelines, working practices, priorities and even the organisation's structure may change. And of course, the longer things last, the greater the chance the whole project will be torpedoed by plan X.

The contract was equitable, practical and straightforward.

This set the tone for the project and meant people could concentrate on the job in hand, rather than constantly looking over their shoulders for potential penalties or contractual liabilities.

Trust staff spent a lot of time working with the system before signing a contract, so there was a clear understanding of what was being delivered. A successful project requires realistic levels of expectation. Even unintentional pre-contract misunderstandings can lead to relationships breaking down.

The managers responsible for implementing the system and realising its benefits had been heavily involved in the selection process. They were also given material and moral support, throughout the lifetime of the project, by the trust's directors.

This gave the project team both a mandate and a real sense of ownership.

The system was implemented one step at a time. For example, an outpatient system was implemented in one department so that the trust could evaluate it in a live environment before rolling it out. This approach reduces both risk and pressure.

The supplier and the trust worked together as a team. There was no chasing personal credit or avoiding blame. There were no pre-emptive letters that would prove conclusively that the blame lay elsewhere should things go wrong. The whole team adopted an attitude of problem-solving without blame: it took collective responsibility for both success and failure.

Problems are inevitable in a project of this size. In this case, they were kept in the open and dealt with by the team. People would volunteer to sort things out without worrying about who had caused the problem in the first place. They concentrated on who was best placed to fix things at a given point in time. The supplier did the trust's work and vice versa, so everyone saved time.

Although problems and disasters can make interesting reading, they also promote a mindset that exaggerates the risks attached to the introduction of IT. This has helped create the gulf between those who are promoting proper use of IT in the NHS and the relentless centralism and bureaucratic paralysis that prevent working computer systems from even being procured.