Latest / The Fiscal Policy Podcast with Fexingo: Government Budgets, Stimulus, and Public Spending / Why Government IT Projects Cost Ten Times More Than Planned
Transcript
- Lucas: So California spent over a billion dollars trying to build a payroll system. And then it just... never worked. Luna: A billion dollars for payroll? How many employees were they trying to pay? Lucas: About 250,000 state workers. The project was called MyCalPAYS. It started in the early 2000s with an estimated cost of nine million dollars. By the time they pulled the plug in 2013, they had spent roughly one point two billion. Luna: That's like a hundred and thirty times the original estimate. How do you mess up that badly? Lucas: It's a pattern. The Institute for Government, a uk based think tank, studied large government IT projects across the US and found that about 70 percent exceed their original budgets, and the average overrun is 45 percent. But MyCalPAYS is an extreme case. And it's not just the US—the UK's National Health Service spent about ten billion pounds on a single IT modernization project that was eventually abandoned. Luna: So what's the root cause? Is it just bad management, or is there something structural about government procurement? Lucas: It's structural. Let me give you three reasons. First, optimistic cost estimates. When a project is proposed, the initial estimate is often a political number—low enough to get approved. The real costs only emerge after the contract is awarded. Second, vendor lock-in. Once a company like IBM or HP gets the contract, switching costs are so high that the government has no leverage when costs balloon. Third, changing requirements. By the time a system is built, the agency's needs have evolved, so they ask for modifications, which cost more. Luna: That sounds like a recipe for disaster. But don't private companies have the same problems? Lucas: They do, but the difference is accountability. If a private company overspends on an IT project, shareholders push back, the CEO might get fired. In government, there's no profit motive, no competitive pressure. The people who approve the money are different from the people who manage the project. And once the money is allocated, there's rarely a mechanism to stop funding even if things go sideways. Luna: So the taxpayers just eat the loss. And the contractors walk away with the money. Lucas: Exactly. In the MyCalPAYS case, the state sued the contractor, SAP, and eventually settled. But the settlement was a fraction of what was spent. The contractor paid about ninety-five million dollars, but the state had already paid them hundreds of millions. Luna: It feels like there's a fundamental mismatch between how governments plan and how technology projects actually work. Lucas: That's a perfect way to put it. And it's not just IT. The same dynamic plays out in defense procurement, infrastructure, healthcare systems. But IT is especially bad because the scope is so hard to define upfront. Luna: Before we go further—and I don't mean to interrupt—but listening to this, I think about how this podcast stays ad-free. If walking through the economy with us has made something click, and you want to support that choice, there's a simple way. It's buy me a coffee dot com slash fexingo. That's it. Lucas: Yeah, we deliberately keep the show free of ads. If that's valuable to you, and you want to help us keep it that way, that link works. Now, back to the question of why this keeps happening. Luna: So let's talk about the incentives for the contractors. They know the government is a captive customer once the contract is signed. Lucas: Right. There's a term for it: the 'winner's curse' in procurement. The winning bidder is often the one that underestimated the cost the most. And then once they're in, they can charge for every change order. The government can't just walk away because they've already sunk millions into integration and training. Luna: Are there any examples where governments have gotten it right? Lucas: A few. Estonia's digital government is often cited as a success, but they started from a blank slate after independence. The US state of Utah did a decent job with its online tax filing system by breaking the project into small, incremental pieces. The key seems to be modular development—don't try to build the whole thing at once. Luna: But most governments don't do that. They go for the big bang approach. Lucas: Exactly. And there's a political reason for that. Politicians want to announce a big, transformative project. They don't get re-elected by saying 'we're going to slowly improve the system over five years.' They want a ribbon-cutting moment. But the evidence is overwhelming that this approach fails. Luna: So what would real reform look like? Is it just smaller projects, or is there something else? Lucas: A few things. First, independent cost estimation. Don't let the agency or the vendor set the budget. Second, require modular contracts with fixed-price phases. Third, mandate that project data be made public, so taxpayers can see the cost overruns in real time. The UK has a 'Government Digital Service' that does some of this. But even then, political pressure can override the safeguards. Luna: So the problem is ultimately political. The same incentives that lead to bad fiscal policy lead to bad IT procurement. Lucas: Yes. And that's the larger point. Government IT failures aren't just a technical glitch—they're a symptom of a budget process that rewards overpromising and doesn't punish underdelivering. Every billion wasted on a failed system is a billion that could have gone to schools, roads, or tax relief. Luna: It's easy to see billions and think it's abstract. But that's real money from real people. Lucas: Exactly. And the problem isn't going away. As more government services go digital, the stakes are only getting higher. The question is whether we'll learn from the past or keep repeating it. Luna: I guess that's a question for voters as much as for procurement officers. Lucas: Right. Because ultimately, the solution isn't just better software—it's better accountability. And that starts with understanding how the money flows.