Thursday, September 09, 2004

Leap of Faith

I like Aidan's post on the Leap of Faith very much.

Dear Aidan, you have hit the nail (or several of them!) on the head. I am currently wrestling with how to express those bullet points you just requested. Here are a few thoughts which I hope push us in the right direction:

1) Bill's point is that the right solution to any problem has to be invented. For example, although Newton's Laws of Motion seem obvious now, nobody grasped those three simple propositions in all of human history until he did. It took unparalleled genius to see what now looks obvious.

2) Bill knows that this process of invention is mysterious. He refers to the way in which ideas come across "the gulf of human intellect". He refuses to discuss where they come from, but concentrates his discussion on the process of testing them after they have been obtained, at the lowest possible cost, to see if they will solve the problem.

3) The project management community refuse to accept that invention lies at the heart of solving any problem which includes novel elements. Everything they do assumes that building systems is just like building cars on a production line. This is only so if there is no complexity, but none of them are trained to spot the difference between "vanilla" projects and "complex" ones.

4) The root cause of the Universal Scenario of Project Failure is a failure to successfully identify the requirements for the system. From my experience, I can easily tell the difference between the "vanilla" elements of NPfIT and the "complex" ones. I already explained which is which in my posting "NPfIT" to this blog at 11:07 on 9th August 2004. There is a simple checklist of "danger signs" which can be applied, but these are generally ignored, as they have been in this case.

5) Where there is complexity, Ashby's Law of Requisite Variety says that it can only be addressed by two methods:

a) Reduce the variety of the system to be managed, or

b) Increase the variety of the management of the system.

6) The NPfIT management have assumed that they can ignore the complexity inherent in the Care Records System (CRS). When the GPs got stroppy about not being consulted, they appear to have been surprised by this, although anyone with half an ounce of sense could have seen that this reaction was bound to happen.

They have reacted by creating a body to "listen to them", but it is obvious that this is a superficial exercise, since it is already too late for their feedback to be incorporated into the system design. The real purpose of this is to "listen" (but not even start listening until November), then claim that every effort has been made to be "reasonable", and apportion some of the blame to the GPs for the eventual failure of the system.

Richard Granger, the head of NPfIT has already suggested that the only reason the project might fail is because of the negativity of the press, public and members of the medical profession.

7) This approach could be called the "Gordian Knot" approach to complexity. If you do not know the story of the Gordian Knot, you can check it out at:

http://www.geocities.com/~jlhagan/fineart/gallery3.htm

The basic approach is "this looks very complicated, so I will apply violence to simplify it". This works as long as the applier of the technique has enough superiority in "fire power", but at the expense of a lot of "collateral damage".

8) A better approach is to embrace the complexity and improve the understanding of the issues so that the new system can manage all the necessary complexity. This approach has a few key requirements:

a) The ability to recognise complexity, rather than assuming that "business as usual" can solve all problems.

b) A willingness to learn whatever it takes to understand the realities of what is being dealt with. This requires great attention to learning about how things work in reality, rather than making unwarranted assumptions, based on no evidence. This is impossible without field-work, which involves watching what people actually do, not what they believe they do.

c) Technology which is designed to support the process of learning.

d) Methods of rapidly validating possible solutions, so that candidate systems can be tested to destruction at low cost, before wasting resources on rolling out big systems which then fail.

9) One of the most absurd fallacies is that it is possible to design IT systems based on asking people what they want.

Last year, I visited the national office in an East European country of one of the world's most famous fast-moving consumer goods manufacturers. I was working with the head of IT for several countries in the region. He complained that the company had spent millions of pounds on Business Intelligence systems for the Finance Department. Months after these were installed, he discovered that nobody was using them. When he enquired about this, the finance staff eventually admitted that what they really wanted could be done with five Excel spreadsheets!

The NPfIT system could have been a great success, and it could have been delivered for no more than 10% of the budget which has been allocated for it. But to do so, the approach would need to be quite different, based on openness, making use of the knowledge already available in the best of the IT systems already in use, and a recognition of the fact that nobody can understand the NHS without studying it first.

The current approach is based on the assumption that the application of bullying by "the experts" and intimidation of dissenters can solve any problem. Unfortunately, the failure of this project is likely to be taken as evidence that the NHS cannot be reformed, and used as an excuse to dismantle it.

No comments: