Why has yet another NHS IT system project has fallen short?
This follows the NHS’s failed attempt (the National Programme for IT) to build the largest civilian computer system in the world in the early 2000s – a patient records system for 220 of the UK’s NHS trusts. After costs of 10 billion pounds the system was used partially by just 22 trusts.
Reading reports on this fiasco you get the impression that the mistakes were contractual, that with better control of the voracious IT contractors who stepped up eagerly and greedily to the task all might have been well.
This one, for example, from Computer Weekly, identifies various faults in the commissioning (overly political and top-down), contracting and execution of the project and points out that end-users were involved too little.
Hubris….
But very few of these reports point out that these projects are just TOO BIG.
Is it that they are big IT projects, or just big projects? Is there something about IT projects that makes them more vulnerable to overrun or failure?
Over the last years I’ve seen the steady and exciting progress of the Crossrail project to build a railway under London. This appears to be on schedule and on budget, or at any rate close. It’s the largest engineering project currently running in Europe. Why should a massive engineering project succeed and large IT projects fail?
You might think that dealing with the abstract would be easier than dealing with the physical. But, in fact, it’s the opposite that’s true. Let’s compare the Crossrail project with a project to implement a large IT system:
In the case of a project such as Crossrail you’re dealing with something new. It’s large, but in fact travel is a highly constrained human activity that involves getting on a train at a station, travelling a certain distance and then getting off at another station. There are only so many permutations of possibilities. Purpose is clear, and the engineering involved in making this possible is largely physical. True, all sorts of physical difficulties can emerge, but it’s all about materials and their interaction. How someone gets onto a train at one station doesn’t directly affect the way they get off at another.
In the case of a system implementation project you’re dealing with the partial computerisation of complex human activities which already exist, which are not easily constrained and which evolve as an organisation evolves. The resulting ‘system’ is partly human and partly electronic, and an implementation project is all about making the electronic part fit into the human part perfectly. The benefit lies in speeding up certain aspects of the overall system, making it cost less and making it more reliable. For example, being able to access X-ray images from London that have been created in Manchester, is quicker by computer than by post.
To my mind these are essential differences between these two types of project, and it’s no surprise to me that a computer system implementation project becomes almost exponentially more difficult as it involves the evolving interactions of more and more people, whereas an engineering project perhaps becomes linearly more difficult as it gets larger.
The problem is that those who imagine the computerisation of part of what they do don’t understand how difficult it is to describe what they do. The impossible task for the systems analyst is to extract and then formalise instinctive and adaptable human behaviour from the people they interview whilst trying to understand a complex system.
A friend of mine works in the NHS and she describes how difficult it is to deal with the very basic problem of ‘patient identity’. Patients require the attentions of the NHS at all sorts of different times, at all sorts of different places and in all sorts of different contexts (under stress, in an emergency, whilst wanting to conceal their identity, etc.). Determining if this patient is the same as another is not a matter of the provided name, address, age, date of birth, nationality,and so on, and adopting a probabilistic approach (as some software systems do in other contexts) can be dangerous in a medical context. On the other hand, not knowing that this patient is the same as that patient can lead to incorrect diagnosis and prescription. And this is just one basic problem. Establishing human identity is a very much more complex process than tunnelling through London clay.
One approach to large projects that’s often mooted is the idea of breaking a large project down into smaller ones. I am sure this is the approach with large engineering projects. But even if this is occasionally helpful, I can’t see that it solves the problem. You still need to have a very precise idea in advance of how each smaller unit is related to other smaller units and the number of possible states each unit can be in.
I am an optimist, but a realist. Human behaviour is complex and I am inclined to think that some IT projects are just impossibly big and should not be attempted. Rather have smaller systems that ‘speak’ to each other only through the mediation of human behaviour.
Adam Bager 