This article is more than 1 year old

Doomed from the start: considering development risk

Hell for a developer is ...

Inspired by our recent Mumps or M story (and M is clearly alive and well in many UK GP surgeries - readers mentioned EMIS and Protechnic Exeter as using M, in the past at least; both now have NPfIT solutions too), some of our correspondents involved with UK healthcare systems have contributed their points of view (no attributions, as it seems to me that speaking out here could well be career limiting). These make interesting reading

One clinician commented: "Personally, I'll be glad to see the back of the Mumps based system as it (or its implementation) is not up to what I need as a clinician in the new NHS. However, while I hope for a decent replacement, the chaos of the NHS IT program just leaves me worried that whatever is going to replace the old MUMPS version is going to be so 'improved' that it will be slower, restricted, inefficient and unreliable - just like most of the other 'innovations' in the NHS."

Obviously, not much resistance to the idea of innovation there, but indications of a failure to actually achieve stakeholder "buy-in" (for all stakeholders including users, developers and regulators) before starting the new developments - a crucial first step in any software development project.

A correspondent with experience of one supplier commented: "The [M-based] Protechnic Exeter product in question was originally developed by a cooperative of GPs."

I'd agree that it's always good to involve the target users heavily if you want true buy-in - and, in this case, where GPs are responsible for the security of patient records, almost essential - although I'm less happy about them being entirely responsible for development (application development is a science, or at least a craft, in its own right), even though this could be very successful in specific cases.

One of the reasonable expectations for NPfIT, of course, is improved operability from the elimination of fragmented technologies. But this implies a potentially huge integration problem (and it is thus interesting that InterSystems Caché, one of the suppliers of legacy M technology, and much more these days, has a rather impressive new integration product called Ensemble on offer).

A reader with experience working for a health systems supplier comments that his company "had to abandon one large-scale integration project when two customers combined, because a feasibility study showed that it wasn't. They simply handled data too differently. These two customers were both using our highly specialised (if quite flexible) product; organisations using different products have a correspondingly lower chance of interoperating".

And, of course, if you bring in new and untried (in these applications) technologies, that may or may not scale to the volumes required, will this make integrating existing data easier? And, if you're dependent on fewer suppliers, each successfully selling platforms aimed at the general marketplace, will you be able to pressurise them into adopting your agenda rather than their own?

I don't want to be too negative, however. A correspondent working in the NHS commented: "I don't think GPs should be writing software, though. My impression is that by and large NHSIT do have a good grasp of the situation and technology, and that with a bit of luck and proper funding and commitment (and there's the key, it has to be over at least 10 years for the current drive to work), the NHS's IT infrastructure will end up in a much better state, even if it also has new problems." Let us hope so, but proper risk assessment and management early on could help reduce the requirement for luck.

There is a huge developer resource available to most project managers, the developers' (and users') "organisational memory" of why things are as they are, which is all-too-often neglected (and often lost forever when the dubious financial benefits of outsourcing are discovered). This is why calling in outside contractors can increase some risks (while mitigating others - your in-house developers know well where they've come from, but may have little actual experience of where they're going).

It's also why agile techniques, such as using stories in eXtreme Programming to capture "requirements", can reduce risk, because stories tap into "organisational memory" (unless you've sacked it); and why federating legacy applications as services is becoming popular. Even in the new NHS, it might be possible to retain organisational memory by "wrapping" existing applications to look, and interface, just like new NPfIT applications.

More about


Send us news

Other stories you might like