Putting out the FiRe

22 September 2011

Another week, another example of a big government project failing at scale. This week, the NHS National Programme for IT is back in the news, but there’s also a blazing row over who’s to blame for the failure of the fire service programme, which reportedly cost taxpayers almost £500m.

Back in 2004, the Government decided to replace the control room functions of 46 local Fire and Rescue Services in England with a network of nine purpose-built regional control centres using a national computer system. Their intention was to ensure that the IT and other communications systems could be better co-ordinated at times of crisis, particularly with the growing threat of terrorism or in the event of a natural disaster. In a classic symptom of flawed project management, the Public Accounts Committee pointed out that the responsible department excluded the end users from decisions about the design of the control centres and the proposed IT solution.

Last year, we collaborated with the Metropolitan Police Service and the Home Office, to test out whether a radically different approach to delivering on big policy commitments could add value. The project addressed a long-standing issue that the public sector has traditionally struggled with: sharing information on known identity fraudsters. As in the case of fire services, resolving this issue requires coordination across a range of different organisations and at different levels in the public sector.

Rather than trying to set out a grand plan for wiring up numerous different systems in numerous different organisations, the project followed an ‘agile’ approach. ‘Agile’ might sound like fancy jargon but at its heart it is simply about applying a set of principles.  Firstly, projects should be ‘modular’. This involves splitting up complex problems and projects into smaller components and portions of functionality, which can then be prioritised.  Secondly, they should be iterative, which involves trialling in short iterations, receiving feedback and learning from mistakes. Thirdly, the project needs to be responsive to change with regular prioritisation discussions. Finally, the project needs to have users at the core. In an agile project, users or business champions are embedded within the project team. Agile projects are about becoming much more flexible, responsive to change and innovative. Early delivery of core working functionality is the priority.

In the case of the fraud-prevention project, the team employed a modular, iterative and responsive approach that involved the users throughout. Instead of attempting to solve all the problems at once, it was agreed that the most immediate priority was to create a database that the Met could use to handle the increasing amount of data it needed to store and to assure the quality of the data. The system was also built so that more advanced functionality, including the potential for other departments to interact directly with the system, could still be added in the future. The users and departmental sponsors were able to make informed changes to the prioritisation of functionality as the business needs shifted and some elements became more or less urgently required. The initial modules of the system were successfully delivered and are now being used by the Met.  And now, users and departmental sponsors can decide on the next areas of functionality to be added – and, no, they will not be the same as they might have been when the project was first instigated!

The current Government is quick to blame failures on the previous administration but how do we know the same problems won’t happen again in the future? Before the fire spreads the Government needs to start taking a far more agile approach to delivering its policy commitments.

Share this post:

Comments (2)

  1. David Chassels on 23 September 2011 at 7:13 pm

    Hi Jerret
    How about you help Government become the intelligent buyer. Francis Maude spoke wise words when he said saying that open source would be encouraged where cost is “equal to, or less than, the lifetime costs of proprietary software”. So who makes the call?
    Now Government just need to become the intelligent buyer – a point made by the PASC in their recent report on Government IT. So if they are to avoid mistakes of past then it is vital they understand the underlying technology, what works efficiently, delivers exactly what is required and is virtually future proof for change. It’s not rocket science but who is responsible?

  2. Fire Alarms Kent on 27 September 2011 at 9:14 am

    Whilst it makes sense to centralise control room functions more it is worrying that any response to an act of terror may in fact be slowed down considerably. Having said that the London bombings response was far from perfect so this may actually be a good thing.

Tags:

Blog: Permalink