In February 2002 the UK embarked on what was described as, “the world’s biggest civil information technology programme”: the NHS National Programme for IT (NPfIT). The vision was bold: to create a modernised health service, including the delivery of electronic health records (EHR) to patients, allowing for interoperability.
For years the project enjoyed defence from the highest levels of Government, even as it swelled to consume greater budgets and stretched timelines.
By September 2011 however, the project – which was intended to be delivered 6 years earlier with a budget of £6.2 bn – was summarily scrapped, realising very little of its aims. There were questionable contracts, poor usability, floundering suppliers, and crashing IT systems which degraded patient care.
The final cost of the failed project has been estimated at as high as £20 billion of taxpayer money. What went wrong?
In this article we’ll consider the project vision. Although critical for success, poorly constructed visions can represent a risk to your project. We’ll look at how you can build one that will stand the lifetime of a project and beyond.
Just politics?
How did such strong high-level support for NPfIT continue for so long?
It would be too easy to put this down to politicians simply covering their backs. Or just loss aversion. Though no doubt both played their part.
In truth, as delays, problems and costs mounted, the project manager was able to wield the clear vision that was the project’s inception and its promise: a truly modern, technologically advanced NHS.
But the vision was so dominant that it defied all common sense.
The Vision Trap
There can sometimes appear to be a tension between vision and reality. Both are necessary for success.
The vision is the engine of your project. Your vision has practical consequences because no one works towards an end that doesn’t seem realistic or better than what came before. Good project management sometimes requires the defence of that vision, so that when the project slips or seems to falter, the team is motivated to continue on.
But if that shared belief in success is so crucial, it’s easy to see how one can find themselves defending the vison beyond all reasonable doubt. This is the vision trap. When the promise of the project is seen as an essential component of success (which it is) then criticism starts to look a lot like an attack. And that’s when the problems begin.
Where did your vision originate?
The solution is a truly robust vision which stands the test of time. This is how you get one.
From the very beginning, your project should be taking attacks. You should never decide the solution before the problem is truly understood. The deliberative process at the start of a project can appear messy but it serves several functions, including:
- Is this the right solution? (“We thought it should be an app, but have we considered the costs and updates needed to keep it on the app store?”)
- What are the project risks? Even if it goes ahead.
- What does it really need to do, according to the people who will use it?
- To allow people to buy into the project.
The last one might seem odd but, without subjecting the project to scrutiny, it’s also difficult for people to identify with the goal. The deliberative process is not just a way for people to shoot the project down (though sometimes it needs it!) but is also a way for people to invest time, energy and thought in something.
These are all fundamental components of attachment. Part of identifying with something else, whether it be with people or projects, requires an investment of time and input. If you want person A to form a bond with person B, better than B buying an expensive present is having A teach them something. What we invest in we are more likely to value.
The deliberative process not only tests the validity of the project but allows the crafting of a shared vision, from the bottom-up, from the people who one day need to use it.
Conclusion
Though essential for success, not all visions are created equal.
Visions imposed from the top down are brittle. Even when they are right, they are often wrong because they lack the support of those that must adopt them. But that’s still assuming the project even concludes.
In the case of NPfIT, the vision was so strong and abstract that it was able to become entirely divorced from the reality. Mounting complaints from users themselves should have toppled the project but instead, to various governments, the vision remained tangible and bold.
To take hits and adapt, your project vision needs to be, 1.) shared, 2.) an extrapolation of possible things (i.e., realistic), 3.) tested early, as though it were ok to break (so that it can if it must), 4.) owned by your end users in some way without you, and 5.) inclusive of imperfection.
To truly last your vision should not be built, but organically grown.
