PREAMBLE

  One of the items in the Terms of Reference is as follows:

—  Current progress on the development of the NHS Care Records Service and the National Data Spine and why delivery of the new systems is up to two years behind schedule.

  The progress of the systems can be determined only by a detailed examination of the initiation documents; the specification of requirements, the system design, the implementation plan and much else. The answer to the question is that the two years was probably a political number based on thin documentation. This document is an attempt at providing a solid basis towards eliciting a more reliable picture of the system(s), in particular trying to predict initial delivery times and costs as well as long-term follow-up costs.

1.  THE UNDERLYING QUESTIONS

  At every step of the way the underlying questions are:

—  Who was the project owner?

—  Who were the members of the steering group that created the specifications?

—  May we see those specifications?

—  May we see the resulting system design?

—  Who was the designer?

—  May we see the project plan?

—  Who was the project manager?

—  May we see the resulting cost estimate?

—  Who approved the estimate?

2.  FEBRUARY 2002

  At the Downing Street meeting, and attended by David Bennett, McKinsey, Andrew Pinder, the Delivery Unit, Lord Hunt, Health Minister, and John Pattison, NHS Director of Information, all apparently agreed that the NHS could and should be radically transformed by IT.

—  What does "radically transformed" mean?

—  To what problem was the radical transformation the alleged solution?

—  Were they not aware that throughout the NHS, from the GP's surgery via the hospital booking systems to the individual technical equipment in the wards and operating theatres the computer had already become ubiquitous?

—  Were there any medical professionals present? Doctors, nurses?

  In particular, during the meeting the question was asked, how long will this take? Apparently John Pattison said three years. This answer was unacceptable and he reduced it to two years and nine months.

—  What was meant by this?

—  What made John Pattison think it should take three years?

—  What enabled the meeting to change the estimate to 2.75 years?

—  What was the meeting's estimated cost?

—  If the question wasn't asked, why wasn't it?

—  Whose job would it have been to answer the question?

—  Why did that person not volunteer the question unasked, or require that an answer be produced before making a decision to go ahead?

—  Was this far-reaching decision concerning computers made without a single computer-competent person present?

3.  A FEW WEEKS LATER

  John Pattison produced some sort of blueprint for the project in the spring of 2002.

—  What did the blueprint consist of?

—  A specification?

—  A design?

—  An implementation plan?

—  A cost estimate?

—  What was this based on?

—  Who was intended to be the project manager?

—  Was he or she involved in any way in creating the blueprint?

4.  COST ESTIMATES

  It was reported that at about that time, early 2002, the cost estimate was some £2 billion but was increased in the first draft of the Pattison blueprint to some £5 billion based on what seems to have been a fairly realistic estimate of the true nature of the project. But when the report was published this estimate had been deleted.

—  What was the published version of the blueprint cost estimate? Was this the £2.3 billion figure reported in the press?

—  Who removed the £5 billion from the draft?

—  Why?

—  To whom did John Pattison protest at this removal?

5.  A FIRST MILESTONE

  It has been reported in the press that a "full national health record service" would be delivered by Christmas, 2005.

—  What did this service comprise?

—  Who was the project owner?

—  Who was the project manager?

—  What was the cost estimate?

—  Who approved it?

—  What, if any, penalty clause was included in the contract?

6.  SEPTEMBER 2002

  It seems that the project was handed over to Richard Granger, a Deloittes consultant, in September 2002. Later he became head of the agency running the programme, Connecting for Health.

—  Was Richard Granger the project manager?

—  If not who was, and what was Richard Granger's role?

—  To whom did Richard Granger report? And the project manager?

—  What control over the project did the NHS authorities have?

—  In what was this control vested?

—  How closely to the plan did the project keep? What time and cost overruns were there?

—  How many designers/programmers were involved?

—  What documentation was produced; implementation, training?

—  Over the next two years how many senior responsible managers were there for the project?

7.  MAY 2003

  Bidders for what seems to be a changed contract splitting the project over five regional monopolies were issued a 500-page draft specification with a five-week deadline for bids to do the work.

—  Who wrote the specification?

—  Is it the intention to produce five different systems?

—  If so, to what extent can this be called a single national system?

—  If not, what steps are being taken to ensure conformity between them?

—  To what extent were medical professionals involved in the decisions?

—  What other consultants were involved in the process?

—  Was five weeks, at 100 pages per week, considered sufficient time in which to provide a thorough and reliable basis for a contract?

