On Government Technology Failures (Part 1).

Introduction.

In the field of public sector technology, there has been a consistent pattern of failures in the implementation of information technology (IT) projects. Despite the potential for technology to greatly enhance the delivery of public services, government IT projects often fail to meet their objectives and deliver the intended outcomes. These failures can result in a significant waste of public resources, an erosion of citizens’ trust in government, and a lack of access to vital services for citizens.

This is a shame, because the promised land is enticing.

An ideal state of government technology would be one where citizens are able to access government services with the same ease and convenience as they do with consumer technology. In this ideal scenario, the technology would be intuitive and user-friendly, making it easy for citizens of all ages and technical abilities to access the services they need.

Citizens would be able to access government services from any device, whether it be a smartphone, tablet, or computer, and from any location, whether at home, at work, or on the go. The technology would be designed with accessibility in mind, ensuring that it is easily usable by people with disabilities and those with limited internet access.

In this ideal scenario, government technology would also be highly reliable, with minimal downtime and outages, making it dependable and trustworthy. The technology would be designed with security in mind, so that citizens’ data and personal information would be safe and protected.

Citizens would be able to quickly engage and communicate with government agencies in real time, giving them the ability to access information and track the progress of their requests. The technology would provide easy access to information and give citizens the ability to easily interact with government services, and provide them with a sense of transparency and control over their interactions with the government.

Government technology should be designed with citizens’ needs in mind. It must be user-friendly, efficient, and effective. This will create a smoother experience for citizens and enhance the efficacy of government services. If we consider even small time savings multiplied across every single citizen, this could, quite literally, increase the GDP of the country.

Optimizing the use of technology in government services could lead to increased efficiency and effectiveness, resulting in cost savings and reduced operational budgets.

The ability to provide online services and automate repetitive tasks would decrease the need for human involvement, which would reduce labour costs and free up staff for more complex and pressing tasks.

Technology could also improve the accuracy and speed of data collection and analysis, which would lead to better decision-making and improved service delivery. This could lead to a more efficient allocation of resources and a reduction in unnecessary spending.

Reducing government operational budgets could free up funds for social programs like education, healthcare, and poverty reduction. This could have a positive effect on society. Ultimately, the goal is not only to save money but also to improve public services and the quality of life for citizens.

Technology Doesn’t Come With Guardrails.

One issue with software development is that it does not come with built-in safeguards against creating problematic or unnecessary projects. This can be a significant challenge, as it is up to the organization or leadership team to develop their own precautions and guidelines to ensure that projects are well-planned and appropriate.

However, this can be difficult in practice, as there is often pressure to build “cool” new apps and to focus on “technology for good.” This can create a culture that prioritizes the development of new and innovative technology, even if it may not be the most effective or necessary solution to a particular problem.

Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.
Dr. Ian Malcolm from the movie Jurassic Park (1993)

Organizations may prioritize digital product development, resulting in staff members concentrating more on creating new technology than on creating solutions that satisfy the organization’s or customers’ needs. This culture can be intensified by the visibility and promotion given to staff who work on digital projects. As a result, working on digital projects can be perceived as a reward for good performance, and staff with the right connections in the organization may be more likely to land these projects.

People may want to build digital products regardless of whether there is a need for them. This can be problematic. Unnecessary or damaging projects can be created, wasting resources. A culture can emerge where new technology is prioritized over solving real problems and meeting customer needs. Opportunities for digital projects may be given only to people with the right relationships, even if their work doesn’t align with the organization’s goals.

One way to understand this issue is to think of software development as similar to building a physical structure, such as a house or a bridge. When building a physical structure, there are explicit constraints and considerations that must be taken into account, such as the strength and stability of the materials, the weight that the structure can bear, and local building codes and regulations. These constraints are often evident and visible to anyone involved in the building process.

It is obvious to anyone involved in the building process that it would not be practical or feasible to build a structure that is 2000km long and 10km high. Such a structure would be unprecedented in size and would face numerous challenges in terms of materials, engineering, and logistics. It would also likely be prohibitively expensive to build and maintain.

Despite the apparent impracticality of such a project, it is essential to consider the potential consequences if it were to be built. The structure would likely face numerous problems, such as instability and difficulty in managing the weight and stresses on the structure. It could also pose significant risks to public safety in the event of any problems or failures.

