Another day, another enormous public-sector IT project disaster getting news coverage. This time, the abandoned NHS systems project that has cost us all £10Bn so far. “All” of course being unless you are a shareholder in one of the companies involved, in which case you’re probably at worst neutral on the deal.
“Richard Bacon, a Conservative member of the (public accounts) committee, said the report was further evidence of a “systemic failure” in the government’s ability to draw up and manage large IT contracts.”
I’ve two things to say to Mr Bacon. First of all, how well your career has progressed since the TV presenting days and that nasty incident … (oh -not that Richard Bacon).
OK – I’ve got one thing to say to you. The systemic failure you associate to governmental abilities isn’t limited to the public sector. It’s just that there are bodies like the public accounts committee that hold public sector projects to account. This stuff goes on in all sorts of private sector organisations but gets kept quiet about.
So why are we so bad at running big projects? There are three things at play from my perspective.
1. Investment processes
The way in which we do cost/benefit type analyses of potential projects is a starting point for failure. Projects are made up numbers. There is an interest for project sponsors to overplay the benefits and underplay the costs. And there is an interest for bidders to contracts to underplay their costs and then rack up additional charges later along the line to make the work profitable. All of this conspires to make many projects duds from the start.
2. Overly focusing on the technical stuff
Technical projects focus on technical aspects; that might be the IT in an IT-led project. It might be the accounting books and product lines in a merger and acquisition (the majority of which destroy value). But organisations are a summation of the people and the systems and the processes (and the other stuff too) and undue focus on too few of those elements leads to dysfunction. The best “technical” solution might not be the best practical solution or the one that gets best adoption. Think VHS over Betamax. Think QWERTY Keyboard over every other suggested text input device ever.
3. Diseconomies of scale
Growth, whether linear or exponential, eventually flattens out. Sometimes it can even go into reverse. It’s the same with the economies of scale that are returned by big projects. At a certain point the complexity and scale becomes so great that it’s more expensive to do things “one” way than it would be to do a series of smaller projects. If you want evidence, take Excel away from a major organisation and see it grind to a halt as you find that all of the important maths isn’t happening in the ERP system, it’s happening in hundreds or thousands of spreadsheets.
The NHS, as recently discussed, is the fifth biggest employer on the planet.
4. Blinkered benefits realisation
Just over a decade ago I was involved in one of the earliest streaming video projects at the BBC. It was in the days when streamed video was very expensive (hard to believe today), and the project was very, very focused. It was to deliver preview versions of TV programmes to TV programme buyers at channels across the globe. Each full programme (from memory) was going to cost us a couple of hundred pounds to deliver. But that would replace about £400 which was the end-to-end cost of sourcing, duplicating and distributing a VHS copy of the programme.
That was the project investment objective: cost saving (as so much in the IT space has been over the years). On that metric it was a failure, because VHS distribution actually went up because people were seeing the streaming version and then ordering a tape to show to others.
Of course the real metric it transpired would have been in terms of positive impact on sales. But the reality of doing new things is that you don’t know what you are likely to achieve until you start doing them. If we had crystal balls, we wouldn’t be clanking them around IT projects…
Well, a few things: smaller projects; focus on frameworks for open exchange of information between systems rather than single systems or complex integrations; project approaches that focus on change of organisation rather than change of systems; project approaches that commit to a level of investment against a series of desired outcomes and track those outcomes as they go.
The era of monolithic systems projects should, quite frankly, be behind us by now. That senior managers, politicians and the public at large still think that silver bullets will be the answer to all our problems says more about our psychological immaturity as a species than anything else: big, intractable, hairy problems are usually that way because they are big, intractable and hairy. Our natural inclination is to believe that they can be magically solved with a quick waxing (a more obscure analogy I think you’ll be hard to find…)