—  How does this figure compare with other major computer contracts?

—  To what extent did confidentiality clauses prevent public audit of the contracts?

—  How many of the 176 acute hospital trusts were due to become users of the system by the end of 2006?

—  How many actually did become users?

—  Who carried out the acceptance tests?

—  Against what specification?

—  How many people needed training?

—  Who wrote the documentation?

—  How much did each installation cost the user?

—  Where did the budget come from?

—  What arrangements are there now in place to report problems? Hardware/software?

—  Who has the responsibility for fixing them?

—  What arrangements are there in place for processing requirements for improving the functionality of the system?

—  How much has been budgeted for continued support and development of the system?

—  Are the users satisfied with the system?

8.  COST ESTIMATES

  It has been reported in the press that the £2.3 billion figure quoted in section 4 increased to £6.2 billion, and that the two years nine months had been increased to 10 years.

—  Is this true?

—  What is the reason for this increase?

—  On what is the current time estimate based?

—  What is the current cost estimate?

—  How many major systems that have just come on stream today were specified in 1997?

9.  CLINICAL LEADERSHIP

  At some point there was a professional leader of the project, by name Professor Peter Hutton. However, he left the project—which should mean that he is free to answer questions and express his opinion.

—  Who appointed him?

—  To whom did he report?

—  What was his remit?

—  Its duration?

—  Who was in his team?

—  What happened to the project during his tenure?

—  Why did he leave it?

—  Who replaced him?

10.  POLITICAL LEADERSHIP

  Someone who might be able to shed some light is Richard Bacon MP. He is quoted in the press as saying that a set of contracts had been signed "before either the government had understood properly what it wanted to buy or what the suppliers had understood what it was they were expected to supply".

—  Was he allowed to see the contracts?

—  Who has he talked to about the project?

—  Would he be willing to talk about it?

—  In particular what is his current opinion of its health?

11.  COMPANIES INVOLVED

  It would be interesting to review the roles played by some of the participating companies and their associated consultants. Underlying the discussion is the impression that they stand to make a lot of money and are not being tightly controlled.

iSoft

  iSoft is a software company who had promised to deliver a package called Lorenzo by March 2004. This was supposed to be the computer tool for the major companies to use for their contracts for the 100 acute hospitals. By early 2006 the package had not been delivered. Instead a new date of 2008 was set.

Questions for iSoft are:

—  Why was Lorenzo delayed?

—  What effect did the delay have on the work of its intended users?

—  What is the probability of its being further delayed?

—  What penalty clauses are there in the contracts for its delivery?

—  How are the intended users going to honour their contracts without it?

BT

  BT have the contract for the London area under contracts totalling some £1 billion. So far only about £3 million have been earned for delivery. Some 47 total systems were due for installation by March, 2007. So far only one has been delivered.

Questions for BT are:

—  Why has so little been done?

—  Why did BT replace their collaborating company, IDX, with Cernet, (both American), and could this shed any general light on the problem?

—  What is the revised plan for spending and delivery?

—  May we see the original baseline and the current version of the plan?

—  To what extent has BT been paid by the NHS for systems yet to be delivered?

Accenture

  Accenture have the contract for the east and northeast. It seems that when Lorenzo failed to materialise Accenture repeatedly offered to fulfil its contract using other companies' software but the proposals were rejected by the NHS as this might have bankrupted iSoft. As a result Accenture decided to withdraw from the project, handing their contract over to Computer Sciences Corporation (CSC), an American company apparently under investigation for boardroom corruption. As things stand an American company now has the contract for some 60% of the contract.

Questions for Accenture are:

—  What reasons did Accenture give for their withdrawal?

—  What light has Accenture shed on the technical and financial problems of the system?

—  How much money had Accenture lost on the project before withdrawing?

—  More generally, with the experience gained by Accenture to what extent could they advise the NHS on the future of the project?

12.  USER TRAINING

  At some point during the project implementation phase training needs to be carried out for all the expected users. The timing is a bit of a balancing act. It cannot start until enough of the eventual functionality is in place to ensure that the trainers understand their job and have been able to create the necessary documentation; the trainers themselves need to be trained. On the other hand it must be in time for the users to be ready for delivery. The training phase of computer projects is notoriously shambolic. It is as though each computer project is a brave new adventure without anyone remembering what happened last time, and how we made the users so frustrated. It should also be mentioned that the cost of training sometimes dwarfs that of the implementation. Ironically, this is usually when the training is properly scheduled, budgeted and carried out and therefore computable. On the other hand, the cost of not training must exceed that of training but is never made known.

