7 reasons behind the costliest government IT failures

seven reasons behind the costliest government IT failures

Government IT projects are best known for their multi-million-dollar budgets. They also tend to run for years on end and, when they fail, it usually creates a lot of controversy in the media, because there is taxpayers’ money involved.

But why do these projects fail? Your humble author went through a few dozen post-mortem reports looking for patterns, and was able to spot some regularities.

1. The “good news” culture

Government organizations are known for their “good news” culture. From what we’ve seen on many reports, people responsible for the project are often reluctant to give honest feedback to their seniors. This results in problems being underreported or swept under the rug.

government IT failures and their reasons

Perhaps this has to do with the tense emotional climate in government orgs (like the one described in Who Killed Nokia? Nokia Did – although Nokia is a commercial company.) Although public-sector orgs now try to model their culture after to that of the private sector, complete makeover still remains a challenge. Research describes decision-making within government bodies as “often autocratic” and their communications as “very structured and rules-oriented.”

Plus, employees are often concerned with staying in office rather than their agency succeeding financially. Here is a quote from Canada’s Phoenix project analysis that attributes project failure to the unwillingness of project execs to break bad news to the upper management (emphasis added):

Instead of asking for more money, which would undoubtedly lead to a lot of uncomfortable questions from politicians who were wary about the project in the first place, Phoenix executives worked with the prime contractor, IBM, to force-fit the project into the existing budget. This required reducing its functionality, testing, schedule, and project development staffing…

2. The Hubble psychology

Government agencies that work on break-though, innovative tech tend to worry little about the project’s budget or schedule. NASA has a special term for this – the Hubble psychology:

Many project managers we spoke with mentioned the ‘Hubble Psychology’ – an expectation among NASA personnel that projects that fail to meet cost and schedule goals will receive additional funding and that subsequent scientific and technological success will overshadow any budgetary and schedule problems.

Unsurprisingly, many NASA managers refer to their projects as “successful,” despite those projects having exceeded their budgets or violated their deadlines.

the Hubble psychology — The Hubble Space Telescope greatly exceeded its original budget and was launched years after promised, yet it’s now viewed as a national treasure and its initial cost and other issues have largely been forgotten.

3. Overly optimistic and inaccurate estimates

Software projects are notoriously hard to estimate correctly. And the longer the time over which a system is to be built, the harder it is to accurately predict its scope and go-live date. At the same time, if a project is unique and not something that the agency has done before, its budget and time-frame is anyone’s guess.

In many post-mortems, investigators blame project executives for underestimating risks and giving inaccurate estimates. Those inaccuracies arise not only from the difficulty of such estimates, but also from the generally optimistic human nature – people tend to give best-case-scenario predictions, especially if it helps raise funds for the project.

For example, Australian Senate Committee’s report described the government’s attempt to digitize public-sector services as “a litany of failures,” stating that it was partly because of “overly optimistic project objectives, costs, and schedules along with procurement strategies that did not reflect the myriad of risks involved.” (This assessment was disputed by the people responsible for the project, though, and claimed to be an attempt by an opposing party to discredit the government.)

Also read: Estimating a Software Project

4. No buy-in from software users

UK’s FiReControl project that lasted for six years (from 2004 to 2010) is often cited as “one of the worst cases of project failure” that occurred largely because the project was not being discussed with the parties it was intended for.

The goal of the FiReControl project was to replace England’s forty-six local fire and rescue services with a network of just nine control centers covering larger regions. After six years elapsed and £469 million was spent, it became evident that the local services were reluctant to change the way they operated. As a result, only the new facility in London ended up being used.

Yet rather than engaging with the Services to persuade them of the project’s merits, the Department excluded them from decisions about the design of the regional control centres and the proposed IT solution, even though these decisions would leave local services with potential long-term costs and residual liabilities to which they had not agreed, reads the post-mortem summary.

Another example is the UK’s ID cards project that turned out to be unpopular with the public once it went live:

The main problem with ID cards is the politics. It’s clear to any project manager that big projects need buy in before they go ahead, and this one simply doesn’t have it. A lot of voters don’t want it, and the Conservatives have said they’ll scrap the project if they’re elected.

5. A lack of proper testing

Proper testing being an afterthought is a problem on many rushed IT projects. Yet when a system hasn’t been properly tested, this could render it nearly unusable or even harmful. Mistakes in a computer program are especially costly in banking and finance.

For instance, in the already-mentioned Canada’s Phoenix Pay System case, auditors discovered that no proper end-to-end or security testing had been performed prior to the system’s launch. This resulted in the new software functioning incorrectly, with some people getting paid too little or too much, or not getting paid at all:

In reviewing a sample of 81 pay processing functions, the auditors found that 20 percent failed testing. Worse, the functions that failed never were retested. Furthermore, the system was never subjected to end-to-end testing. The wrapping paper and bow on those miscues was the decision to scrub the sole Phoenix pilot rollout that was supposed to be conducted with one department in order to assess how well the system worked under real-world conditions. The rationale: to save money.

On top of the abovementioned failure to test an important financial product, the project’s executives shut down the old system before switching to the new payment method and let known security vulnerabilities remain unfixed for almost a year, since the system was shipped in production.

6. Extremely long release cycles

In government IT, frequent feedback loops are pretty much non-existent – there is no iterative process of releasing working software prototypes for early evaluation, testing, and gathering user feedback. So the odds of building the wrong thing are much higher than in the commercial sector.

Here are some recommendations from Australia’s “Learning from Failure” report (emphasis added):

The default position that new policies proceed straight to large-scale roll-out should be reversed and instead new policy proposals should include a trial or demonstration stage, allowing new approaches to be developed fast and evaluated early […]Adaptive government calls for greater organisational flexibility. It demands more willingness to experiment — starting small, testing what works and (in the worst case) failing quickly.

Agile government project management — A table of the differences between traditional and adaptive governments from the Learning from Failure report

7. Poor project sponsorship

A project sponsor is usually a high-ranking official (equivalent to a C-Suite member in a commercial company) who makes major decisions about the project and ensures that it stays in line with the agency’s strategic goals. The project’s sponsor doesn’t spend their whole time working on the project, but they check on it from time to time and correct its course, if needed.

Weak project sponsorship is a frequently-quoted reason for project failure in both private and public sector orgs. High-ranking officials are busy people and may not have enough bandwidth – or expertise – for managing the project. Plus, considering that many government IT projects take a long time, they usually experience a high turnover among the management/sponsorship ranks.

Final thoughts

Government IT projects tend to fail more frequently and waste more money than those in the private sector. This happens because of the government sector’s failure to adapt its culture, communications, and project management practices to the realities of the new, software-powered world. A lack of vested interest or personal accountability also plays a role.

On a brighter note, considering that global IT project success rates are improving, let’s hope that government bodies adopt more modern (Agile) project management approaches, foster open cross-department communication, and stop wasting heaps of money on failed projects.