Why government websites often struggle to meet people’s needs

By Greg Jordan-Detamore

November 3, 2022

myGov
Governments should treat software as a service that is constantly being improved rather than an item bought or created once. (AAP Image/Supplied, my.gov.au)

“Why are so many government websites hard to use?” This is a question consistently asked by policymakers, government employees, and the public.

From the 2013 healthcare.gov launch debacle to more recent failures of many unemployment benefits websites, it’s not hard to find examples.

And it’s not just websites. All sorts of government tech projects have challenges. One report found that only 13% of large government software projects are successfully completed on time, on budget, and on target.

In our decade-plus of working with governments to deliver critical services to people that not only met their needs, but treated them with respect and dignity as well, we’ve found that there are three common factors that tend to complicate these projects:

  1. “Clunky” approaches and practices: project scopes that are too large and rigid, with too many upfront specifications and not enough iterative development.
  2. Not focusing on people-centred tech practices like user research, design, and product management.
  3. Insufficient technical capacity and expertise.

To be fair, these challenges are not unique to government. They’re common in the private and nonprofit sectors too. There are also many cases of well-functioning government websites that power services that are simple, accessible, and easy to use. Still, addressing these key issues can make a world of difference in delivering better public services. Let’s explore how:

1. “Clunky” approaches and practices

Governments need many goods and services to function, from bridges to fire trucks to pencils. Traditional budgeting and procurement treat digital technology as if it’s similar to a large physical item by requiring:

  • long timeline for planning, budgeting, procurement, and delivery — often measured in years.
  • precise understanding of how people will use it before it’s purchased or built.
  • Long, detailed lists of requirements specified at the beginning of the process.
  • clear definition of when something is “done”.

This approach doesn’t work well for software. As our friends at 18F put it, “Technology changes, government policies change, regulations change, laws change, and leadership’s priorities change — any project that is planned in great detail upfront will be unable to adapt to those changes and will be at significant risk of failure, significant cost and deadline overruns, or costly ‘change orders.’”

Rather, treat software as a service that is constantly being improved rather than a big item bought once. “Fund product teams, not projects.” If work is being contracted out, break it up into small “modular” contracts.

2. Not focusing on people-centred tech practices

Often, government digital tools technically do what they’re supposed to do—but in a way that doesn’t work well for the people who use them. A big culprit can be inadequate user research, design, or product management. Governments may not employ people with these skill sets—or if they do, there might not be enough of them. Meanwhile, vendor contracts used to purchase technology may not have these practices included in their scope.

Each of these practices plays an important role in delivering effective, easy-to-use digital services:

When the needs and experiences of real people aren’t placed front and centre throughout the development process, a lot of money and time may be spent on software that doesn’t deliver what the people who are using it actually need.

3. Insufficient technical capacity and expertise

Despite digital technology being a key part of government operations, it’s common for governments to lack the tech knowledge and skills needed to plan, manage, and implement such projects and services. This creates challenges both for the large portion of government IT work that is contracted out to the private sector as well as for efforts to develop technology internally.

Specifically:

  • At the administrative/leadership level, legislators, executives, and policy staff often lack appropriate knowledge that’s critical for strategy, policy, and budgeting.
  • Staff in procurement offices and mission agencies sometimes lack the domain-specific knowledge needed to effectively write RFPs, evaluate vendors, and act as good product owners for digital technology; it’s hard to oversee the work if you don’t know how the work should be done.
  • When it comes to the actual technology development and delivery, some work is contracted out that would actually be cheaper or more efficient to do in-house but can’t because of insufficient internal staff skills and/or expertise in key digital disciplines.

Common challenges that governments face in hiring certain types of digital specialists include: complex hiring processes, outdated job titles, below-market salaries, degree requirements, and bureaucratic work rules. By addressing some of these issues — as well as educating policymakers and upskilling existing employees — governments can greatly improve their digital capabilities.

Where do we go from here?

On top of these key issues, there are several others that further complicate matters: complex laws and policies about government programmes; requirements related to security, privacy, and accessibility; and divisions between different departments and agencies as well as different levels of government.

As challenging as some of the issues in this post may seem, they can absolutely be addressed. We regularly see examples both in our work at Code for America and beyond.

This fall, we will publish a series of blog posts addressing each of these major issues presented above. By confronting these challenges head-on, we can help make government work for the people, by the people, in the digital age.

This article is reproduced from Apolitical.


:

Tell them what you really think… Shorten launches myGov user audit public survey, calls for submissions

About the author
0 Comments
Inline Feedbacks
View all comments