In short, the prominent and visible constraints of a physical building make it clear that specific projects are simply not viable or practical. While software development may not have the same level of visible constraints, it is still important to carefully consider the potential risks and consequences of projects and to ensure that they are well-planned and appropriate.

In contrast, when developing software, there may not be as straightforward or visible constraints or considerations. It can be more challenging to anticipate and plan for how a software project will be used or adopted or to predict the potential consequences of a failure. This can make it more challenging to develop adequate precautions and guidelines to ensure that projects are well-planned and appropriate.

One issue that can arise in technology projects is the tendency to make significant changes to the project plan or design once it is already well underway. This is similar to making drastic changes to the architectural plans for a building that is already 50% complete. Such changes can be disruptive and costly and may significantly impact the project’s overall success.

In the case of a building, making significant changes to the design once construction is already underway can be difficult and expensive, as it may require significant rework or redesign of already completed sections. It can also lead to delays and additional costs as new materials or contractors may need to be sourced. This is obvious to all stakeholders, who would not want to have the publicity around knocking a half-constructed building back down to its foundation and restarting again.

Unfortunately, technology projects do not have this inherent visibility with the press and the public at large. Making significant changes to the project plan or design once it is already underway can be equally disruptive and costly as doing it to a physical structure. It may require the reallocation of resources, the integration of new technologies or approaches, and the redesign of already completed work. It will undoubtedly lead to delays and additional costs as the project team works to implement the changes.

And people in the public sector know this — they aren’t stupid. But, the solution that is widely adopted to combat this issue is that all projects are carefully planned and designed upfront to avoid making significant changes to the project once it is already underway. In theory, this can help to ensure that projects are completed efficiently and effectively and that they can achieve their intended goals and objectives. However, the reality is that technology projects often do something new, and there is a large amount of uncertainty.

This is where the analogy to building physical structures breaks down if you will excuse the pun. Buildings typically have clear purposes, and there are only so many ways to build a room. With technology, there is almost an infinite number of use cases, and this is where the problem lies.

At the start of the project, not only do you not know what you should know, you don’t even know that you don’t know it!

As the project progresses, new information is uncovered, and new challenges arise. This is why it is so important to have a flexible system that spans from the procurement structure to the project plan and the system design that can accommodate changes as they arise.

It’s Often Not That Complex — Except When It Is.

Public sector technology projects often use databases to store and organize large amounts of data. This data may include information about citizens, government programs, financial records, and more. Data entry and modification may be necessary to input new information into the database or update existing records.

In addition to managing data, public sector technology projects may also involve the creation of dashboards and other tools for reporting and analyzing data. These tools may be used to track the performance of government programs, identify trends or patterns, help stakeholders make informed decisions, and provide a layer of transparency to the general public.

Notifications may also be an essential aspect of public sector technology projects, allowing government agencies to communicate with citizens and other stakeholders. This may include alerts about changes to programs or services, reminders about deadlines or requirements, and other important information.

Authentication is another crucial aspect of many public sector technology projects, as it is necessary to ensure that only authorized individuals have access to specific data or systems. This may involve using passwords, security tokens, or other methods to verify the identity of users.

Government technology projects may seem relatively simple and transactional compared to consumer apps, which may be more complex and innovative. They may focus primarily on managing and organizing data, rather than on more advanced features or functionality. However, this does not diminish the importance of these projects in supporting the operations and services of the public sector.

That said, some unique challenges exist to developing technology for citizens.

The first is that governments have to design for scale from day one. Because these projects are intended for use by the general public, they may be accessed by millions of people immediately upon launch. This can be a significant challenge, as it requires the technology to handle a high volume of users and transactions from the start.

In contrast, private sector companies may have more time to plan for and gradually increase their scale as their products or services gain popularity. They may also have more flexibility to make necessary changes or improvements, without the same level of scrutiny or public scrutiny as government projects.

Managing the scale of public sector technology projects is especially important because of the potential consequences of failure. If a government website or app cannot handle the demand, it can lead to frustration and inconvenience for citizens. It may also have more significant impacts on the operations and services of the government. Ensuring that technology can meet the needs of a large and diverse user base is, therefore a critical consideration in the planning and development of these projects.

Public sector technology projects face another major challenge: considering a vast array of edge cases and user groups. Governments must cater to a diverse and often intricate user base, comprising people with varying abilities, backgrounds, and needs. This includes the incarcerated, children who cannot use the systems by themselves without adult supervision, the elderly who don’t own smartphones, and everyone in between.