—  May we see the training features of the contracts?

—  How much time and cost has been allocated to the training?

—  Have all the potential users been identified and informed?

13.  POST DELIVERY COSTS

  A newly delivered system is always a Trojan Horse, except that it contains two armies rather than the one; the inevitable bugs, however carefully the quality control procedures were carried out, and the inevitable discoveries of the missing and inadequate features, however carefully the system was designed. Each requires considerable expenditure of money over an indefinite period. To what extent has this expenditure been discussed and provided for?

13.1  Quality control

  Standard practice in the computing industry at the initiation of any project is to include in the contract a detailed specification of the testing regimen and the consequent post-delivery maintenance procedures; a project is incomplete without a guarantee of smooth functioning. Normally the procedure comprises an internal evolutionary sequence of testing starting with that of each (small) feature as it emerges from the programmers, systematically integrated with neighbouring features until it appears (to the implementation team) to function well enough to begin to involve the potential users. We call this the alpha test phase.

  This is followed by the beta test in which friendly customers subject the system to real life situations using field data. This phase also tests the effectiveness of the training given by to the nurses, lab technicians, doctors etc.

  Quality control includes the retention of the project teams to solve all problems encountered. The best people to solve problems are those who created them. Bringing in new people at this stage involves unacceptable delays in their familiarising themselves with the detail.

—  How much time and cost has been estimated and scheduled for the quality control procedures?

—  Have these been adequately provided for in the contracts?

—  What do they amount to in terms of both time and cost?

13.2  Acceptance testing

  The time when the computer salesman dropped a cardboard box on the customer doorstep and rode swiftly over the horizon is long past. Not a penny must be invoiced or paid before a system has survived a thorough acceptance test involving all concerned; users, trainers, programmers, designers, lawyers—and perhaps even an occasional patient. Acceptance testing must involve real life use of the system; Monday morning queues of patients.

—  How much time and cost has been estimated and scheduled for the acceptance testing procedures?

—  Have these been adequately provided for in the contracts?

—  What do they amount to in terms of both time and cost?

—  To what extent do the contracts provide for the retention of the project teams until the systems have been accepted?

—  What penalty clauses are included in the contracts?

13.3  Continued maintenance (evolution)

  By maintenance we don't mean that systems get rusty, we mean that bugs are always present, even after acceptance, and the users inevitably discover weaknesses that need redressing as well as good ideas for further improvement. The procedures for reporting problems during quality control and acceptance testing must remain in place indefinitely. Computer systems, once installed, remain in place for years until replacing them with significantly better versions is a better option than continuing to evolve them.

—  What thought has been given to the continued evolution of the system?

—  At what budgetary level?

—  Has this all been prescribed in the contracts?

14.  SYSTEM DELIVERIES

15.  CONTRACTUAL VALUES

16.  VULNERABILITY

  All computer systems fail; it is impossible to guarantee the 100% continuous operation of any agglomeration of software and hardware. Computer programs always contain bugs because there is no foolproof method of finding them in the first place or theorem to prove that they have all been fixed at any time. And computer hardware, both central and peripheral, as with all physical things, breaks down from time to time, despite the most stringent maintenance regimen. Today's computer is a very complicated system of literally millions of interacting components, most of them invisible to the naked eye. And the bigger the system the greater its vulnerability to the hazards of interactivity; the probability of failure increases with some high power of the number of components. Moreover, large computer systems imply a high level of importance; you would not try to create a large single system if there were no good reason for doing so. They must be attempts at solving very serious problems; problems involving large amounts of money, goods or people. Such importance must in turn imply a need for extremely high levels of reliability. Most such systems can undoubtedly tolerate periods of malfunction; we can usually wait a while for a bank transaction to take place. But systems involving human welfare and life support must work continuously and reliably once they are turned on; there can be no toleration of interruption in computer support any more than interruption of blood supply or anaesthetic.

—  Has a risk assessment been made of any component of the contracted systems?

—  How much effort, in terms of man hours and cost, is being assigned to solving the problem of reliability in the contracts?

—  What is the maximum delay acceptable in the contracts due to system failure?

—  What are the envisaged consequences of system failure?

—  What plans have been made to revert to backup systems in the event of system failure?

