Why Is Government So Bad at Spending Money on Itself?
At this point in the narrative, the betting odds almost seem to be written before a shovel hits the ground: When a government project is announced, how much over budget will it run? How late will it be? Will it even finish or be euthanized?
In the 21st century, Western governments don’t have a strong reputation for delivering major projects, and while a lot of the successes might not make for salacious headlines, much of that failed reputation is well earned.
But while some of the major infrastructure projects get a lot of the (deserved) attention, such as the California1 and British2 rail projects (why do trains seem to cause so many losses?), there are some projects that hide in the shadows—that can have an even bigger effect.
Governments transforming their infrastructure and internal services isn’t exactly the most glamorous topic, but it’s one that affects all of us. Because, unlike one-off projects such as building new transit corridors, government internal services dictate how well they themselves operate—or don’t. Which means that if a government runs inefficiently, then whatever they do and however they spend their money will be inefficient.
These projects are often ignored by the public, because they’re not easily seen. But because they have such a massive, compounding impact, they can be some of the most important projects that governments undertake. Every once in a while, however, the failure is so massive that the public can’t help but notice.
Accounting for the $128 Quintillion Error
The United States Department of Defense (DoD) is obligated by law to produce auditable financial statements every year. What might surprise you is that the six different armed services within the DoD (Army, Navy, Marine Corps, Air Force, Space Force, and Coast Guard) all use their own financial systems, which can make a simple requirement much more complicated.
What might sound even more surprising is that different financial systems are even used within the different armed services, which means that there aren’t just six sets of annual financial statements—there are dozens.
One organization decided they wanted to fix that. The U.S. Air Force decided to modernize their financial systems under the Defense Enterprise Accounting and Management System (DEAMS) initiative. The project began in 2005, and from the outset, the Air Force made two very unconventional directional decisions.3
The first was to run the older systems in parallel alongside the new for up to ten years, increasing the risk of duplicate or mismatched information. The second was to keep all of the existing, underlying processes and databases, and hope that a top-level system could patch everything together.
By virtue of the project being included in this article, you’d be right to assume that those decisions didn’t quite pan out.
One senior leader in HR actually told me that–according to the system–“2 + 2 = 5.”
The software system needed over 900 customizations to be able to read and match the underlying systems, many of which broke during a 2019 upgrade. Far from being fluid, the system needed constant manual workarounds; which is to say, rather than the software automating the process and popping out numbers at the end, a human would have to jump in and make corrections at multiple turns. And some of those errors were big—really big.
In 2020, DEAMS reported a reservation of funds error worth $128 quintillion. There aren’t too many countries whose accounting systems go beyond “trillion,” so to clarify how big that error is: A quintillion is a billion billions, or a million trillions. In other words, DEAMS said that the U.S. likely had more money than Star Trek’s United Federation of Planets.
Unsurprisingly, given the above, the system does not properly integrate with the United States General Ledger, the overall tally of the government’s raw financials. The DEAMS project is now 20 years old, and its $500 million budget now sits at about $3.4 billion.
There is no official word on when it will function as intended.
How Canada’s Payroll System Imploded
The Phoenix transformation project was meant to centralize and significantly reduce human resource services within the Canadian federal administration. The goal was to automate what had historically been an extremely manual set of processes and reduce the numbers of staff needed to support the public service’s human resources needs. And so, in anticipation of just how easy the system was going to be, the government decided to lay off human resources staff in all of the departments, with the goal of saving money before the project was even completed.
Another cost savings opportunity came from centralizing the whole set of operations, and moving that center about 650 miles away from headquarters. The government was confident the system would run without issues; so confident, in fact, that user testing was dramatically scaled back, and a “big bang” approach was used: Implement most departments at once, rather than try it out on a handful first to see if there were issues.
And there weren’t any issues—until the system went live, and everyone discovered that it didn’t work.4 Payroll was the first red flag, when some employees received less than they were owed, and some were actually overpaid. Many received no pay at all. The system just plain didn’t function properly. And what was worse, no one could really answer why. One senior leader in HR actually told me that—according to the system—“2 + 2 = 5.”
Adding to the 1984 comparisons was the government reaction, wherein they insisted that all new system implementations have bumps in the road, and that employees should just fill in a form and wait for it to be resolved. The number of forms soon exceeded 600,000, and the government needed its human resources experts to manually fix the system errors.
One of the biggest structural impediments to government modernization is that one could argue there is no “government” to modernize.
Unfortunately, most of those experts had been fired—and were now living 650 miles away.
Eventually, senior leadership finally acknowledged the crisis they had on their hands, and had to spend their way out of the mess. A project that was originally budgeted at $215 million and expected to save $51 million per year soon saw that budget climb. And double. And triple.
Almost ten years after implementation, Phoenix is estimated to have cost almost $3 billion. And those costs are still rising, because it’s been determined that Phoenix is unfixable and needs to be outright replaced. That replacement is still being identified.
Australia’s Ambitious One-Platform Dream
And for perhaps the most ambitious operation of the three projects, a multiheaded beast from Down Under: GovERP, the Australian government’s attempt in 2019 to standardize all internal systems on one platform. Unlike just bringing in one financial system (like DEAMS) or modernizing HR and payroll (like Phoenix), GovERP aimed to do it all—including all of their procurement activities.
Over 100 government agencies used a mishmash of different systems, which not only complicated government-wide reporting, but potentially ran up costs as each entity purchased its own software, rather than buying in bulk for the entire public service. On top of that, many of the systems were out of date and in need of a refresh. Enter Services Australia: a central agency designed to act as a hub for federal internal services (although the project was initially led by their Department of Finance—the changing project ownership a sign of things to come). As highlighted repeatedly in the government’s “reuse assessment”5—a report that essentially tried to determine whether or not the project should continue—the change in ownership led to a change in scope, which led to all sorts of questions about who was actually in charge.
The project was shifted to another department approximately halfway through the life of the project because Services Australia had already implemented its own new internal services software, and it was thought that their model could be scaled across the entire public service. But that “mishmash” of different systems, mentioned above, was—as is so often the case in these major projects—completely underestimated in its complexity.
As the Australian government soon learned, this was never really a software issue: It was a process and operational one. Each department and agency simply did things differently. The minutiae of who collects a request, what they do with it, who approves it, and in what kind of a database the information sits sounds really boring (and it really is). But without first understanding the starting point, how can anyone be led to a finish?
It would be much like hosting a party and giving everyone the same directions: Take a left on Main St., drive for about five minutes, turn right on Elm St., and we’re the third house on the left. Where do the party-goers live? In the north of the city? The west? Are they coming from out of town? Are they actually within walking distance? The process is meaningless unless everyone works with the same foundation.
And GovERP was never able to get everyone to the same starting gate. They’d planned to build and standardize 118 new software capabilities, and only 21 were completed. The original three-year, $58 million project was mercifully shut down after four years and $218 million—unlike with Phoenix, they didn’t rush user testing because they didn’t even get that far.
None of the key functions (staffing, procurement, finance, travel) made it to the finish line, and the government fully abandoned the project in 2023; only the lead department, Services Australia, still uses the platform. The other departments and agencies said they really liked the new process maps, though.
Why Governments Struggle to Work as One
The Australian GovERP serves as a great example that standardizing government is not as simple as installing the same software everywhere. One of the biggest structural impediments to government modernization is that one could argue there is no “government” to modernize.
In most Western governments—including the United States, Canada, and Australia—the government bureaucracy is actually made up of a collection of agencies and departments. And rather than just being different divisions set up under the same banner, each of those agencies and departments requires enabling legislation to be created.
In other words, the legislative arm of each government (Congress, parliament, etc.) needs to write and pass a law that creates each agency. Every agency and every department is its own legal entity, which requires them to be as independent as they can possibly be.
Massive transformation projects often take so much time to set up that they’re invariably behind before they’ve even begun.
And while those same legislative arms can create layers of laws that try to encourage partnerships and leverage scales of delivery, there are simple inhibitors that tend to throw a wrench in things. For example, the Privacy Acts of Canada and the United States expressly forbid government agencies from sharing personal information with each other without express consent from the person (or business) in question.
Why Data Sharing in Government Rarely Works
This is why people feel as though they’re talking to a dozen “governments” when trying to get all the necessary permits to open a business. While agencies with similar mandates could very well get together and develop a common form requiring applicants to grant shared access to that information, that creates new problems.
First of all, in this era of government distrust, many people and businesses will simply not grant that access. Then what? Two separate processes for people who share their information and those that don’t? Also, gaining access is just a surface-level win. Once agencies can begin sharing their information, they soon realize that their databases have nothing to do with each other. One agency collects “Surnames” while another collects “Last Names.” One agency asks for birthdates to be entered as “Oct. 1, 1980,” while it’s “10-01-80” in another, and “01-10-80” in yet another. And what happens if one agency requires a trove of information that the other agencies don’t collect? That agency will have to go to the individual and ask them for more—in essence, asking them to fill out another form.
That’s where the real integration challenges begin. Agencies have to pore over their databases, seeing where they align, and where they don’t. Then they have to make the decision: Build an extra layer of software over top of all the agency databases to help them “talk” to each other, or rebuild every agency’s databases to look the same. The first requires a leap of faith that there won’t be any errors in how they’re read, because a single mistake could mean it’s replicated millions of times before it’s even detected. (For those who are interested—in addition to the DEAMS project—it’s worth digging into Michigan’s MiDAS implementation6 to see this type of chaos in action.)
The second requires a complete transformation of the core systems and infrastructure on which agencies rely—in other words, exactly what this article is all about. And how do those generally go?
And Then There’s Something We Don’t Talk About …
When the Auditor General of Canada released the audit report of the Phoenix debacle, the word “culture”—and its associated problems within the government—was mentioned a staggering 25 times in the press conference.7 It led to an explosive reaction within the government worth about 25 times the effect of an atomic bomb. Lots of senior leaders became very defensive about the accusations, as if they were being attacked personally. But culture is not about individual behavior, it’s about the collective behavior. And there are some collective behaviors that happen time and again within governments that just don’t seem to go away.
The first is the need to customize these massive software solutions as much as possible, sometimes even building them from scratch. Governments continue to insist that they’re unique, and that their requirements couldn’t possibly be understood by anyone other than themselves. There might be hundreds of thousands of companies out there who have employees on salary, and who are given vacation days every year, as well as sick days—but the collective bargaining agreements that governments negotiate with unions somehow makes those other use cases irrelevant.
As pervasive as these cultural issues are, there’s another quality that’s just as prevalent in government cultures: the desire to finally get things right.
The result is that governments buy the absolute bare minimum software, and then spend years (and tens or hundreds of millions of dollars) trying to make it usable—or not. Some very specific payment stipulations mean that instead of using software that’s processed billions and billions of transactions, they build out new tools and have to start all over again.
The second massive cultural impediment is in how heavy oversight tolerates sliding timelines—until it doesn’t.
Rushed Rollouts, Untested Software, Predictable Failures
Massive transformation projects often take so much time to set up that they’re invariably behind before they’ve even begun. And while the “context” and “uncontrollable delays” mean that the schedule doubles or triples or even quadruples, there are few efforts made to accelerate delivery. Until, due to outside pressure or someone just deciding that “enough is enough,” the project is rushed through to completion. The result? As we saw above, perhaps the two most important parts of the project are either neutered or abandoned: testing and scaled roll-out.
The most important element of any software is that it works, and we can’t know that unless we see people using it. But user testing isn’t just someone poking around for a couple of hours, as is often the case in government software testing. It’s meant to simulate real-life scenarios: People doing the work for hours per day, every day, until you can be sure that the software has run the gauntlet of every possible pain point.
This is why, when a new stadium is opened, they make a big ceremony of everyone flushing the toilets all at once. You can’t know that the plumbing will hold if you pretend that 80,000 people are going to flush in a respectable and orderly sequence.
Compounding that first massive gap in judgment, all three of these projects went for the “big bang” approach: rolled out the software virtually everywhere, all at once, rather than first implementing in a few smaller agencies, adjusting where needed, and rolling out another handful. By tempting fate and launching everywhere with unproven software, they might as well have just called it “the unsinkable Titanic.”
Real Reform Means Facing the Past, Not Ignoring It
Unfortunately, the long-term effect of these failures is a reduction in ambition. Rather than make the government as efficient as a Silicon Valley tech company, officials might as well keep the 40-year-old systems: They might be slow and inefficient, but at least no one will watch us try to fix it, right? What makes things difficult, however, does not make them impossible. As pervasive as these cultural issues are, there’s another quality that’s just as prevalent in government cultures: the desire to finally get things right.
Every public sector project team wants to deliver the rare government “win,” and that enthusiasm grows the bigger and more ambitious the goal. And which politician wouldn’t want to brag about how their leadership brought a cheaper government, or a faster government? While the infrastructure and the overall culture can hold things back, the individuals within those structures can—and want to—do more. The ambition is there, and the lessons from previous failures can help build the blueprints for future successes—not excuses to run away from what the public needs.
For that reason, I strongly believe that governments can deliver needed change. And to build more trust with their citizens, that change is more important now than ever.