This can be a significant challenge, as it requires technology to be designed and developed in a way that is accessible and usable by a diverse group of people. This may include individuals with disabilities, those with limited technology skills or experience, and others who may be part of marginalized or underserved groups.

In contrast, private sector companies may be able to focus on a specific target market or user group and may not need to consider the same range of edge cases. They may also have the option to ignore specific market segments if it is not financially viable to address their needs.

Ensuring that public sector technology is accessible and usable by all community members is essential for promoting fairness and inclusivity. It is also crucial to ensure that government services and programs can reach and benefit as many people as possible.

Security concerns also apply to startups. When launching their first product, startups typically haven’t had any security review beyond what their internal team can do with their existing knowledge. This isn’t a major concern since startups have few, if any, customers and are not yet making money, so they’re unlikely to be targeted for a hack. However, as soon as they start to scale up, this becomes an issue.

Government projects that have some public interface and are served over the internet, on the other hand, are likely to start experiencing hacking attempts from day one of launch because there is far more at stake. So, let’s explore just how much is at stake when the government launches technology projects.

The Stakes are higher in the public sector.

When things go down or don’t work with technology, this can range from mildly frustrating for users (and a few sleepless nights for developers and project managers) all the way to causing fatalities.

A technology failure of a private company can have dire consequences. In the worst case, it could lead to financial losses or even bankruptcy, resulting in job losses and financial hardship for employees and other stakeholders.

Even if the company recovers financially, it may suffer long-term damage to its reputation and customer trust. This can lead to a decline in sales and revenue. Investors may see a decrease in the value of their investments and be reluctant to invest in the company again. On a practical level, a technology failure can prevent the company from conducting business or serving customers, leading to lost revenue and customer dissatisfaction.

However, the stakes are much higher if a public sector technology project fails. The consequences can be far-reaching and have a significant impact on the public. For example, if a government website or app cannot handle the demand, it can lead to frustration and inconvenience for citizens and may also have more enormous impacts on the operations and services of the government.

In addition, public sector technology projects often involve handling sensitive or personal data, such as financial records or health information. If this data is not adequately protected or is compromised in any way, it can have severe consequences for individuals and the community.

In the most severe of cases, a failure in health-related systems that fail to recognize an individual’s allergy to a particular antibiotic, or a disruption of the 999/991 emergency system, can have fatal consequences. Numerous other potential risks must be taken into consideration.

Furthermore, public sector technology projects are often funded with taxpayer dollars, so there is an added responsibility to ensure that these funds are being used effectively and efficiently. If a project fails or does not meet its intended goals, it is not only a waste of resources but can also erode public trust and confidence in the government.

Overall, the stakes in the public sector regarding technology projects are higher, as the consequences of failure can be more significant and far-reaching. It is, therefore important for the government to carefully plan and manage these projects, and to ensure that they are able to achieve their intended goals and objectives.

The Statistics of Failure.

The statistics for the failure of public IT projects are staggering. It is a testament to the productivity gains of technology that, regardless of this wastage, we still feel it is worth continuing to invest in technology because the small number of projects that do work provide enough benefit.

According to The Standish Group’s report, only 6.4 per cent of federal IT projects in the US with labour costs of $10 million or more were successful between 2003 and 2012. So for every $1b committed to technology costs, $940M is wasted and adds little to no value.

A study by the Brookings Institution found that the average cost overrun for government IT projects was 45% and that the average schedule overrun for government IT projects was 70%.

And the objective numbers are not small either. For instance, the U.S. government has invested heavily in information technology (IT) projects in recent years, with spending totaling 92.16 Billion dollars in 2021 alone.

This is a concerning trend, as IT projects have become increasingly important in government and citizens’ relationships. The healthcare.gov website, for example, was a high-profile and politically important project that ultimately suffered from significant cost overruns and delays.

The United States is not alone in its struggles with government IT projects. Other countries, such as the United Kingdom and Australia, have also experienced failures in IT projects, and we will cover a few specific case studies.

So let’s look at a few key stats from the Standish group report. Let’s start with some definitions based on the Classic CHAOS metrics.

Successful projects as on time, on budget, and are on target.
Challenged projects are over budget, late, and/or have an unsatisfactory target.
Failed projects are projects that were either canceled prior to completion or not used after implementation

