What CfH Could and Should Learn from Defence Procurement

From Nhs It Info

In November 2005 e-Health Insider published a letter of mine saying 'what a pity people in CfH had not sought experience from the Defence field'. The text below is based on the reply I gave to a doctor who asked me to be more specific regarding the lessons that I had in mind.

Malcolm Mills, 11 Oct 2006

The magic bullet is the employment of high calibre and properly experienced people in pivotal posts in the programme management organisation. In the UK, US and Europe, much basic and operations research has been carried out in Defence, and many many volumes published, on the development and procurement of IT-based systems and services in the years since computers were first used towards the end of the 2nd WW. Some fortunate people (yours truly included) have been lucky to have been involved with these developments for some of this time. Unfortunately, many of the cognoscenti have not practiced outside of Defence and take their knowledge into retirement, and the grave. Little encouragement is given or interest shown for them to pass on to other communities the basics of what they have learned. A few fortunate ones do look over their shoulders from time to time and when they do, they see much in common.

Why should this be? Well, although the health environment may (appear to) be different, much is similar. And of key significance, critical programme 'building blocks' are the same: 'people are people' (whether they wear a military uniform or a white coat) -they have the same two arms, two legs, one brain, can be trained, have the same basic cognitive, perceptive, neurological and social, behavioural characteristics etc etc. And the basics of 'computers in defence' are the same as the basics of 'computers in health'. They are constructed with the same physics, same von Neumann architecture, same EM theory, logic, Shannon's Laws, etc., etc.

Years ago when software was recognised to be a pivotal and evolutionary issue in Defence, we agreed the need to pursue a 'software-first approach' in procurement in an attempt to get software 'off the critical path' of the programme timescale. In addition it became obvious you can design, and redesign, the (software) machine (not that easily to be sure - software is brittle rather than flexible) but you cannot redesign the human being (at least not in project timescales!). To be sure people can and should be trained to perform new tasks and procedures but their basic characteristics must be allowed for and cannot be redesigned to any great extent. (People are God given, machines are man given).

With these thoughts in mind, we now realise the delivery of these systems and services requires not just a software-first approach but a more evolutionary and radical emphasis called: the socio-technical approach. Orthodox technological determinism, with its classical engineering, intellectual, legal, financial and contracting baggage is not man enough for the job. The process must be changed (modernised!) to suit the needs of the new era.

Requirements are the crItitical item. Who are the End users, who are users, who are operators. How are (output) requirements elicited from them. Do they do it themselves or will surrogates be used. Who has the authority to verify the requirements. How and in what language will they be specified. How will they be documented and accounted for. Will software prototypes be used to aid the requirements process. How are they communicated to suppliers. Are they testable quantitatively and/or qualitatively. What role for subjective assessment. Can they be validated in a trials programme. What about safety requirements. How does one specify output requirements. Will requirements be put under configuration control and linked to issued software versions and contract. Who will do this. What procedures will be used to manage change in requirements. How will risk in over grandiose requirements be assessed. How will requirements be downsized to be realiseable within project costs and time-scales. How are requirements for 'business' interoperation between cooperating institutions, organisations and specialist communicated elicited, verified, validated, changed etc etc. How are requirements then tuned to legacy functionality and the characteristics of new 'off the shelf' software from UK or elsewhere.

Tackling User issues in Defence has been a major challenge over the years and continues to be so to this day. It is an intractable problem and needs deft management by people who know what they are doing. And at last those at the top of the MoD seem to be aware of this issue. Military users are now taking responsibility for the ownership of their requirements.

Notwithstanding the requirements problems in Defence, it probably has fewer specialist user stakeholders than in the Health user community, recognising the latter includes requirements for a very diverse patient community as well as clinicians, managers etc. This must or should be recognised as the Big Issue, more so in Health than today in Defence.

Yet from the way CfH is being progressed, this does not seem to be the case. Classic Public Sector Procuement is geared to the purchase of physical goods eg widgets, machinery, bridges and roads. To put it crudely, it is geared to the assumption you can specify, a prioiri, in objective testable quantitative and unchanging terms what you require. IF this is true, then it follows specifications can be put out to competitive tender and terms and conditions of contract awarded on a fixed price basis to a contractor who accepts all the risk for delivery. Finance underpinning the contract is geared to the provision of the good alone and follows the premise that beneficial capability comes from the operation of the physical good. Any roles people might provide in delivering the overall capability will be funded from existing operating budgets. Savings in costs in more efficient operation are also expected.

