Of all the money spent by Rolls-Royce on the research and development of their latest jet engine, half goes on direct research and the remaining half goes on refining the way the company puts it together.
I will repeat that: Rolls-Royce spends half its research budget on refining its construction procedures.
I haven’t stopped thinking about that since first I heard it. It makes complete sense: it is highly unlikely that the first attempt at assembling such a complex piece of machinery would be anywhere near perfect.
The temptation to stick plasters on flaws
But it’s also a challenge. How often is the NHS prepared to do this? Perhaps someone has a good idea – NHSmail, for example.
It’s planned, coded, and released. Do we really think the Department of Health will get such a complex application – including its integration with the human procedures – right first time?
The law of averages suggests not. So will the DH spend as much again refining the product?
Two years ago, I would have said not. But, thankfully, both NHSmail and Choose and Book are now being re-worked; which has got to be good news.
Even so, this principle still poses a challenge. Like yours, our clinical commissioning group is new – ultra-new. There is no way that we will get its systems right first time.
Indeed, there is every possibility that our first attempts, however well-intentioned or executed, will ultimately prove to be way off-target in specific circumstances.
But in these days of restricted finances, the danger is that we will be tempted to stick with what we’ve got, rather than refining it repetitively until it is utterly brilliant.
Suppose we were to discover a flaw in some of our newer software? Never mind, we could stick on an extra piece of code, like a finger plaster.
Four months down the road, we might discover another flaw: so we put on another bit of sticky tape, which interferes with the first one.
Now we have the equivalent of spaghetti programming, in which there is more emphasis on quick fixes than on getting the whole system right. It’s not the way to go – certainly not in the long term.
A personal insight
I’ve just had first-hand experience of this. When first I started as clinical lead, I created for myself a complete directory structure for holding relevant documents, partially mirrored by another set of directories that was intended for sharing with our IT committee.
With surprising regularity, documents started to get lost. I couldn’t remember where I had put them!
Eventually, I bit the bullet, took both directory structures apart and reassembled them. It took some time and a lot of mental concentration.
I’m sure I could have spent the time very successfully on something else that was, apparently, more immediately profitable. But now it’s over I am hugely gladI did it.
The new filing systemsare much more intuitive and functional and, as a result, over the next few months I expect them to save me large amounts of time.
In the past, it was all too easy to pick up a file and work on it for an hour, only to discover that it wasn’t actually the latest version and I had to do it all again. There will be no possibility of mistakes like this in the future.
What’s the difference between my old directory structures and the new ones? Not a lot – often the differences are quite subtle. But it’s in these subtleties that real convenience, user-friendliness and – dare I say it? – beauty lies.
Amateur v professional
What happened to my own filing system is mirrored elsewhere. As a CCG, we have put a lot of work into the menuing system for our Extranet, trying different layouts to see which is the most intuitive.
It would have been easy to settle for the first version: but this would have irritated a lot of people because of the lack of functionality and user-friendliness in some areas.
So we changed it. And we changed it again. And again. And again… constantly polishing, constantly refining.
And we’ll keep on changing it until we can’t think of a way to get it any better – which, quite seriously, will probably be in about two years’ time.
That’s the point at which the users will stop being aware that there is any background programming going: when the Extranet is so intuitive that users forget they’re dealing with a computer program.
This concentrated, reiterative process reminds me of the difference between an amateur piano player and a concert pianist.
The amateur practises until he can get it right: the professional practices until he can’t get it wrong. It’s the same principle – refine and polish; polish and refine.
A challenge for you
And so to my challenge, which applies to all CCGs and those working in them. Are you going to be like Rolls-Royce – refining, refining and refining?
Or will you take the easy route, the convenient one, the way the NHS so often does? “It works, sort of. Leave it alone. We can create a workaround. It’ll be cheaper that way.”
Only it isn’t cheaper. It takes time to set up a computer system to deliver exactly what you want, when you want, formatted how you want – but once you’ve got it right you’ll save time and money hand over fist; and reduce everyone’s stress in the process.
To put it another way, clunky programming and inelegant systems waste the time and energy of health service workers.
Maybe it’s only a few seconds on each occasion, but if these programs are being used across the CCG hundreds or thousands of times a week, then the amount of staff time wasted will be enormous.
Even so, you may still be wondering whether your CCG can afford to spend 50% of its IT development costs on refining its systems. I would ask the opposite question – can it afford not to?
Dr John Lockley
Dr John Lockley is clinical lead for informatics at Bedfordshire Clinical Commissioning Group and a part-time GP.