Doomed from the start: considering development risk

Hell for a developer is ...

Another of our readers, Dr Adrian Midgley, represents, perhaps, just one example of (informally published) "organisational memory" in the NHS for designing GP Clinical Systems, with his series of Hubris essays. These were mostly first published on the academic ("for varying values of academic"), gp-uk jiscmail list funded by the Joint Information Systems Committee (JISC).

Mind you, corporate memory at the sharp end isn't the only neglected resource. A lot of knowledge has been documented in resilient, random-access devices known as books. As long ago as 1975, Fred Brooks in the Mythical Man Month was documenting the "second system effect".

This is the tendency to correct all the problems with your first system when you get a chance to revisit it, resulting in an overcomplicated system addressing minor issues with yesterday's technology, which completely fails to exploit current and emerging technologies. The classic example is OS/360, which had great overlay programming facilities but failed to implement virtual memory.

But, it seems to me the new NHS architecture may represent a typical 20th century centralised Government system, instead of a federated 21st century service-oriented architecture - that could exploit existing NHS technology (especially that implemented in GP surgeries). Many of the problems with NHS modernisation seem to come from the fact the NHS already has extensive local IT systems in GP surgeries and elsewhere, and centralisation is being imposed from above, through hospital trusts.

In support of this view, one reader commented that "the current consolidation is forcing local systems to change for non-local reasons, hence forcing an upgrade cycle with its attendant problems when it wouldn't usually be needed". In other words, there may be benefits from consolidation for national NHS management, but the pain associated with the changes will be felt by the GP surgeries and current technology suppliers. Will GPs be fully supportive in these circumstances, and is there, for example, some risk associated with asking suppliers of current technology to close themselves down tidily as NHS suppliers, possibly, in preparation for an empty future?

The new isn't always obviously better than the old, even when there are good strategic reasons for moving on. I myself remember being told to persuade secretaries that the early Windows Word Processors were "better" than the faster DOS-based systems they were used to - when they were only better in the sense that they allowed managers to do their own word processing, albeit slowly, and get rid of secretaries. And, of course, secretaries were quickly re-instated as management status symbols, so then we had the costs of inefficient word-processing (sometimes performed by highly paid managers) and the previous secretarial costs too. A real victory for business process redesign!

One reader with experience of both old and new NHS systems commented: "The M version [of one supplier's system] still seems to be a far more reliable, stable, faster, cheaper implementation than the full GUI version. M was a wonderful language for RAD, and the speed of the database was truly frightening, MS-SQL still cannot get close to its performance [perhaps he hasn't tried SQL Server 2005 yet, but all the same...]. We used to have 20 dumb terminals running off a 486, and 'cos it was all vt100 the response of each terminal was instantaneous. Also 'cos it was all text based, the users quickly became used to the 'eclectic' interface and data entry was far quicker than the new fangled Windows interface they use in the shiny new GUI."

Hmmm, it's not the first time I've read such comments, and they'd encourage me to put a lot of extra effort into risk mitigation and getting user buy-in to any NHS project I was unlucky enough to be involved with. Also, I might consider keeping the old technology around for a bit, just in case it is needed after all. ®

David Norfolk is the author of IT Governance, published by Thorogood. More details here.