Project vs Product Funding

Modernization shouldn't even really be a thing at all.

Photo credit: Scott Robinson, CC BY 2.0 DEED

A few months ago, I made a slide deck about the differences between funding technology as projects and funding them as products¹. Every time I’ve shown it since then, people have asked me for a copy of the slides, so I thought I’d share them here in case they can be helpful more broadly. I also wrote up the narrative that goes along with them and included it in my Congressional testimony in January, so I’ve adapted that below. A link to the slides themselves is at the end.

As with most of what I talk about, this is nominally about technology in government but applies far beyond tech. We need to acquire ongoing capabilities, not static things, in lots of parts of government.

***

We procure and fund software as if it were static, and thus make it both worse and more expensive. This is best illustrated through a series of graphs, each one entirely fictional but representative of two fundamentally different approaches to funding software.

Government typically follows a “project” model. The following graph shows the number of staff who work on an IT project at its outset, as requirements are being developed, a request for proposal written, bids from contractors sourced and evaluated, and a winner chosen. The contractor, once hired, brings a team to develop the software based on the RFP, and the staffing levels (counting both internal and contracting staff) shoot up. There is a development period, followed by a short period of “user acceptance testing,” and then the project falls into “operations and maintenance,” (or O&M), which is generally a different color of money than the development funds. (This is a huge problem worthy of a separate discussion, but see here for a start.)

Contrast this with a typical “product” model, in which, instead of a requirements gathering phase up front, a small team, often but not always internal to government, conducts what are called discovery sprints to better understand the problems the software is supposed to address. If some parts of the proposed solution are riskier than others (for instance, it’s not clear whether a data integration will work well), they find ways to test those problems first, before an entire software solution has been built. They may develop prototypes to help question their assumptions, and they engage with users from the beginning. Product teams almost always leverage contractors, but the contractors are there to complement a core internal team which holds the product vision and provides clear direction to vendors. Staff is added slowly over time as the team learns what they need, but doesn’t dramatically ramp down once a first or even second version is shipped. As my colleague Dave Guarino quips, “Google didn’t lay everyone off after they put up search.” Indeed, they invested more.

At this timescale, there seems to be an obvious reason to prefer the project model: the minimal ongoing expense. This is what appropriators and oversight staff in Congress and elsewhere seem to be looking for as a sign of success. But as anyone following government technology appropriations knows, this is not the right timescale to look at. What happens next on the project line is one or more of the following scenarios: the software doesn’t work well for its users, and funds are sought to fix its defects; it quickly becomes outdated, either by changes in the technical environment, the policy environment, or other external factors, and funds are sought for modernization; or new needs have emerged that the existing software doesn’t address…and funds are sought to meet those needs. Thus, the actual project model line looks more like this in the medium term: 

And then in the longer term, as modernizations fail, needs escalate, and even more money is allocated, like this:  

Here is where the slow and steady product line starts to look a lot more attractive, on a purely cost basis.

But cost is far from the only reason to prefer it. Having a consistent team over time may look like an unwanted ongoing expense, if we assume that development work is at some point “done,” but that is not the case. (“Software is never done” was one of the precepts of the Software Acquisition Practices report I contributed to for the Defense Innovation Board). If software isn’t updated, it rots in a variety of ways. O&M should be relabeled ROT. (Someone please backronym that for us.)²

The product model is not only less expensive in the long run, it results in working software that doesn’t need “modernization” of the kind you’ve become used to hearing about because it’s constantly being updated and improved. To extend Dave’s quip, you don’t hear about Google pausing search for a modernization. Google Search first came out in 1998, and I doubt its code base today bears much relation to what existed then. But Search is a product, not a project. It never went into O&M. It changed daily, not every other decade.

If you’ve worked in government you’ve seen Whong’s Law in action: “Every government agency, everywhere is working on a “new system”; It will solve *all* of their data problems and will be ready to use in 18-24 months.” The joke, of course, is that it will always be ready in 18-24 months, and in the meantime, because the new system will solve all problems, no improvements can be made. Have a need? Find a workaround for the time being…which turns into effectively forever. When I worked on unemployment insurance in California during the pandemic, the team had been working on a procurement for a new system for eleven years. The request for proposal hadn’t even gone out for bid yet, so the start of development was at least a year away (probably a lot more), but the team had been in this "find a workaround” state, in which problems get kicked down the road (or more accurately, kicked into the requirements of a mega-project that will take another decade to build) since the last modernization shipped. Of course the UI system in California couldn’t scale to meet demand. It had been rotting for decades.

In contrast, New Jersey’s unemployment insurance team was making improvements every few days throughout and beyond the pandemic. The Department of Labor just crowed about that state’s successful new system, a success built on “a continuous approach to IT modernization over an all-or-nothing strategy.” Dave Cole, New Jersey’s Chief Innovation Officer, said at the press conference: “Far too often, other states, large and small, have spent hundreds of millions of dollars to do one monolithic overhaul of their UI technology and applications, only for the resulting experience to remain just as confusing, just as frustrating, and just as demoralizing for claimants and state UI staff.” It’s great to see a state escape that trap. More eyes should be on New Jersey.

Products also don’t wait to meet their users until they’re in a “testing phase” at the end, when some of the engineers have already been moved to other projects and the project’s budget is almost entirely spent. Understanding users — not documenting requirements, as the two are different — is what that tiny initial team is doing, and what the growing team does along the way.

The biggest difference between the project and product models is that the steady investment over time delivers effective service to the American people. Periodic investment in “projects” is how we get backlogs and confused and frustrated constituents.

A summary of the differences in these models is below³:

As much as it's tempting to hold agencies accountable for their addiction to the project model, this is not something they can fix on their own. Congress would need to enable ongoing funding streams (in addition to procurement changes previously discussed) in order to see agencies develop in the product model. Congress should work with OMB and agencies to change the laws, regulations, processes, and practices that impede agencies from operating in the product model.

***

That last sentence is a bit of a doozy, I admit. It’s the kind of thing one says in the written version of Congressional testimony, as if it were something that one could just do, or that anyone in Congress actually wanted to do. But it’s our jobs to make it a priority for them, and as we do, we need to figure out tactically how this will really work. I hope you’ll contribute to that plan.

In the meantime, here’s a link to the slides. Feel free to use them with credit, but let me know if you do, and in what context, and how they are received.

1. My best shorthand for the difference here is that project management is the art of getting things done. Product management is the art of deciding what to do. (Thank you to Bennett Hillenbrand for that line.) (See Chapter 10 of Recoding America for more.) But obviously, there’s a lot more to it.

2. Update: 20 mins in and we already have a winner here. April Harding suggests ROT could stand for Recurring Obligations for Technology. I love it.

3. In the chart (which is an image from the slides because Substack doesn’t seem to do columns), I list Byrne’s Law under the Product Model side. That’s from my book Recoding America. This is Mike Byrne’s assertion that most government tech projects could cost 10 percent of what they do and still provide 85 percent of the functionality. This is not quite the same as the concept of a minimum viable product (MVP), which would be far less than 85 percent of the functionality, but in the same general direction.