Putting out the FiRe

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.