For large projects, defined as those with labour costs over 6 million dollars, the statistics are dire:

Successful: 13%
Challenged: 58%
Failed: 29%

Smaller projects with budgets of less than 1 million dollars, unsurprisingly, fare somewhat better:

Successful: 57%
Challenged: 29%
Failed: 14%

We can assume that successful projects delivered their projected value to analyze Return on Investment (ROI). For every dollar spent, taxpayers received one dollar’s worth of technology. Challenged projects, however, only provided taxpayers with fifty cents’ worth of technology for each dollar spent. Sadly, failed projects provided no value at all. This does not consider the cost and time overruns that often occur before challenged or failed projects go live or are abandoned, thus potentially underestimating the issue.

For every $1 million invested in a portfolio of smaller (sub $1m) technology projects, we can expect to observe the following outcomes:

$570,000 of value from successful projects
$145,000 of value from challenged projects
$0 of value received from failed projects.

So the total is $715,000. So for every dollar of taxpayer funds invested, we can expect to receive 71.5 cents of value back through technology, resulting in a capital efficiency of 71.5% for the project itself. Considering the fact that then the technology will hopefully be used for many years, this will most likely create a positive ROI in the future.

Let’s review larger projects.

For every $1 million invested in a portfolio of larger (above $6m) technology projects, we can expect to observe the following outcomes:

$130,000 of value from successful projects
$290,000 of value from challenged projects
$0 of value received from failed projects

So the total is $420,000. So for every dollar of taxpayer funds invested, we can expect to receive 42 cents of value back through technology, resulting in a capital efficiency of 42% for the project itself.

Given that smaller projects are 70% more capital efficient than larger projects, governments have the potential to deliver more than twice the value of what they currently provide if projects are managed correctly. We will investigate further in the solutions section how to address the current reality of project failure as the norm.

Case Studies of Technology Project Failure

NHS Patient Record System

The National Health Service (NHS) in the United Kingdom began the National Programme for IT (NPfIT) in 2002, with the goal of creating a centralized, electronic patient record system for the entire NHS.

The goal of the project was to replace paper-based records with a digital system that would allow for more efficient and effective sharing of patient information among healthcare providers.

The NPfIT was designed to provide a single, centralized electronic health record for each patient, which would be accessible to authorized healthcare professionals across the NHS. This would allow for a more complete and accurate view of a patient’s medical history, making it easier for healthcare providers to make informed decisions about treatment and care.

The system would also allow for the secure sharing of patient information between different healthcare organizations, such as hospitals and General Practitioner (GP) surgeries, improving patient continuity and allowing for more efficient use of resources. Additionally, the system was designed to improve data security and protect patient privacy by using advanced security technologies.

The NPfIT would have involved installing new computer systems and software in NHS hospitals and GP surgeries across the country, as well as integrating existing systems. The project was also intended to provide training and support to healthcare professionals to help them adopt and use the new system effectively.

However, the project quickly ran into difficulties. According to a report from parliament’s public spending watchdog, the project was hampered by a lack of clear goals, poor management, and a failure to consult with healthcare providers adequately. In addition, the contract with the primary supplier, a consortium called CSC-led NHS Connecting for Health, was plagued by delays and cost overruns.

In 2011, the NHS abandoned the NPfIT, opting instead to focus on regional IT systems. However, even these regional systems have been plagued by similar problems, with poor management and contractual wrangles leading to increased costs and delays.

The final cost of the NPfIT is expected to be several hundreds of millions of pounds higher than the current £9.8bn, adding up to a total of £10bn. The project’s failure has been a major blow to the NHS and a significant waste of taxpayer money. Every single man, woman and child in the UK threw $200 each down the drain on this project.

The case is a clear example of how a lack of clear goals, poor management and failure to consult with healthcare providers can lead to project failure. The NHS has been criticized for not adequately planning or testing the system before its launch and for not engaging with healthcare professionals to ensure that it met their needs. Additionally, the contract with the primary supplier, a consortium called CSC-led NHS Connecting for Health, failed to deliver the intended results, adding to the project’s failure.

The case serves as a cautionary tale for other large-scale public IT projects, highlighting the importance of careful planning, consultation, and management to avoid similar costly failures in the future.

Obamacare (healthcare.gov)