BUT we know from defence experience the key risk and cost of providing capability in these kinds of application concerns the risk and cost of the people who use and operate the system - their salaries, benefits, development of new user procedures, training in new procedures, recruitment, organisational restructuring, locums etc. The overall costs of getting the people 'right' in the procurement and operation of IT- based business services can be 5 times the life cycle costs of the equipment. In Defence, much effort is underway to trade-off and optimise the costs of different lines of development (LoD's) (people, training, safety, equipment etc) early in corporate planning, and well before contracts/suppliers are even considered. In this context, there is an opinion HM Treasury should re-examine the overtly technical (and not socio-technical) emphasis given in its Green Book (Appraisal and Evaluation in Central Government) - the appraisal guideleine used in the Gateway reviews of the OGC/Gershon process for large investments in the Public Sector.

Interoperability. The emergence of on-line networks has heralded a shift from services operating in isolation to services being interconnected both within and between organisations and communities. The first major examples in Defence occurred in the late 50's onwards with real time computer-based (wireless) networking of fixed radar installations across continental land masses, and between ships, submarines and aircraft at sea in mobile integrated command and control systems. These examples networked military staff and weapons systems across different Services (eg Navy and Air Force) and between differing Nations (eg UK and US). Many lessons have been learned from this experience and are being applied today in the 'joining up' and integration of many of the previously stove piped services in the administrative, logistic as well as the operational defence arena.

The enabling technology initiating this pan-organisation change is the new £4B Defence Information Infrastructure (DII) backbone - the defence equivalent of the NHS CfH IT initiative. Amongst the many interoperability lessons learned to achieve seamless interoperability across disparate organisations are the following: need for agreed joint purpose, the importance of the human factor, agreed functional requirements, cultural/ organisational compatiblity, team working, development of common, and new, business procedures and rules of operation, semantic/ lexicon understanding and awareness, extensive training and cross organisaton trials AS WELL AS technical issues such as data dictionaries, communications protocols, message standards, electrical, physical compatibility etc.

The true costs of achieving seamless interoperability involve not only the costs of the technology (included in the capital expenditure) BUT ALSO the more significant user costs hopefully adequately provisioned from the many different operating budgets of the participating organisations. Included in user costs should be the need to establish, for example, a minimum but authoratitive coordinating layer of management to fund and develop the necessary business operating procedures and rules of engagement deemed necessary for organisations to achieve the needed degrees of joint working.

This country has spent many many £B of Tax Payers money on failed and successful IT-based projects in Defence. Much has been learned but most is kept 'in the box'. We shall have to wait and see whether the National Audit Office, in its new inquiry into 'IT successes in the Public Sector', has the wit and experience to include the lessons learned from Defence in its report.

I hope this provides some indication of the kind of lesson now well learned. Inevitably because of the nature of the Defence beast, mistakes as well as successes will continue to occur. But from what I have read, it does appear to me the planners of the NHS/CfH programme are unaware of the relevance of the Defence experience. That's quite a loss for we patients, clinicians and tax payers.

 Malcolm Mills is a graduate of the Royal Military College of Science,
 Shrivenham and London University. Following a general list career in the
 Engineering Branch of the Royal Air Force in mostly software-related
 appointments, Malcolm became a Principal in the Civil Service Science Group as a
 project manager for Royal Navy surface ship combat systems and NATO
 real-time data exchange networks before leaving to join Software Sciences Ltd
 (now integrated into IBM Global Services) some 20 years ago. He then
 joined Gregory Harland Ltd in January 2000 to focus on the changing role of the
 user in the evolution of interoperable corporate information systems,
 one of his professional interests. Malcolm is a Chartered Engineer
 and Fellow of the Institution of Electrical Engineers. He has been
 an active member of the Electronics Industry Trade Associations and
 work of the Defence Scientific Advisory Council. He retired this year (2006).