What government IT can learn from cycling in London

Cycling in London requires agility. By that, I don’t mean being limber (although that does help). You need to be prepared to react quickly to changing circumstances and to revise your planned route as circumstances require.

Why flexibility is key

My commute takes me from Bethnal Green to Westminster. As any London cyclist will tell you there are plenty of alternative routes you could take depending on the time of day, weather, preference for quiet roads and whether you are on the inbound or outbound leg. For example, cycling down The Strand, east to west during the morning rush-hour is a waste of time. The traffic backs up from Trafalgar Square to Aldwych. In the evening, The Strand is fine in the reverse direction except on days where there is a protest taking place in which case you might as well use Victoria Embankment. You get the picture. Imagine if, before setting out, I decided the exact route I would take regardless of any of the conditions I came across along the way. That would be ridiculous and would be likely to make my journey unnecessarily long and maybe even dangerous. When dealing with unpredictability, being flexible is the best strategy.

The risk fallacy

For too long, our approach to IT in government has been similar to cycling along without any regard to road conditions or other vehicles. The punchline being that this is supposed to reduce the risk associated with the £16 billion spent on government IT each year. Massively complex, multi-year projects are described in extreme detail upfront in an attempt to lock down specifications. The procurement process has become so complex that it takes an average of 77 weeks just to get a supplier signed up. Once up and running, projects are delivered against these specifications with little regard to changing requirements or technologies. At the back end, assuming the project is not terminated mid-way, the inevitable change requests end up costing taxpayers a premium. Why do this? Sadly the incentives in the system encourage such behaviour. Those tasked with drawing up the contracts in the first place are encouraged to put as much detail on paper as possible for fear that this is their one and only opportunity to describe the functionality they need. Gold-plating becomes inevitable. Large IT suppliers are similarly incentivised to agree to massive contracts with the promise that if requirements change, they will get paid anyway. The size of the contracts also limits competition. There are relatively few players who are willing to spend the millions of pounds necessary to participate in the procurement process. Small and medium sized enterprises are priced out.

An agile solution

Next week we will be launching a report that outlines a new vision for government IT. Our research has focused on ‘agile development’ - a set of techniques originally used for creating software but now deployed widely in many leading companies and government agencies around the world. Agile turns the traditional logic on its head. Rather than specifying detailed requirements in advance you let specifications evolve over time. Functionality is built in from day one, with users involved continuously rather than during a ‘test’ phase at the end. Flexibility is valued over following a predetermined plan. It’s the IT equivalent of cycling with your eyes wide open, and being fully prepared to change direction when necessary. Wise advice for cyclists and chief information officers alike.