When IT projects go right - How not to stuff it up

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.

Content Contributors: Josie Sephton