The launch of the Obamacare website (also known as healthcare.gov) in 2013 was plagued with technical difficulties, leading to widespread frustration among users and significant embarrassment for the Obama administration. There were several factors that contributed to the failure of the website, including poor management, inadequate testing, and a lack of coordination between the various teams working on the project.

One of the main issues was that the website was not adequately tested before it was launched. This meant that when it went live, it could not handle the high volume of traffic it received, leading to long wait times, error messages, and other technical problems. Additionally, the website was not designed with the users’ needs in mind, making it difficult for them to navigate and understand the information they were presented with.

Despite Administration officials having had more than three years to work on it, the signature effort of the Obama administration was a failure, in stark contrast to the remarkable success of the Apollo mission, which achieved its goals of putting people into orbit and returning them to Earth in a similar timeframe to John F. Kennedy’s “we choose to go to the moon” speech.

Forget launching to the moon; we can’t even launch a website now.

Canada Payroll System

The Canada Payroll system, also known as the Phoenix pay system, was a large technology project implemented by the Government of Canada to streamline the payroll process for public servants. It was intended to replace the decades-old system used by the government and centralize the payroll process to reduce costs.
However, the system was beset by several problems upon its launch in 2016. There were widespread bugs and errors in the system, and many of the promised functionalities were not working as intended. As a result, thousands of public servants experienced issues with their pay, including non-payment, overpayment, and incorrect payment amounts.

These issues caused significant disruption for many public servants and resulted in a loss of trust in the system. The Government of Canada spent hundreds of millions of dollars to try and fix the issues with the system, but despite these efforts, the Phoenix pay system never achieved the goals it was designed for.

The case of the Canada Payroll system is also an example of large technology project failure in the public sector. The system was expected to streamline the payroll process for public servants, but it launched in 2016 with many bugs, errors and lack of functionalities. This resulted in thousands of public servants not getting paid, overpayment and a lack of trust in the system. The federal government ended up spending hundreds of millions of dollars to fix the system, but it never achieved the goals it was designed for.

Why Does Failure Happen?

It is interesting to take a step back and understand the common themes and roadblocks that stop governments successfully implementing technology projects. After all, nobody wants to fail, yet failure keeps happening.

The failure of large technology projects in the public sector is a complex issue often caused by a combination of factors.

One key issue is the tendency of political and bureaucratic leaders to equate the announcement of a project with its successful accomplishment. This mentality can result in a lack of focus and attention on the details and operational aspects of the project as leaders move on to other issues, crises or new projects.

Another vital issue is the cultural disconnect that can occur between the project designers and the people who have actually to implement and run the system. This “handover mentality” can result in a lack of communication and coordination between different teams and departments, as well as a lack of understanding of the operational requirements and constraints of the project.

This cultural disconnect can also lead to problems being downplayed or not adequately communicated to those at the top of the chain of command. Problems that are seen as warning signs of more significant issues are often minimized and passed off as minor rather than being addressed head-on. This can lead to a lack of accountability and a lack of transparency in the management of the project, which can contribute to its ultimate failure.

This is a huge issue — good news and metrics flow up, while bad news is hidden or downplayed. This means that the people at the top with authority to make decisions that could positively impact a project often only know that things are going off-course when it is far too late to do anything about it. Governments are typically large organizations with many different departments and levels of bureaucracy. This can make it difficult for information to flow freely between different levels and for decision-makers at the top to understand what is happening on the ground.

Bureaucrats and managers may fear that reporting problems will reflect poorly on them or lead to punishment, so they may choose to hide or downplay negative information.

As a result, leaders at the organisation’s top may only hear good news. They may not be aware of important issues or problems affecting the organisation’s functioning. This can lead to poor decision-making and a lack of effective action to address problems, as the leaders are not aware that they exist.

Additionally, when problems are reported, it can be difficult for the top leaders to properly assess the situation and determine the most appropriate course of action, given the complexity and scale of government organizations.

Governments struggle to acquire technology projects due to systemic issues. Procuring these projects is much more complex than buying commodities such as chairs. To manage a technology project effectively, starting it and making adjustments as the project progresses is best. It’s impossible to predict all the complexities of such endeavors — technology projects are typically at least one order of magnitude more complex than any individual can fully comprehend.

The solutions appear very simple: flexibly purchase technology, work in an agile manner, launch smaller projects sooner, and so on.

So why are they not widely implemented? Well, there are a lot of roadblocks, and we will make a systematic review in Part 2.