The Auricle

by Derek Morrison, 5 December 2008

BBC Radio 4 transmitted a programme called Wiring the NHS on 25 October 2007. A second follow-up programme was transmitted on 1 December 2008. While I was listening to the second programme I found myself reflecting on some of the similarities with a much smaller, but yet still major IT project in financial terms, i.e. development of the putative “world class” learning platform of the now defunct UK e-Universities (UKeU) initiative.

Although I think the BBC programme should be required listening for all those responsible for either strategic/policy or operational aspects of ICT projects it’s a real pity that, as the major public service broadcaster the BBC does not do the same as the US On the Media archive which also provides transcripts of its programmes. Low technology I know but such provision would be a valuable public and future scholarly resource.

So what echoes of UKeU did I detect in Wiring the NHS?

Despite the obvious differences of scale both the much smaller UKeU initiative and the National Health Service (NHS) Programme for IT are/were technology driven and therein lies many problems. By declaring the intention to develop a “world class” platform the UK e-Universities initiative immediately became a hostage to fortune and perhaps, unintentionally in that case, made risky technological innovation and development mission critical. The NHS Programme for IT has embarked upon risky technological innovation and development and the integrated packages making up the system it is seeking to develop are certainly mission critical. However, problems with the UKeU platform at worst represented lost time, frustration and ultimately considerable money whereas problems with 50 million patient records on a “data spine” the NHS Programme for IT can result in distress, pain, embarassment, loss of confidentiality/privacy, and even avoidable deaths.

The loudest common echo for me in both initiatives was encapsulated in the significantly divergent perceptions and views of the different stakeholders. It is in this divergence where I think lies the seeds for the failure of major publicly-funded IT projects lie.

Why?

Stakeholders on the system analysis, design and development side perceived multiple “requests for changes” to a specification they viewed as a contractural document. Users of the putative systems, however, perceived “clunkiness” and mission critical “defects” that made the proffered solutions “unfit for purpose”, e.g. in the NHS for IT initiative a key contractor, Fijitsu, told the UK Public Accounts Commitee that hospitals requested 615 “changes” to the specification.

Ahh! the specification. Herein lies the seeds of further stakeholder clashes and sources of failure. When constructing a ‘concrete’ entity like a car, high rise building, bridge or aircraft there are certain scientific and technological principles that must be applied to the creation of the multiple elements that lead eventually to the realisation of a fully working system. In other words you can’t half-build a bridge and drive over it or half-build an aircraft and attempt to fly it because these entities only function as multifaceted systems. With a bridge or aircraft everyone can agree it works because it is seen to work and does not crash to the ground. These entities may still need to be refined and enhanced but from day one they need to be fully working integrated systems. These complex systems have equally complex sub-systems which are designed, and tested in their own right but it is only when these are all brought together does the entity ‘fly’. Should the entity fail to fly, however, this is not a disaster because these putative new systems are themselves part of a system which has an incredible level of built-in redundancy, i.e. there are many more cars, buildings, bridges, and aircraft and so whilst the new entrant may improve matters the other provison has not been “switched off”.

But with major public IT projects there seems be a requirement to create THE definitive car, bridge, building or aircraft so that other entitites can be “switched off”. I suggest that building a concrete entity like a bridge or aircraft whilst incredibly complex is actually be a lot less challenging than analysing and developing a major IT system to enhance the work of more abstract and heterogeneous areas like the UK NHS or UK Higher Education. Complex IT systems are best in homogenous contexts and a failure to recognise heterogeneity and local contexts can be the source of much “changes” versus “defects” conflict. A specification leads to contracts, design documents, project plans, prototypes, pilots etc. If the specification, however, is based on an assumed homogentity which doesn’t actually exist what can result is either a simplified incremental view of a very complex, multifactorial, and fast changing world, or a solution that only satisfies stakeholders in some contexts and not others.

The incremental introduction of sub-systems of the “big vision” is also replete with risks; risks which the UKeU platform suffered from. With aircraft design pilots and passengers tend to have a vested interest in a fully-working system in which mission-critical sub-systems are in place, e.g. body, wings, wheels; although the seats and cabin service may still need improving. With the aircraft, however, there tends to be little debate about mission criticality whereas the provision of say, a reliable assessment component, in a “world class” learning platform in the UKeU case became the source of intense internal debate. The NHS Programme for IT seems to be experiencing somewhat similar challenges.

