This week at Beacon, we listened to the podcast: This Is What Happens When Governments Build Software on Bloomberg Odd Lots. We found it relevant to many of our conversations and have summarized it for your digestion. In the episode, Bloomberg talks with Jennifer Pahlka, founder and former executive director of Code for America and author of the new book Recoding America: Why Government is Failing in the Digital Age and How We Can Do Better. And Dave Guarino, founding engineering at Code for America, who recently left the Department of Labor after working on upgrading the unemployment insurance system. They explain why building software in government is so tricky.
Our summary of the podcast
Everything we do and build these days comes with some sort of software requirement. In the pandemic period, we got sort of smack in the face. There was a realization that the software component is not trivial at all. The process by which government software is developed is changing – and there’s a lot of movement in good directions.
What has been the process?
Often, there’s a mandate that comes from legislation or regulation. This kicks off a really long process, that’s first centered around requirements gathering. That process can easily take years. They gather every imaginable requirement and throw it in one giant bucket. Those requirements are how the RFP is created, and that’s what vendors bid on. It’s an undifferentiated mess that’s not prioritized – including things that got pulled in from previous RFPs and a bunch of things pulled in around compliance and security.
That process IS NOT product management.
There’s no one saying “here’s the important things this should do.” There’s never a requirement for it to just work. It takes a long time to bid it out and then they go into development. Their job is to check all of these boxes, and there are thousands of boxes. An example project discussed had 6,700 requirements – that’s really a normal number. There are all of these things where you can check a box, but what they don’t do is check that it works.
How hard would it be for a more agile, innovative firm to break in?
That’s changing a lot. There are ~35 agencies in the Digital Services Alliance – smaller companies working in a more agile, user-centered way. It’s still a tiny portion relative to the Beltway Bandits. One example of a challenge is that in most RFPs, they usually require that the bidder has done a similar system in another state. So right there, you’re limiting it to ~3 vendors. You were never going to hire any disruptors because they were boxed out in the very first step. To some extent it’s rational. We need to do this very large project. We really need it to go right. It’s hard to think about “well why wouldn’t I look for a vendor who’s done this 5, 10 or 15 times. You’ve now very drastically narrowed your vendor pool and there’s a lot less competition.
Additionally, if you have a new vendor that wants to work in a more agile, user-centered way, that’s bidding on an RFP that’s structured in a very waterfall, top-down way, they’re not going to be successful if they do get it. They’re not getting any space to say: “Well, I know your requirement is this, but when we tested it with people, we discovered it should be done this way. Could we change that requirement?” If we define success by meeting every requirement that we laid out before we even got started, you almost ensure that you are not going to get what you really wanted.
Why are vendor options so limited?
- The ones that are putting themselves out for government contracts are maybe not as innovative as companies that are in Silicon Valley, for example [of course, a generalization].
- There are no alternatives. And it’s frustrating. A common complaint: “do you think we don’t know that our project’s going to fail? The last 7 projects have failed.”
- There’s also this real feeling that the company in San Francisco with its 40 people who make consumer software won’t understand us. They’re not going to understand the constraints of government software. They’re not wrong. The constraints are real. There’s so much that goes into getting the bid and the established companies know how to get the work.
What is it about government buying?
There’s a deep seeded culture in government: the policy people are the important people. Tech and digital are just part of implementation, and therefore at the bottom of a big rigid hierarchy in which info flows from top to bottom. People doing the tech are downstream of everything else. There’s no power or willingness to step in and say “hey we probably shouldn’t do these 6,000 requirements. Let’s focus on the 200 most important and add on from there.” There’s no permission to really say that. In contrast, the people who write code in Silicon Valley started the companies. Compliance is below them. In DC, compliance and policy are way above.
A big part of it is budgeting
There’s some degree of generalization here. That said, by and large, agencies get large, one time funding to do a project. So there’s a feeling of needing to get everything right, since you only get this chance every so often. They design the system, then they build it. And then you enter maintenance and operation, which is supposed to be very, very little.
The difference with modern software development
“Google didn’t build search and then lay off its staff. They expect to continuously change.” In modern software, you learn the most the second you deploy to real users. Unfortunately, in a big bang launch project, on Day 1, you can almost immediately see all of these issues that should be fixed. But usually, the funding is one time, instead of flat and drawn out over 10 to 15 years. Therefore, they’re waiting for the next big project to change things from the previous one.
Moving from “one time project” to ongoing funding (because it’s a living breathing system) would be a huge paradigm shift. Lots of dysfunctional probably flows down from the root cause of funding mechanism. There are a lot of people advocating for doing things differently, but to do things differently, there has to be enough internal knowledge and capacity to outsource well.
“Then it’s not our fault.”
Lastly, many IT/tech people feel that they shouldn’t have an opinion on business requirements. “If they ask us to build a concrete boat, we’ll build a concrete boat. Because then it’s not our fault…”
Final takeaways
- Requirements v. Goals: The process starts with a crazy long list of requirements used initially as an inputs to vendor selection. There’s no one who’s prioritizing requirements and focusing on the most important requirements, such as “does it work?” The developers job is to check all of the boxes, and there are thousands of boxes.
- Tough for agile, user-centric firms to break in: Oftentimes, funding is for a large project, not ongoing work. In an effort to do it right, they often look for vendors who’ve done the same type of project before. This is totally reasonable, but does limit competition. The constraints of working in government are real and guess what: the incumbents know how to win the projects.
- Constraints & culture: In Silicon Valley, the coders started the companies. In government, they answer to everyone else. Additionally, moving from “one time project” to ongoing funding (because it’s a living breathing system) would be a huge paradigm shift in funding mechanism.
