18F’s profound legacy of procurement reform

Back in March I wrote about the elimination of the United States government’s two leading digital government teams. These two teams – 18F and the United States Digital Service – were an inspiration for digital service teams in governments around the world, including our own as we launched the Canadian Digital Service.

Beyond their digital service work – designing, building, and improving online services for people across the United States – these teams also did a lot of heavy lifting to challenge and change processes and policies that held back better service delivery. Most of this work, I’m sure, was behind the scenes and unseen by the public.

In the spirit of working in the open, though, 18F in particular produced a long-running series of blog posts and publications that remain one of the best sources of insights on how to do technology procurement in government differently.

As I was researching IT procurement reform in Canada with Prof. Amanda Clarke, these 18F publications were always close at hand and informed our recommendations for Canadian government organizations.

IT procurement reform in 25 minutes

You don’t need to be a procurement nerd to enjoy these insights. One of 18F’s procurement experts, Waldo Jaquith, gave a presentation to a Michigan state senate committee that is still the best and most approachable introduction to this work:

Cost savings in the hundreds of millions of dollars

Procurement often seems like a dry topic, but the consequences of doing IT procurements well or poorly are massive. As 18F and USDS were suddenly shut down, anecdotes about the hundreds of millions of dollars saved by helping departments and decision-makers make better technology choices quickly emerged. A few conversations could help save hundreds of millions of dollars by avoiding wasteful or ill-advised IT spending:

One of the continuous problems with IT procurement is that decision-makers have no idea how much money a custom software project should cost. If you’re trying to solve a specific need or replace an old system: should the new software cost $50 million dollars to build? $80 million? Departments issue a request for information, large IT vendors come back with multimillion-dollar proposals – perhaps similar to past government IT projects, with a bit extra for inflation and, of course, higher project complexity – and departments go ahead and issue requests for proposals for prices that match. No one involved from the government side is well-equipped to ask if the project should really cost that much, or what all that money is for. As Waldo Jaquith writes:

The result has been 20 years of spiraling of costs for custom software in government, as prices have gradually gone up because they are tethered to nothing but the amount of money that vendors say it’ll cost, and they have every incentive to provide a big number.

He has an elegant solution to this: budgeting software projects in “scrum team years”. Scrum teams (digital product teams of, say, 4 to 10 people), might cost $1 or $2 million dollars per year, depending on the size of the team. That’s a helpful grounding point for how much a custom software project should actually cost:

Is the bid for $20 million? Then you should be getting between 10–20 scrum team years, perhaps as 5 scrum teams working for 4 years, perhaps as 5 scrum teams working for 2 years, or any number of other mathematically plausible variants. Experienced software developers can compare the complexity of a project to the number of scrum team years and have a sense as to whether the price makes sense.

This works at an agency level, this works at a procurement level, this works at a budgeting level. It allows people who lack deep expertise in software development (which is to say nearly everybody involved in the entire budgeting and procurement process) to have some basic unit of value to compare and debate. (Does this project really require 500 people working for 5 years? What could we get from 10 people working for 6 months? Wait, we’re only getting 10 scrum-team years but we’re paying $50 million? And so on.)

If you’re a public service leader working on IT or service delivery projects, the State Software Budgeting Handbook that Waldo wrote with Robin Carnahan (later the head of the General Services Administration) and Randy Hart at 18F is a must-read.

Along with that handbook, and the scrum team years blog post above, there are two other blog posts from Waldo Jaquith that I send to anyone looking for advice on IT procurement:

• Make sure your UI modernization plan includes an open source clause.
• How an agency principal should oversee a major custom software project.

The one time a sitting Canadian Member of Parliament asked me for digital government advice, that’s what I sent them, too. (I no longer worked in the federal public service at that point!). Also you don’t need to be an MP to ask me for advice, you can just email me. 😜

Along with Waldo and the team at 18F, fantastic public servants across the US government worked for years to change IT procurement for the better and deliver better services to citizens. The United States Digital Service had the “procuremenati”, a small but mighty team of procurement experts helping departments buy software more effectively. Within US departments and agencies, unsung heroes worked to either change outdated rules or to achieve useful outcomes despite them. (Mark Hopson, the now-retired “procuremancer”, has an entertaining newsletter of procurement adventures from the past decade.)

I’m forever grateful to all of these public servants for their work, and for having the courage to share it in the open. If we’re ever able to achieve significant reforms to IT procurement in Canada, it will be thanks to the example they set.