What if simple, step-by-step guidance could radically improve the outcomes of government technology projects ?

De-risking Government Technology Field Guides

State and federal IT projects are often costly, risky, and prone to failure. For this effort, the team compiled best practices for common issues like budgeting for agile projects, limiting contract size, and measuring success. These were then published into a “how to” field guide that agencies can use to point their projects in the right direction.

Why this matters

Most people can probably recall seeing at least one story in the press about a government technology failure, whether at the national level or within their own state. The headline probably involved a shocking price tag and finger-pointing between the government agency that paid for the system and the software vendor that built or sold it to the government.

Imagine for a second that at the same time that headline was being written, a contract for a new case management system between the government and a large tech company was receiving its final signature. The newly-signed contract obligated $300 million up front and was supposed to be complete within 3 years. Both the headline-writing and contract-signing are two steps in the same unfortunate cycle, and the newly-signed contract could easily end up with its own scathing headline a couple years, a few lawsuits, and a lot of headaches later.

What we did

After 3 phases, 10x shipped two de-risking field guides (one aimed at state audiences, and one for feds) for agencies to use when navigating the process of acquiring custom software from the private sector. The guides cover the basics of how modern software is built, which is a process that turned out to be quite unfamiliar to a lot of the folks who help make modern software in government happen. But simply copying and pasting the contents of the Wikipedia article on agile software development and handing it to a state budget examiner wasn’t going to make change at scale. In order for the field guides to be useful, they had to contain actionable guidance and they had to marry the theory of agile development with the realities of government bureaucracy. This project is unique because the ultimate deliverable wasn’t exactly a piece of technology, it was guidance. This is the first project that redefined what an MVP on a 10x project could look like.

How we did it

The first step on all 10x projects is to validate that there is a real problem worth solving. To do that, our team met with procurement, oversight, and budgeting officials from dozens of states in both the legislative and executive branches. The good news is that almost everyone agreed that there was a problem. The bad news is that almost everyone agreed that there was a problem. And most people didn’t know where to start on how to fix it. The key question in the early phases of the project became: What is the right lever to stop states from wasting billions of federal dollars on failed software procurements, and can we use it to bring about change at scale? 

Turns out, the key lever wasn’t legislative aids. Or state agency IT shops. Or contracting officers. Or the state governor’s budget folks. Or even the policy folks working on the individual programs. It was all of them. Or more precisely, it was getting all of them to work together. The question became: how can we provide a single resource that will meet the needs of each of these different (read: siloed) groups? To validate these assumptions, we essentially took all of the lessons that we thought were important, put them into one place, and tested them by putting them in front of the right folks. 

The first MVP was a simple markdown file that lived on GitHub. It contained not only the basics of modern software practices, such as DevOps, modular contracting, and the key role of product ownership, but also contained specialized guidance for folks catered to their role in the process. For example, the guide contained a library of questions that proposal reviewers can use to test how committed software vendors are to following best practices on an upcoming project.

The response was overwhelmingly positive. The initial guide exploded into the civic tech ecosystem, receiving thousands of views not only from the US, but also governments from around the world. In fact, the initial, unpolished guide was quickly translated into Czech and Portuguese. Furthermore, the team behind the guide was asked to testify in front of the legislative bodies of various state governments and some of the language even entered proposed legislation at the state level.

The reason we initially focused on state audiences is because that is the level at which many federal programs are administered, which means that failures at the state level not only cost the federal government money (the federal government funds much of the IT work at the state level) but it also resulted in the failure to deliver on the goals of federal programs. One of the main pieces of feedback we received on the initial guide was that modifying it for an explicitly federal audience could be of huge value. This marked a new definition of what scaling a 10x project can look like: not only expanding the user base of something we’ve delivered, but doing so across government boundaries, even internationally. The team pitched for Phase 3 funding to make the de-risking guide a more polished offering, conceive a business model for turning the guides into hands-on workshops, and a new guide targeting federal audiences. 

This is a good example of a project that demonstrates one of the unique elements of the 10x model: embracing unknown outcomes. To be frank, 10x was not always convinced that this project would deliver the impact that it has. We usually aren’t as excited about projects that result in guidance as we are in projects that deliver elegantly engineered software tools. But the great thing about 10x is that our decisions are based on evidence, not on hunches. And the team was always effective at proving the merits of the work and the potential it had, if 10x continued to support it. This project is also a great example of a project that made an impact early on and did not require all four phases of 10x funding. We graduated the project at the end of Phase 3, proud of the team and pleasantly thrilled at the reception, and adoption, of our guides.

Where we are today

The field guides live at 18f.gsa.gov and form the core curriculum for de-risking workshops offered by 18F that are available to agencies across the government. The de-risking guides continue receiving attention and interest from government, academic, and international groups. The ideas presented in the field guides have been embraced by state & local governments, inserted into legislative proposals, and lauded by international governments and government-focused research centers.

Graduated after Phase 3

Next steps

The success of the two de-risking guides prompted 10x to ask: what’s next? There’s always more risk to minimize, especially in the world of government technology. 10x will be exploring that question in a new Phase 1 project inspired by this one, only the new project will focus on the entire vendor management process from start to finish.