17.  SUPPORT

  Intrinsic to the question of vulnerability is that of support. Most medical computer systems seem to be delivered by specialist companies who also have the contract to support the using organisations. (This is much the same for schools.) Whenever anything goes wrong the user requests the support company to fix the problem—and they need it done now! But it is never done now. It cannot be. There is always a delay, sometimes as much as a week, during which time the user staff has to keep things going as best it can. The problem facing the support organisation is that it is difficult to provide a satisfactory level of support and make a profit. Or it is difficult to get the user to pay the price of a level of support that they really need.

  And in addition to the question of cost is that of proximity, or lack thereof. You are far less vulnerable if the support person is only a few minutes away; even in this day of electronic conversation, in times of crisis face-to-face talk is still the best, amplified by printouts, screen pictures, sketches etc. A profound problem with a centralised, monolithic system is that it is ipso facto remote from almost all its customers' premises. If things go wrong at the centre they can be fixed at the centre. No need for site visits. But if things go wrong at a remote site what arrangements might there be for local support?

—  To what extent has the support problem been analysed within the NHS?

—  Since most NHS computer systems are still locally generated has any attempt been made to aggregate support costs to the national level?

—  Is there a single system for logging faults, waiting times, patching programs etc?

—  Are there standard contractual agreements for levels of support?

—  What are the current prices for levels of support?

—  What is the total annual NHS computer support budget today?

—  What would it be within a monolithic system?

—  Are support costs part of the current financial figures?

18.  A QUESTION OF COST

  A final thought concerning cost is that of the human cost vs that of the hardware. Hardware is getting cheaper by the day, and always has done. For £20 you can buy as much computer memory today as there was on the entire planet not so many years ago; a billion bytes contained in a 7.5 cm long "USB stick". At the same time people costs have steadily risen and will continue to do so. Out of a £1 billion contract well over half must be the "peopleware", the cost of system designers, programmers, managers, writers, trainers etc. Suppose it were only a half. At, say, £50,000 per person per annum, £500,000,000 would pay for 10,000 people. You can run an army of that size, but it is very difficult to manage a deeply integrated technical project of that size in which so much information has to flow, even if you can find enough technically competent people. It is simply too big, and that is the reason why they have tried to split what is supposed to be a single entity into five, the irony being that you then have five entities created by five disparate teams who cannot help but produce incompatible versions. But even 2,000 people is a mighty software horde. Where would they all sit?

—  How many people are employed on the NHS system by the contracted companies?

—  How large are the individual groups of programmers etc?

—  What is the turnover picture? Rates of hiring and training new people?

—  Are there problems of finding people of adequate calibre?

—  Of the total to date, what is the ratio of people costs to equipment costs?

19.  CONCLUSION

  This is a very short version of a survey of the NHS system. Before any reliable recommendation could be made a much more thorough investigation would be needed. But who would do it? How cooperative would the current participants be? How long would it take? Meanwhile the contracted work would carry on and more money spent. The obvious fear is that good money would be spent trying to rescue bad. And as time went by it would be ever more difficult for anyone to call a halt. With the growing investment of time and money, and the inevitable changes of project owners and managers, computer systems take on a life of their own.

  One very important feature of this system that has not been mentioned here is its monolithic nature. Although the contract has been split geographically and by provider, it is nevertheless a single endeavour; it is a national program. Moreover it does not appear to have wide support from the PCTs or the hospitals. In addition to the vulnerability of large monolithic computer systems, the massive and possibly life-threatening consequences of computer breakdown, its national nature means that local initiative would no longer be tolerated. Removing local enterprise would have a demoralising effect on the NHS, adding to its current malaise.

  However, I hardly think it necessary to carry out an investigation. To an experienced computer person this system bears all the hallmarks of massive failure. It is simply too big to design, plan, estimate, manage, implement, verify, install and keep alive. It can only drain the NHS of incalculable amounts of money and frustrate the day-to-day work. The long-term consequences of the project cannot even be guessed at. It would take a brave man to put an end to it today, but it would need a veritable hero to do so five years hence. But if it is allowed to continue the cost of the initial installations could easily reach £20 billion and more, and the annual continuation cost of supporting the installations could be several billion. And somebody might die.

  Instead, write off the one billion spent so far and let initiative flow locally from the bottom where it is most likely to be competent; let the mistakes be limited and recoverable. At the same time create a small monitoring group at national level with the remit to keep us informed of what's going on. Somebody, somewhere might have a good idea they'd be happy to share.

Norman Sanders

26 March 2007