Government IT: it doesn't have to be so hard

The Institute for Government recently published System Error: Fixing the Flaws in Government IT — a comprehensive and much-needed attempt to catalogue why government struggles so consistently with IT delivery. At 101 pages, it requires a reader both genuinely interested in the subject and in possession of considerable time. Having worked in software delivery on some of the largest government IT projects in the UK, there is something to add.

The IfG report makes many valid points: the problem of long procurement lead times, over-specification of software, and over-use of consultants that widens the gap between business users and system developers. It then dives largely into the well-worn territory of agile methodology. Agile is important — it deserves attention in government as it does elsewhere — but it may not be the complete answer the report implies.

The report seems to miss one vital point, something so inherent to the nature of IT that it rarely receives sufficient attention, yet may be the single biggest reason why most large projects fail: they are too large.

Because these projects are so large, they try to do too much at once. That 'once' becomes a year, or two years. Consider how much technology changes in that time. By the time many IT projects are halfway to their delivery deadline, the world has moved on so substantially that requirements continue to grow. The project becomes a long-running change management programme with shifting goalposts and expanding budgets.

The answer is straightforward: instead of going for the biggest and best in a single pass, plan and execute many smaller projects with delivery timelines of no longer than six months. By all means spend more time defining the business need — whether that is enabling people to log 999 calls online, book a hospital appointment or fill a repeat prescription. But if the solution requires a multi-million pound project with more than a year's delivery schedule, it is simply too large and will not deliver.

For large projects with large definitions, break them into sequential or parallel projects that can each be delivered quickly. Make agility inherent to the structure rather than a management layer superimposed on top. A bank can implement what is described as a 'large project' globally, but will only do a small number of things at any one time. The problem with size is always people and time: the bigger the project, the more stakeholders need to sign off, the slower decisions become. Keep the project small. Keep the team small. Smallness creates the conditions for agility — not the other way around.

Any large project, by its very nature, is not going to be agile, regardless of how capable an agile advisory team the Cabinet Office assembles. What matters is keeping the scope of each piece of work genuinely manageable. That is the reform government IT actually needs.