Why E-Government Projects Keep Failing

On October 1, 2013, Healthcare.gov went live. Within hours, the site was functionally unusable. People who tried to create accounts were stuck in queues that did not move. Error messages appeared where enrollment screens were supposed to be. A site that had cost hundreds of millions of dollars to build, with years of development time behind it, could not handle the traffic of its own launch day.

What happened next is worth noting. The Obama administration brought in a team of engineers, sometimes called the "tech surge," many of them from private sector companies like Google and Oracle. In a matter of weeks, using rapid iteration and agile methods, they fixed the core problems and the site started working. The same work that had failed over multiple years of traditional government contracting was rescued in weeks by a team using different methods.

I think about this a lot when people frame government IT failure as a technology problem. The technology was available. The methods were available. What failed was the system around the project, not the software inside it.

Government IT procurement is designed around risk management and accountability, which sounds like a good thing and in some ways is. But it creates conditions that make project success structurally unlikely. A government agency developing a major IT system typically has to go through a lengthy request for proposals process, evaluate competing vendors against detailed specifications, award a multi-year contract, and then manage that contract through a formal change control process. The specifications written at the start of the RFP become the legal basis for what gets delivered. If the requirements change because the world changed, getting those changes into the contract takes time and often money. The vendor has little incentive to suggest changes that were not in the original scope.

By the time a large government IT project delivers its system, two or three or five years have passed. The requirements that drove the design are often obsolete. The technology that was state of the art when the contract was signed may have been surpassed. The staff who knew the original requirements may have moved to different roles. And the system gets launched anyway because the contract says it should and the budget has been spent.

This is not how successful technology development works. The private sector can iterate because failure has commercial consequences: a product that does not work loses customers, revenue, and eventually the company. Government agencies do not face the same consequence. A failed IT system rarely causes an agency to lose its budget or its mandate. The political cost of canceling a multi-year project and admitting failure is often higher than the political cost of continuing it. So projects that should be stopped are continued. Projects that should be redesigned from scratch get patched. And the next project starts with the same procurement structure that produced the last failure.

Healthcare.gov is the most visible US example, but the pattern is much older. I have seen similar dynamics described in government IT projects across many countries and many decades. The UK has had its own high-profile government IT failures, some of them quite large. What makes the Healthcare.gov story useful is that the rescue operation gave us a natural experiment. The same problem, solved with different methods, by people who were not constrained by the original procurement structure.

The UK Government Digital Service, launched in the early 2010s, is often cited as a contrast case. GDS was built on the idea of small, multidisciplinary teams using agile methods and user research to build government services. Their "Government Design Principles" (publicly available) emphasize starting with user needs, not government processes; doing less by focusing on core services; and building for iteration from the start. Whether GDS has fully delivered on its original ambitions is a longer debate, and I do not want to overclaim. But the approach is structurally different from the traditional procurement model, and the services built under its early years, like the GOV.UK platform, are genuinely simpler and more usable than what they replaced.

The deeper issue is that government IT failures are often framed as technology failures when they are actually governance failures. Who makes the decision to continue a troubled project? Who has the authority to cancel it? Who is accountable when the delivered system does not work? In many government IT projects, the answers to those questions favor continuation over correction. The program manager who cancels a project absorbs the political cost of the cancellation. The officials who approved the original contract are rarely held accountable for the original misdesign. The vendors who delivered a non-working system often still get paid, because the contract said they should.

This connects to something I wrote about in a different context, looking at why ERP implementations keep failing. The same pattern appears: deadlines driven by external pressures rather than readiness, political incentives that favor going live over admitting problems, and governance structures that concentrate the cost of failure on the wrong people. Government IT just has a more rigid version of this structure than corporate IT, because the procurement rules and the political accountability mechanisms make it harder to pivot.

There is also a user research problem. Traditional government IT procurement specifies what the system should do before anyone has tested whether real users can do anything with it. The requirements document describes functionality. It does not describe whether a sixty-year-old without a college degree can navigate the enrollment flow on a mobile phone in fifteen minutes. When Healthcare.gov was rebuilt, one of the things the rescue team did was watch real people try to use it and fix what they could not use. That sounds basic. It was not in the original development process.

I do not think government digital services are impossible to build well. The evidence from several countries and several projects says they can be done. But the conditions that make them possible, iterative development, authority to change direction, user research built into the process, short feedback loops between developers and users, are the opposite of what traditional government IT procurement produces. Changing the procurement model is a political problem, not a technical one. And political problems in government are, almost by definition, harder to solve.