ComputerWeekly.com.com

Six reasons why the NHS National Programme For IT failed

By Alistair Maughan

by Alistair Maughan, partner Morrison & Foerster (UK) LLP

Like many men, I don't go to the doctor very often. The last time I did, I was with my GP for 25 minutes: five minutes discussing my symptoms and 20 minutes helping her to understand how to use her new computer system to record my symptoms, her diagnosis and book the next appointment. Together, we experienced a system that was slow, cumbersome, insufficiently explained and poorly implemented.

That experience seems to sum up the massively ambitious NHS National Programme for IT (NPfIT, subsequently re-christened Connecting for Health) which the government has announced has finally been cancelled. Since NPfIT, as it was originally conceived, has widely recognised to have been dead in the water for some time, this coup de grâce is long overdue.

Given the amount of taxpayer money that's been spent on this project over the past seven years, it should give no-one any satisfaction that the problems of the NPfIT stem back right to the start of the project. You almost feel sympathy for those in the Department for Health whose role has been to try to salvage something from the project over the past three to four years - and also for service providers who invested a lot of time, resources and money in pursuing and attempting to deliver on contracts that were aggressively drafted but poorly specified.

Many of the lessons that can be learned from the failure of NPfIT are no more than commonsense. Indeed, many of the mistakes have been obvious almost since Day 1 - but the lessons appear not to have been learned, or at least not until too late.

1. Motives

"Top-down" projects are much more likely to fail than "bottom-up" projects, and NPfIT was top-down project par excellence. I identify a top-down project as one done for political reasons: and this can be both genuinely Political with a capital P in the public sector or a "vanity" or CEO-inspired project in the private sector. The history of public sector ICT and outsourcing is littered with politically-inspired projects that failed: the £1.5bn project to computerise benefit payments at post offices was the classic 1990s example.

The motivation to commence NPfIT came from Cabinet level and it's hard to argue against the fact that many of its aims were entirely laudable. But there is a big gap between laudability and deliverability. The decision to commence any project - let alone one which will transform a fundamental building block of a nation's healthcare system - must be made by the right people who really know about the issues involved. It's unfortunate for civil servants and the departments they run that they have to carry the can for projects devised by ministers that often only make sense on the political drawing board and are almost impossible to translate into reality.

2. Buy-in

Surveys regularly report that more than 30% of ICT project failures are as a result of poor strategy and business planning. This includes a failure to understand and align the commercial drivers and what value is intended from the project. Rarely is a project ever just an IT project; generally it should be viewed as a broader process to deliver business benefits.

It is a hallmark of successful ICT and outsourcing projects that there should be good consultation with all stakeholders involved, including particularly end-users. Ever since NPfIT began, there have been concerns expressed by key stakeholders within the health system, especially doctors and GPs, about the accessibility and utility of the planned system.

In particular, it was not clear even from the outset of NPfIT exactly what was going to be delivered to the ultimate end-users. Add to that the entrenched interests in NHS trusts about loss of control over their own systems and you have an inherently suspicious, if not downright hostile, user base. Few projects can succeed over the outright opposition of the proposed users.

3. More haste, less speed

One so-called innovation for which NPfIT was originally praised was the speed and efficiency of its procurement and contracting process. That process has subsequently become a mill-stone around the project's neck.

NPfIT rushed to award contracts in almost indecent haste with insufficient planning, particularly for such a large contract. Contract scope was unclear and much work needed to be done after contract award to agree key contract parameters such as scope and deliverables. At the time, this was felt by many to be a sign of success and the model for how future procurement should be done.

No-one could argue that there must always be a desire to procure and award contracts as efficiently as possible. But this can't come at the sacrifice of agreeing all appropriate contract terms up-front, rather than retrospectively once the contract has been put in place. Nor is this a substitute for doing appropriate due diligence before the contract is awarded and actually writing clear statements of work and requirements.

One of the lessons that should be learned is that projects will always run into trouble if they try to complete the contractual paperwork before actually working out the scope of what a project is about, what its deliverables will be and how they will be implemented.

4. Poor contracting process

The NPfIT procurement model called for a drastic cut in timescales, with no negotiation allowed, contracts offered on a "take-it-or-leave-it" basis and a very aggressive approach to legal remedies against service providers. NPfIT and its advisers appeared to forget the golden rule that these contracts involve a long-term relationship; so a hyper-aggressive approach to supplier management is counter-productive.

One of the issues that bedevilled the project from the outset was the extent to which the NPfIT was attempting to force service providers to accept onerous and one-sided contracts. Negotiation was a dirty word and NPfIT used heavy-handed tactics to ram through contract terms that were considerably harsher than had ever been seen within a government (or even private sector) context before.

It is worth noting that some of these provisions (for example, in relation to what happens on financial distress of a service provider or in relation to clawback of prepaid milestone payments) have found their way into standard practice within government - not always with entirely successful results.

The combination of the implemented payment provisions (under which service providers had to do all the work upfront with no payments until successful delivery) and the harsh termination and liability provisions, meant that the risks being absorbed by service providers were extremely high.

While many may say that service providers make a healthy margin and, therefore, ought to absorb risk, no service provider is a bottomless pit able to accept enormous costs and risks of delivery, particularly where the customer is in a position of being able to re-interpret and add requirements during the course of delivery. A number of significant service providers have fallen by the wayside during the course of the NPfIT project simply because of the difficulty of delivering what NPfIT wanted within its timescales and risk profile, and against a moving timeframe.

Hopefully, one lesson government will learn from NPfIT is that there needs to be a balance of risk and reward in negotiating contracts even for very large projects. It is notable that the standard paradigm for public sector contract terms has moderated significantly since NPfIT was initiated. Many might wish that there had been more reasonable voices involved in the original project who could have argued for putting in place a more moderate, deliverable contract that didn't force service providers to take on so many contractual risks that their own internal business cases became unstable.

5. Multisourcing

NPfIT was certainly innovative in its structure of making different service providers work together by awarding work in a series of lots. Part of the rationale for this approach was that different regional service providers could be swapped in or out if and when other regional service providers failed.

At least this has meant that, as some service providers have had their contracts terminated over the past few years, there have been others prepared to pick up the slack. But it does illustrate that anything other than a "one customer, one service provider" structure is very difficult to operate.

This doesn't mean that it cannot be established in this way - as the current swathe of multisourcing contracts has shown. But it does mean that there needs to be much more careful thought and planning in advance about how different service providers will be incentivised to collaborate - not forced to co-operate almost against their will and without some "script" or plan as to how disputes will be resolved.

6. Accountability

Finally, the termination of NPfIT also illustrates what I call the Mastermind factor - that is, there is a tendency amongst people involved in a project which isn't going well to adopt the "I've started so I'll finish" approach, circle the wagons and not step back and take the inevitable decision at a more appropriate stage.

Good managers on ICT and outsourcing projects are always asking themselves whether the original course of action is correct and whether adjustments are required - and they are prepared to take the ultimate decision at the right time and not delay the inevitable.

NPfIT was run by a very strong project director with a powerful personality. Maybe that was the best way to give the project a chance of success. Unfortunately, once the project ran into trouble there much less room for manoeuvre and few supporters outside the core team. Clear accountability is fine (indeed, essential) but accountability needs to be in the right hands and with the right checks and balances. If the public sector learns anything from NPfIT, let's hope that it will be how to identify and implement those checks and balances from the outset.

13 Sep 2010

All Rights Reserved, Copyright 2000 - 2024, TechTarget | Read our Privacy Statement