Sunday, January 27, 2008

Transforming government with technology

Over 150 people participated on Tuesday in our Government 2.0 event at the Houses of Parliament. Topics ranged from reducing the failure rate of big government IT projects through to the use of designers and "start-small" evolutionary alternatives to £20bn monsters like the NHS's National Programme for IT and the proposed National Identity Register.

Our panelists and audience had a range of perspectives, but I think they could be threaded together as follows. Politicians and officials need the right incentives to commission systems for the long term, rather than switching roles not long after a burst of initially favourable headlines and avoiding accountability when a system is deployed (Ross Anderson). They need to understand in much greater depth what citizens need from services rather than simply computerising existing business processes (Jerry Fishenden). Designers rather than engineers or management consultants are the best people to tackle this phase (William Heath). Political issues such as transparency and equity must be carefully considered.

Before commissioning systems, civil servants should first consider whether small internal programming teams could prototype solutions that evolve at much lower cost than traditional large-scale projects, especially by exposing government data sources like maps and house prices to mash-up designers like mySociety (Tom Steinberg). But when large-scale and/or critical national infrastructure solutions prove to be necessary, they must be carefully specified and project-managed in the manner of large civil engineering projects (Martyn Thomas). They must also be approached holistically as business change projects, with most of the budget going towards people rather than technology issues (Jim Norton).

If you want to find out more you can watch video of all of the sessions. Let us know in the comments if you disagree with any of the opinions expressed! Thanks again to all of our speakers; to our co-organisers POST; and to everyone who came along and contributed. Thanks also to Microsoft and Kable for sponsoring a drinks reception after the event.

2 comments:

William said...

Cheers Ian; pleasure to take part. William

Clive Blackwell said...

Concerning project initiation
Projects should not proceed until there is sufficient evidence about the benefits, costs and risk of failure. This would mean that many current and past government projects would not have gone ahead. Complex systems with novel poorly understood requirements should only be considered when the case is overwhelming and all steps possible are taken to minimise the risks. Professor Norton’s makes the point about the misallocation of costs to the technical side of problems and neglecting the business and personnel issues. I believe that more consideration should be given to the long-term cost of using a system, which usually dwarfs the cost of development. Methods need to be developed to estimate the hidden ongoing costs such as employees’ time wasted through inefficiency and the missed business opportunities of inflexible systems.

On effective oversight
It has been shown that the success rate of delivering the set requirements, on time and within cost asymptotically approaches zero as project size become very large. In these cases, an external independent panel of experts should provide realistic estimates of costs and benefits (at negligible cost compared to the cost of failure) using established metrics and benchmarks rather than accept the speculative benefits offered by the project sponsors. In addition, these systems often have unforeseen drawbacks that are not considered. Projects should be followed closely at all stages. The responsible parties should be fined for milestones that are not reached, which could be written into the contract and projects that appear to be failing should be abandoned early thereby minimising costs. If contractors cannot be found to tender for a project in these circumstances, it indicates that the marketplace considers it too risky, whereas at present the risks are hidden and only becomes apparent much later.

Concerning economic incentives
The department that initiates a project should bear the entire cost for subsequent failure, although they may be partially recovered from the contractors if they are responsible as indicated above. The effects on third parties as well as cost overruns should come entirely out of its budget. Allowing extra money for overrunning projects is economically illiterate in a similar to the subsidisation of nationalised industries in the seventies. If a nationalised organisation lost £X million then the government gave it an extra subsidy of £X million, which turns economics on its head where the worse the organisation performed the more money it got. If a law was passed that the full cost of data breaches and subsequent identity fraud had to be borne by the responsible parties (such as Revenue and Customs when they potentially disclosed 25 million personal records), government departments would have to consider risk more appropriately.

On scope
Government departments should be aware of their limitations. They might attempt smaller scale incremental developments with tangible benefits that are more in line with their rather limited abilities rather than monstrosities like the National Identity Scheme (NIS) whose proponents claim solve every problem known to man. Large complex projects such as the NIS and computerising health records have both unclear goals and unclear methods of achieving them. They need to projects that address real need, not build systems with a gigantic wish list of features with speculative benefits. For example, it should be a fundamental requirement that a hospital can find your notes, which would be usefully aided with the inexpensive use of RFID tags on patient records. Alternatively, the computerisation and widespread availability of medical records to hundreds of thousands of people has unclear benefits along with very serious risks of loss of patient privacy.

On changing requirements
Government departments need to be good customers and aware of their needs at the beginning and plan accordingly. They should set realistic goals and let the contractor implement them. However, it is not plausible or desirable as Professor Anderson asserts for any client to keep quiet for two years whilst a project is implemented. We need to know what the likely hidden cost of changes based on a clear analysis of data from previous projects. Changes should be properly costed including the additional risk, longer timescales and additional complexity and effects on other non-functional requirements, which are more important that the nice-to-have, but inessential features that could be added later if necessary.

Coping with change
Changes in the direction of large-scale projects should not occur by political whim. This suggests an incremental or evolutionary approach to a desired goal if changes are likely, whether because of technical or political uncertainty. Most projects of less than about 100,000 lines of code could use evolutionary development methods according to Sommerville in his introductory software engineering book, agreeing with Tom Steinberg. The classic waterfall model is suspect according to Fred Brooks (author of the 1975 classic Mythical Man Month about failures in software engineering, which is still relevant today) as we often do not know what the real requirements are until the system is built. It is very difficult and expensive to change systems late in a project and some requirements such as security cannot realistically be tacked on at the end.

C.Blackwell at rhul.ac.uk