In Short: Why Government IT Projects Go Wrong

I have yet to see any convincing evidence that government IT projects go wrong significantly more frequently than similar (and this is a key word - similar) commercial IT projects. This is, I understand, not much of a defence and because these projects are undertaken with public money and in the public eye I am not seeking to mount such a defence.

Many government IT projects are large, with complex sets of stakeholders and are intended to secure change in processes and work practices across the public sector. They operate in a changing public policy context. This makes them very difficult to realise, but it is important to understand that these are not necessary features, they result from decisions. Generally, poor decisions. In other words, the scope and environment for these systems could be different if the key policy actors chose them to be different.

The deployment of good software development practice and experienced project management, are sound measures but are unlikely to lead to significantly improved outcomes on their own. I argue, and I believe the evidence supports me on this, that it is governance which is the critical determinant. By governance I mean the allocation of decision rights and accountabilities. It is well known that good governance is associated with high performance in corporate settings and poor governance with impaired performance. Government projects are - ironically - persistently associated with poor governance: the usurpation of key decision rights by those ill qualified to exercise them; and, making people accountable for matters that they are unable to affect.

Because many of the development and project management mistakes that are made, and widely reported, in public sector IT projects, are very basic it is assumed that technical competence is at issue. I am not persuaded that this is the case. Rather, those charged with project execution are unable to deploy best practice, or even basic good practice, because they are forestalled by decisions made within the larger governance processes. When a project has been chartered wrongly, given the wrong timeline, when only a subset of the stakeholders are empowered, when the budget and business case process are wholly disconnected from the project requirements, no amount of good development practice or sophisticated project management will set matters right.  The locus of control has been misplaced.

By shifting the debate to the technical process (agile methods or formal methods, project or programme management) rather than what is ultimately the political process, far from attending to the issue, we are distracting attention. We need to focus instead on the larger process of 'commissioning' and indeed the manner in which the agenda for public service transformation is set, and then articulated, if we are to ensure that the associated IT projects conclude successfully.

This is not, I wish to emphasise, an argument for a purely technocratic approach, many of the questions are properly in the political domain. Nor am I wholly negative about the prospects of adjusting the situation, there is some evidence from the economic  sphere, that the complex boundaries between political and technical decision making can be redrawn. I am largely, and rather unfashionably, positive about the behaviour and motivation of politicians. In the case of government IT projects an adjustment of governance arrangements is to the collective benefit.