When IT projects go right
How not to stuff it up
Project management There is a vast difference between running a project and running one successfully, as a cursory scan of recent news shows.
In the run up to the Commonwealth Games, dire predictions were rife that the event could not actually go ahead. The government initiative to generate a quarter of all the UK’s electricity over the next 10 years through wind turbines has also been dogged by problems, the main one being that high pressure and low winds – good weather to you and me – will generate only a fraction of that amount.
In the world of technology, too, failure is rife. The nostalgic like to hark back to a time when IT projects always ran smoothly – and the sun always shone in summer. When things did go wrong, at least no-one beyond IT usually got to know about it.
Rightly or wrongly, IT had full control. It would decide what needed to be done then disappear behind closed doors, only to emerge with things pretty much in place. And it also helped that expectations were lower and a few shortcomings were accepted as par for the course.
Things are less straightforward now. IT projects are run on a much more inclusive basis, with varying numbers of people from different departments involved, including senior managers if the project is a large one. And many of these people have a better understanding of IT issues and stronger opinions about what they want as the outcome. In the midst of this, the likelihood of everyone working to a single agenda is slim.
Even within the technology domain, things have become more complex. In a world of converging networks and services, infrastructure and software dependencies need to be taken into account if the project is to succeed. An IP telephony implementation, for example, that isn’t based on a thorough assessment of the underlying network and extensively tested is a highly risky undertaking.
All of this is not necessarily a bad thing, however. Providing the project is properly managed and executed there is a greater chance of the end result delivering what is best for the business. But it means doing a fair bit of juggling and balancing to take into account these extra dimensions. So, how easy is it to achieve in practice?
Every IT project is different, but the successful ones are likely to display a number of core characteristics. The first is that they are based on a clear vision of what is to be achieved. This vision must be big enough to make a difference but must also make sense in the context of the business. It must be achievable, even if challenging, rather than some ‘pie-in-the-sky’ grand plan.
The second characteristic concerns the support and commitment of the different parties involved across the business, especially senior management. An enthusiastic nod of the head in the direction of the project is not enough; support must be based on a genuine acceptance of shared responsibility.
Third is an understanding of the problems to be tackled. From an IT point of view, this might include not only the underlying infrastructure and system dependencies, but security, training and support. But IT-related issues also need to be considered in the context of the business’s overall needs, such as enabling home and mobile workers to communicate with the rest of the business, or dealing with regulatory and governance issues, such as privacy or procedures for handling and storing customer data.
The final common characteristic is that sufficient resources and skills have been made available. The plan needs to consider any gaps and how to fill them, and leave a degree of flexibility to deal with unexpected problems such as staff leaving or some individuals being over-committed.
The project manager must be able to pull together all the different threads effectively, while balancing any requisite internal politics and sensitivities. Although a proven track record helps it is not essential, as long as there are enough stringent check points along the way, as well as clear lines of reporting upwards.
Straying from this core set of guidelines is likely to lead to project failure. Probably the best-known example (although by no means the only one) is the UK government’s £12bn NHS National Programme for IT (NPfIT). Aimed at introducing national patient records for the whole NHS, it was largely seen as a fiasco and was recently replaced by a decentralised system.
The project missed pretty much all of the targets we have outlined. The vision on which it was based – access to and transfer of patient records around the country – was arguably not answering a genuine need and was far too ambitious. It neglected to properly consult the doctors and nurses who would be using the system, and so lacked the necessary buy-in where it was really needed – at the more grass-roots level. Such consultation would have helped the project leaders understand the needs and problems that staff wanted resolved, rather than those perceived by the higher echelons of the NHS. It also went through several changes of project manager during unhappy life.
Very few IT projects match NPfIT in terms of scale, of course, but even a much less significant failure is something that no one wants on their CV. ®
Interesting you bring up NPfIT
As someone who was actually quite close to the debacle...
There is (and was) a strong need to allow greater access to peoples medical records. Put shortly IT WILL SAVE LIVES.
However, there was a strong resistance from GPs in general, not because of privacy concerns, or about a perceived lack of need (indeed the SCR is replacing a chunk of the really useful functionality), but because GPs perceived the data as *theirs*.
The resistance to the centralised DB from GPs was purely down to a loss of control. Essentially the nagging worry that it would far too easy to audit a GPs work without having to come to the GP and get the potentially incriminating data, immediately left a nagging doubt at the backs of GPs minds.
The privacy concerns leveled at the DB though were utterly foolish. It was misrepresented right from the get go, and the security it actually brought in was ignored. My question to people who complained that "Anyone could see my records!". How do you currently know who sees your paper records? There is no logging (as with digital records), and the only reason they aren't stolen more often is that the nice cabinet full of drugs is usually a nicer target.
That's not to say that bits of NPfIT didn't go well, much of it didn't, but planning was less of an issue than PR. If it had been spun correctly to parliament, GPs and patients, it wouldn't have been the dead duck it was basically from the start.
I always though
That the major failure of the NPfIT, was not particularly IT related.
My understanding was that because the NHS didn't have common, defined, business processes across the country, it made it impossible to build a single IT system to support those, non-existent, processes.
Most people seem to forget that modern IT systems are built to support business processes, rather than the old fashioned way of creating business processes to support the IT systems. If you can't describe your business process to the IT bods, you're out of luck!
You're perhaps playing a bit fast and loose with those numbers, the £12.7bn is over 10 years, it has also been reduced, it was down to at least £12.1bn by the end of the Labour Gov't and I presume it is lower still now. It is also not just being spent on the health records, for that money we get electronic x-rays (widely hailed as a triumpth), electronic prescriptions, choose and book, 1 internal mail system, NHS Spine network thing... etc etc.
Increasing the healthcare spend per person is a different argument. I presume this figure is calculated based on how much the average person requires anyway. Do people get turned away because a care provider has run out of money?
Personally, I'm quite happy money is being spent to modernise the NHS, the patient records system makes sense, it is logical that their should be a standard health record that can easily be transmitted between care providers when I move or need care whilst not being at home.
My understanding is the delays in implementation of certain elements can be put down to the fractured nature of the NHS (12 SHA's and 125 PCTS) of course with 3-500 GP consortia in charge this will improve Im sure.