Fixing “Clunky” Approaches to Government Software Development

Start small and iterate—not only with tech development but also planning, budgeting and contracting
a woman with paperwork

This is part of a series of blog posts on Human-Centered Government that we’re publishing in partnership with our friends at Apolitical: the social learning network for government.

Governments need many goods and services to function. Traditional budgeting and procurement treat digital technology as if it’s similar to a large physical item such as a bridge or fire truck – created or purchased once, then maintained – but that’s not how modern technology functions.

Digital technology requires constant improvement, due to issues like technical bugs or security flaws and the need to stay compatible with other updated technologies. The motivating needs and use cases may change during the development process. A years-long delivery timeline can mean that once a product finally launches, it may already be outdated and not meet user needs.

As 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’.”

These issues are sometimes labeled as being about “tech procurement,” but to a large extent they are not; they can just as easily appear in internally-built solutions. The fundamental problem here is one of the overall approach toward digital technology and service delivery, including in planning and budgeting.

Fortunately, changing how these projects are approached can help improve results. Here are a few ways:

1. Start small and iterate

Digital products and services – and the policies governing them – should start small and improve continuously.

Products and services are never “finished”, only improved. You can course-correct by starting small, learning from deliberate experimentation and user feedback, and building up changes over time. Favor progress and working services over perfect or “complete” projects.

This style of software development is commonly referred to as “agile”, which is used in contrast with the traditional “waterfall” style of development. It generally includes these components:

  • Smaller project scopes, focused on the near future.
  • Short development “sprints”, usually two weeks.
  • Quick delivery of a “minimum viable product”.
  • Usability testing with real people, using feedback to improve things in future development sprints.
  • New functionality added incrementally.
Credit: State of California

This change isn’t just needed at the development/implementation level, it’s also needed in policymaking and budgeting. Existing processes often require a level of detailed planning too far in advance.

Making this switch can be a big culture and policy shift – so start small and don’t try to do it all at once. It’s often a good idea to pick a lower-salience pilot project to use as a first attempt.

How to get started:

  • Think of a project that you plan to start working on soon. It doesn’t need to be tech-related, but it should involve creating something in order to help someone.
  • Ask yourself, “What is one very basic way this could be useful to someone?”
  • Develop a plan to accomplish that one thing, even if it’s imperfect or inelegant. Do not obsess over perfectionism! Call it a “work in progress” to reduce pressure.
  • Show/give it to people who are the intended users and get feedback from them on how it can be improved.
  • Develop a prioritized list of ways that it can be improved as well as new functionality that could be added.
  • Work on one or two of these ideas for improvement.
  • Repeat!

More resources

2. Modular contracting

If complex work is being contracted out, break it up into smaller contracts with tighter scopes rather than one large monolithic contract. Contracts should focus on buying a team’s services, not a finished product.

“Every procurement, especially for a large system, has a fair amount of uncertainty,” write Laura Gerhardt and Mark Headd of 18F. “When you procure that system in one or two procurements, you are placing all your eggs in one basket. If the post-award delivery fails, the entire system and likely your mission area fails with it.”

Benefits of modular contracting include:

  • Reducing overall risk by containing problems in a smaller component of the project.
  • Delivering working software faster.
  • Providing more opportunities to reflect with a specific vendor on the quality of work being delivered.
  • Providing bidding opportunities to a wider range of vendors, increasing competition.
  • Encouraging good technical documentation throughout the development process.

Modular contracting can have downsides, such as increased administrative burden. Switching out vendors wholesale during project implementation can also be costly and complex, and may not always be viable. Ways to address these issues include:

  • A phased approach that uses a larger contract but breaks it into smaller option periods, providing frequent opportunities to consider ending the contract but allowing things to seamlessly continue if they’re going well.
  • Awarding “an ‘umbrella’ contract to one or more contractors with a statement of work that describes the general scope, nature, complexity and purposes,” which can then be used to order specific services as needed.
  • Including mechanisms for accountability, such as weekly checkpoints and the ability to rapidly cancel a contract if it’s not going well.

How to get started:

  • Think about an upcoming large contract, either planned or still in the ideation stage.
  • Engage with staff in your procurement office early in the process and explain what you are trying to achieve, in order to get their support and buy-in.
  • Ask: Could this be broken down into smaller components that fit together but can be executed in a somewhat standalone way? Are there tighter scopes of deliverables that can be created?
  • See if you’re able to get contracts that involve spending no more than $2 million in a single year, with a request for proposals that are no longer than 20 pages.

More resources

3. Fund product teams

For governments looking to advance their practices, particularly with the development of in-house capacity, one approach to consider is: “Fund product teams, not projects.”

“The project model says: ‘We can predict what we’ll be doing for the next few months, how much that will cost, and the benefits we’ll get from that work,’” notes David Thomas from the UK government. “The funding model assumes nothing will change. But things always change, and the funding mechanism isn’t flexible enough to cope.”

“Product teams will work on a single service or set of services indefinitely. They will combine expansion of services, adding new features to those services and maintenance on those services,” he writes. Specific benefits include greater stability and maintained domain knowledge, better software maintenance, less duplication of work, and reduced knowledge loss.

Key takeaways

A central element of any effort to improve government digital technology needs to be moving away from “clunky” approaches – with excessive project scope and upfront planning – toward starting small and improving continuously. For complex work that’s being contracted, prefer smaller modular contracts over a single mega-contract. And consider funding internal semi-permanent product teams rather than just approaching things project-by-project.

In our next post, we will explore how governments can better incorporate user research, design and product management in their digital work.

Note: Special thank you to Mark Headd and Jeff Maher for generously reviewing and offering feedback and suggestions on this post.

Read more
Learn more about

Related stories