As with UKeU the NHS Programme for IT needs to be perceived as much more than an engineering problem to be solved. In the first instance both needed to considered as complex social rather than technical systems. Social systems have ethos, cultures and traditions some of which may well clash with new cultures introduced to solve what the latter may perceive as a engineering problem to which engineering solutions can be applied. In the UKeU case we had the participating universities, the London-based UKeU non-profit company, and the technical developers who were projected by UKeU as “partners” but who later described themselves as “contractors”. That partner versus contractor relationship matters a lot when its comes to each stakeholder’s deliberations on, and responses to, perceived deviations from a specification and work schedule. The raison d’etre of a partnership is after all the sharing or risks and challenges, and the achievement of common goals rather than payment for completion of workpackages to an immutable specification. Again there are some echoes in the challenges faced by theNHS Programme for IT.

There are also echoes with UKeU in claims by some stakeholders of the NHS initiative of slippage in delivering what is perceived as being promised. As with the UKeU, and the British Airways Terminal 5, experience immutable target dates for systems going “live” can quickly become embarassments and cause a collapse of user confidence. At best, such situations result in “roll backs” to original systems or, should those not exist, chaos when the new systems don’t function as expected under stress. The key point here is the systems are not functioning as expected or required by the users (not necessarily the designers or software engineers). Users in the NHS case are the staff and patients and with UKeU it was the participating universities and their students.

Again differences of culture and so expectations can quickly come to the foreground. The IT specialists may argue that any disruptions are just part and parcel of the process of introducing new technology and “teething problems” are to be expected. However, as indicated earlier, when another stakeholder group perceive “teething problems” as missing or faulty critical functionality then the organisation will run into trouble because these stakeholders are expecting functioning and safe systems which are fit for purpose and not to be testers of individual components. Part of problem, which I also perceived with UKeU, was that analysts/designers and software engineers tend to adopt a highly planned graduated release perspective i.e. release zero leads eventually to release ‘xyz’ at some time in the future with functionality being built up over time. However, again, we perhaps need to adopt more of a bridge, building, or aircraft design perspective, i.e the bridge/building/aircraft needs to work as a system the first time with any “teething problems” or missing functionality not compromising the whole system or being a poorer alternative to what already exists elsewhere.

But let us return to the concept of homogeneity. Governments, of whatever hue, and IT contractors by their very nature would prefer that homogeneity was the steady state. If it is not then the inclination is either to assume that it does, or if not to make it so. In the latter case the result of a “one size fits all” approach can so easily be that human beings are expected to adapt to what the technology allows them to do. The result, as the Luton and Dunstable Hospital case (and as with the UKeU platform) suggests, can be an experience which is less effective and efficient than that which already exists. I’ve waked lyrical in many previous Auricle posts about questions of whether technology ends up serving humanity or whether we too easily accept that it is we who have to adapt to serving technological systems because those in authority declare it just too difficult and expensive to have it otherwise.

Adapting to a bridge that won’t take the weight, a building that will not stand, or an aeroplane that will not stay in the air just wouldn’t be acceptable but it gets more difficult when they sort of do the job they were meant to, i.e. the bridge works but sways in the wind, the building stands but is damp and attracts crime, the aeroplane flies but is uncomfortable for passengers, expensive to run and is noisy.

The second part of the BBC R4 programme Wiring the NHS states in its conclusion all the stakeholders want it to work and the investment in the programme is now so large that money looks like being flung at it until it does. The big problem will be in deciding at what point it will be perceived to be working better than the current situation. It would be a tragedy if the stakeholders never reach agreement that the massive investments in the system have been justified in light of the enhancements accrued, or if attempts at imposing homogenity actually degrade current provision in some cases. On a positive note the digital imaging infrastructure is generally agreed to offer a vast improvement, e.g. digital X-Rays and scans at the touch of a keyboard.

With UKeU the investments were not justified and it is interesting to reflect on whether decisions would have been the same were those who advised David Blunkett (then Secretary for State for Education) about the setting up of a national e-University to do so today.

The final echo I want to consider is the calls for public inquiry. With the NHS Programme for IT there have been calls made for open/public independent review To date these calls have been to no avail, e.g. motion 507 BMA Conference in July 2008. In the case of UKeU of course there was a Parliamentary committee inquiry. The HE company was ultimately dissolved. I believe its putative “world class” platform now lies on a virtual “dusty shelf” somewhere within JISC. Whilst after such expenditure it would be good to assume there would be some easily retrievable elements that could be of interest to the open source community the platform actually incorporated some proprietary elements and from my perspective it just would not justify further time and effort when the world has moved on and the learning management system approach is now no longer perceived as the panacea it once was.