Waldo Jaquith

In the federal government, when buying anything above the simplified acquisition threshold, contracting officers are obliged to ensure that they receive an independent government cost estimate (IGCE) for the thing being procured. The idea is for agencies to be able to budget for the project, and also to have some kind of a baseline to compare proposals to. Changing how this is done for government software projects is an essential component of making that software less bad.

If you’ve ever had a major repair expense for a car or your home, then you already understand the value of an IGCE. For example, my home has hard water, and it’s become a problem for my plumbing—I need a water softener. But how much will that cost? Is it $500? Or more like $5,000? With a bit of research, I learned that I’d want a salt-based softener, and for my home’s water needs, that’ll run about $500. I’ll need some additional plumbing parts to hook it up—let’s call that $100. And then there’s labor, maybe three hours. Based on past experience, I think that’ll run about $150/hour, or $450 in total. So my estimate comes to $1,050. Now I understand that I should not bother to pursue this until I’ve got about a grand set aside. And I also understand that a quote of $5,000 should either tell that me that I’m missing some fundamental knowledge about this work, or, more likely, that I’m about to get ripped off. In short, I’m a more confident, more informed buyer, who can interrogate quotes to make a sensible choice between vendors.

Federal agencies prepare IGCEs as a matter of course, for software and otherwise, because the FAR requires it. Many states do the same, because the Model Procurement Code requires cost and price analysis in several contexts. But the agencies preparing those IGCEs nearly all make the same mistake: basing the cost of software projects on past, similar software projects. (Legislatures do this as well, which is an even more serious problem that far upstream.) From one perspective, it’s sensible and logical to base the cost of a project on past projects—it’s a reasonable assumption that this new project will not fare any better than those past projects. But from my perspective, this approach is simply a way to persist funhouse mirror project pricing, where prices have no connection to reality, but are instead a continuation of the decades-old price spiral that has resulted from pricing being untethered from any interrogateable logic.

I regret that there’s no better way for an agency to prepare an IGCE than employing people who actually know how software is made. I say “I regret” because creating new positions is actually quite difficult to do. When an agency comes to me for help procuring a custom software system, telling them “simply hire people who know how software is made” is basically telling them to go to hell. With that important caveat, there are a few ways to get at preparing an IGCE. One is to decompose the overall system need into its constituent software services, to figure out which are commercial and which are custom. They’re almost all commercial, which is great, because the prices of such software are readily available, so all the commercial parts can be priced out with certainty. But that doesn’t help with the custom parts, which we can estimate the cost of a second way: basically running a really high-level story-pointing exercise, to figure out how many months of software development that each major component will require, for an estimate in scrum-team years. And then there’s the third way: deciding that you’re simply going to scope down the work to the results that are possible over X years with Y scrum teams. An outsourced scrum team is going to run you about $2 million annually, so if you wanted a two-year contract for two scrum teams, that’s going to run you $8 million. Boom, you’ve got your IGCE.

Your IGCE doesn’t need to be right. It just needs to be coherent, interrogateable, based on facts about the project and the world, and comparable to vendors’ proposals. If my water softener runs me $850 or $1,200, that’s alright—I know what the price is based on, and I can make an informed decision that I’ve budgeted for responsibly. Without an IGCE, you’re potentially allowing yourself to get played by a market that has spent decades quoting $5,000 for water softeners (I’m looking at you, Culligan) in hopes of convincing people that’s a reasonable price tag. It’s unwise and even dangerous to issue a solicitation for a major software project without an IGCE.

For the past few years, the supermajority of my writing here has been about Agile procurement. It would be tedious to provide the same disclaimer every time, so I want to offer a blanket disclaimer here: this guidance is not for everybody. In fact, it’s for an extremely small audience!

My guidance is for employees of governments, in the United States, who are new at an Agile procurement model, and intend to outsource a substantial portion of a major software project.

Sometimes people respond to something I’ve written, telling me “this wouldn’t work well at my company,” or “this doesn’t really apply here in Spain,” or “our agency has been using an Agile procurement model successfully for a decade, and we’ve moved beyond the approach you describe,” or “this doesn’t work well for staff augmentation.” And I imagine they’re right! But none of these people are my audience! I don’t know anything about how corporations procure. I don’t know anything about procurement outside of the United States. Mature Agile procurement models are very interesting to me, but I have no generic advice to offer about them. And I’ve got very little to say about procurement approaches other than this one.

If you read what I write about here and think “this isn’t right for me,” that’s OK! It’s simply not for you!

I wrote last week about how it’s a mistake to include detailed deliverables in an Agile software development contract, but let’s throw another mistake on the pile: including a delivery deadline in an Agile contract.

Yes, I understand it sounds absurd to say that a service contract shouldn’t have a delivery deadline. But hear me out.

A delivery deadline says “you must deliver X by date Y.” That is good and sensible for all manner of contracts. But not for Agile software development contracts.

Imagine that a contract says “you will have a functioning case management system up and running in 12 months,” tying payment to that deadline. And imagine that the product owner is creating user stories that cover much of the case management system, but creating absolutely none that have any bearing on the backend, putting off difficult decisions about the hosting environment. The system is using a stubbed backend that works for local development, but that couldn’t possibly be used in production. Nine months have gone by. The system needs to be in production in three months. The vendor has a choice: they can respect the sanctity of Scrum, or they can get paid. This is not a hard call.

Under an Agile model, the product owner creates and prioritizes the backlog of user stories. (Scrum tells us that the product owner can delegate the power of user story creations to the rest of the scrum team, but they’re not obliged to do that.) When outsourcing software development, the product owner must be a government employee. If a contract includes a delivery deadline, that means that the vendor may be obliged to ignore the backlog, and substitute their own judgment for what work should be done when, in order to meet that deadline. This disempowers the product owner, and eliminates many of the benefits of an Agile model.

Government must never outsource control, and that’s exactly what you’re doing by holding an Agile vendor to a deadline. An Agile control model makes the vendor solely responsible for exactly one thing: writing code. That team is an extension of the government product owner’s will—it is up to the product owner to create and prioritize user stories that will make it possible for the delivery of a product by a deadline, not the vendor.

When procuring custom software, agencies commonly make the mistake of contracting for detailed deliverables. They think “our existing system has 16 workflows, and we want to support two new types of users, plus it has to integrate with our two SaaS vendors, so let’s put that in the contract, so that we’ll know we’ll get all that functionality.” Those requirements provide an illusion of certainty that tends to make leadership happy. But the agency is just tying their own hands.

The core proposition of an Agile contract is this: Instead of defining hundreds of requirements up front, those are instead introduced as user stories throughout the life of the project, based on constant user research, prioritized by a government product owner. Because when you define requirements up front, they’re going to be wrong. Even if you conducted lots and lots of user research, and those requirements were based on solid user needs, once you move into the development phase, the dev team and the users alike will learn new things as they go, discovering that those neatly prepared requirements don’t make sense anymore.

Have you ever read about how the cordyceps fungus infects ants’ brains? It turns them into zombies, making them leave their normal environment to climb onto the underside of a leaf, where they latch onto a vein with its mandibles and await their death. Upon dying, the fungus fruits out of the ant, growing tall to release spores, that will infect more ants and start the cycle anew. This is what it’s like for a software development team to blithely execute a contract’s requirements, even though they know it’s not what the users need. Any team doing that is miserable, stripped of autonomy, reduced to doing work for the sake of doing work, their free will compromised by bad requirements.

Let’s go back to those 16 workflows. It would be a real victory if user research found that, actually, only 9 workflows were needed. But only if the contract allows building just nine! If the vendor is contractually on the hook for 16, too bad, you’re getting 7 extra workflows, never mind whether users want or need them. Let’s also return to the integration with the two SaaS vendors. What if user research finds that one of those vendors is providing a service that the users don’t want, or technical research finds that that service is now being provided by the second vendor? Well, too bad, you’re getting that second integration anyway.

But, wait, it gets worse! It is essential that every project be led by an empowered government product owner, whose has the crucial job of preparing and prioritizing user stories for the vendor team to pull from at the beginning of each sprint. To put it simplistically, this is like preparing new requirements every two weeks. Putting a full-time, government-employed product owner at the helm of a software project restores control to government. Unless you also tell the vendor that they must complete particular objectives. Then you’ve just destroyed that model, because now the vendor has to ignore the product owner and substitute their own judgment about what work needs to be done when, and how, because they must answer to the higher power of the contract.

Again, every requirement is just tying your own hands. The statement of objectives should define the goal of the work, using a problem statement and a vision statement. There should be a few technical requirements, such as the acceptable programming languages, or the agency’s cloud vendor. And there should be a quality assurance surveillance plan to measure the quality of the vendor’s deliverables. But you should not include anything beyond that.

Requirements feel safe. Detailed deliverables are comforting. They provide a sense of assurance and certainty. I get that. But we’re 30 years into a contracting death spiral, where software projects have more and more requirements—thousands of them, in the case of major systems—and yet those projects more likely to fail than ever. This model hasn’t worked. The solution is a radical reversal: the elimination of nearly all of those requirements. This is how we put government in charge again. This is how we succeed.

There are a lot of things that I describe as “the biggest cause of failures in government software projects,” so here’s another one to throw on the pile: using capital funding instead of operational funding.

A state Medicaid agency goes to their legislature and says “we need $50 million for this big custom software project.” And the legislature hands over $50 million in capital funding. The Medicaid agency has to obligate that funding within some brief, defined period, sometimes within a single budget cycle (1–2 years). If they don’t spend the money, it’s clawed back. It’s tough to spend that much money that fast. In practice, the procurement action lead time is going to use up a big chunk of that time, so the agency will put all of that money on a single firm fixed price contract, just to get the money obligated before it evaporates. (In 2025, we saw lots of agencies have funding clawed back by DOGE, which was harder to do if that funding had already been obligated, and damned near impossible if it had already been spent.) But putting huge dollar values on a single contract is enormously risky, and leads to bad outcomes…and in this scenario, it’s the only sensible thing to do.

The problem here is treating custom software as a capital expense. Custom software should not be a capital expense! When you pay people to perform a service for you—the service of developing software, in which the vendor is paid for their time, government owning the software that is the output—that’s an operational expense.

It’s often said in the Agile space: fund teams, not projects. This is part of why that’s so.

This is a hard problem to solve! Unless you’re going to hire FTEs to develop that software—something that should be far more common than it is—how is the legislature supposed to provide operational funding? It would be foolish to expect to be able to vote every year or two to continue to provide sustained funding to an individual software project—a change in partisan control of a legislature or even just a change in a committee chair would be enough to end that funding, and a project would be left without funding. No legislature can bind any future legislature, so they generally can’t pass a bill saying “we will appropriate $10 million annually for the next five years, and that can’t be undone.” How can this problem be solved?

A common solution to this is an information technology investment fund. Instead of allocating $50 million to the Medicaid agency, the legislature allocates it to an agency that operates a revolving fund, such as a state budget agency or a state IT agency. They then dole out the money over the lifetime of the project, ideally pairing that with a level of oversight that’s tighter than what the legislature might be able to manage. Michigan’s IT Investment Fund is a good example of this.

People cleverer and more experienced than me tell me that there are other solutions here, and that things get tricky and interesting when bond revenue gets involved. I haven’t learned enough about that yet, but once I learn more, I’ll write more.

It’s worth exploring just about any mechanism available that will allow smaller, safer contracts—”OpEx, not CapEx” is the mantra here. As changes go, this one is pretty far upstream, and awfully hard to do, but if we can develop patterns and repeatable approaches here, I think it will have an enormous positive impact on the viability of major government software projects.

I’m delighted to announce that the State Software Collaborative, which Robin Carnahan and I started in 2020, is growing up and leaving its Beeck Center nest—the Council of State Governments is taking it on as a major new initiative, building and supporting shared intergovernmental software.

As I’ve spent the past decade preaching, government is utterly reliant on highly specialized software to deliver on its mission, and a lot of that highly specialized software is overpriced garbage. But there’s a strong exception: the software that agencies and departments team up to develop collaboratively. These software collaboratives are the beating heart of a lot of state agencies. State DMVs, vital records offices, departments of transportation, UI offices, libraries, etc. are all powered by software quietly built by state and local governments that teamed up because they were sick of the status quo.

The Council of State Governments is perhaps best known in my world as the state-owned NGO that puts together interstate compacts, the constitutionally defined agreements that substantially bind together the union. They’re how states agree to do stuff together when congress can’t, won’t, or shouldn’t step up. CSG is better than any other organization in the country at getting states to agree to do a thing collectively. In a happy coincidence, that’s the single biggest obstacle for creating new interstate software collaboratives. As a result, there is no organization better to take on the State Software Collaborative (now the “Interstate Software Collaborative,” and the “Intergovernmental Software Collaborative” in the interim) than the Council of State Governments.

CSG isn’t just hypothetically going to build interstate software collaboratives. They’ve already done it. Over 18 months, they led a signal interstate project in establishing CompactConnect, open source software that allows licensed professionals to practice across state lines. CompactConnect was developed incrementally, based on constant user research, improvements delivered every two weeks, led by a CSG product owner, the process so transparent that video of every sprint review was posted on the website. That’s the very CSG team that will be building new interstate collaboratives.

I have to acknowledge the Beeck Center fellows who helped build up the Interstate Software Collaborative in the years after Robin and I moved onto the Biden administration: Aaron Snow, Shelby Switzer, and Dominic Campbell. We were around for the first 18 months, but those are the people who did the work for years afterward. I’m grateful to Kevin O’Neill at Rockefeller Foundation who provided the funding that got this off the ground, and the Beeck Center (especially Sonal Shah and Cori Zarek) for turning Rockefeller’s funding into a whole lot more funding and providing our project with a home.

If you’re with a state government (or a NGO that supports states) and want to learn more about interstate software collaboratives…I used to say, “let me know,” but actually, no: let CSG know.

I write a lot about how government should procure custom software, but all of my high-falutin’ theories are built atop some crucial prerequisites that I don’t often write about. I recently wrote about the enormous value of hiring people who understand how technology works, and in the spirit of that, I want to point you to Will Callaghan’s recent blog entry on the subject: “How to be a better collaborator.”

Though I want to paste in the whole thing, I’ll give you the seven major points he reviews:

1. Consider other people’s needs as well as your own
2. Share everything openly
3. Acknowledge what you know and don’t
4. Have a shared endeavor
5. Find simple ways to stay aligned with others
6. Always be iterating
7. Work in an organization that supports all of the above

Will’s audience is individual collaborators, but I want you to think of this organizationally. Successful government software projects have created an environment in which all of these things are possible. And that’s hard! Sharing everything openly runs counter to many agencies’ instincts. Acknowledging what you don’t know can be scary, especially for anybody from a marginalized demographic. Working iteratively is a battle against the headwinds of long-term planning. In many organizations, it’s not on individuals to work in this way, but on leaders to foster an environment that provides the circumstances and psychological safety necessary to allow people to work in this way.

No amount of procurement, budgeting, or oversight changes will bring about a successful software project. They can create the circumstances under which it’s possible for a project to succeed. For that to happen, the project should be run as Will describes.

When government buys custom software (whether built from scratch or having commercial software customized), it costs a lot of money. For both federal and state government, $100 million is not a shocking price tag for a large project. I’ve worked on software projects that top $1 billion. The question I get all the time about this is, simply: why?

There are dozens of reasons why government software is often both expensive and bad, but these are the biggest reasons:

1. The price tag isn’t just for software—it’s everything. In fact, actual software development is a minority of the cost. Agencies toss everything up to and including the kitchen sink into these contracts: creating and staffing the program management office, running the help desk, providing tech support, hosting the software, monitoring performance and uptime, maintaining the software, outsourced oversight (IV&V), preparing innumerable reports and PowerPoint presentations, and just a smattering of actually creating software. Putting most or all of that on a single contract inevitably means that most or all of it gets outsourced, with associated markups and inefficiencies.
2. We’re at least 30 years into a pricing death spiral. When the average price tag is 310% of the originally budgeted price, it stands to reason that you should expect the next project to cost more, and vendors adjust their bids accordingly. (This is adjacent to Hofstadter’s law: It always takes longer than you expect, even when you take into account Hofstadter’s law.) Prices are a one-way valve—they only ever go up.
3. Price tags are a funhouse mirror. Neither program nor procurement staff know what software should cost. After a career of eye-popping price tags, staff have become inured to them. $10 million for a trivial change order is just normal. $300/hour for a junior software developer seems reasonable. $50 million as the all-in cost for a modernization of a major agency system feels like the going rate. Folks from the private sector balk at these prices, and they’re right to do so. These prices aren’t tethered to reality. But if those price tags are all you ever see, they just seem normal.
4. Agencies’ solicitations aren’t set up for the best software developer to win—they’re set up for the best bidder to win. There are very few vendors equipped to write a 500-page proposal in response to one of these kitchen-sink solicitations—this is not a competitive market. The few vendors who can manage that are the ones who get contracts over and over again. Is their work any good? That’s beside the point. The important thing is that they can get contracts. They’re very good at that.

There are other reasons for the large price tags on government software—waterfall development, vendor lock-in, not conducting user research, diffuse responsibility, lack of in-house knowledge, and so on—but it’s my experience that these aren’t the major culprits. Want the biggest reduction in pricing? Attack those big problems.

My job is working with state and local agencies on the budgeting for, procurement of, and oversight of the major software projects that undergird every agency. I have lots to say about how to get that right, but it can really all be boiled down to one piece of advice: hire people who understand how technology works.

By hiring coders, designers, user researchers, product owners, etc., agencies can stop getting ripped off (and stop publishing RFPs in which they absolutely demand to be ripped off).

The mission of nearly every government agency is intermediated by software. If the software fails, the agency fails in their mission. If a state unemployment department’s UI system goes down, there’s really no sense in which they’re an unemployment department. If a state Medicaid agency’s Medicaid Management Information System is broken, there’s really no sense in which they provide Medicaid coverage.

And yet state agencies outsource this work. The thinking is that they’re not in the business of software, they’re in the business of unemployment insurance or health insurance or whatever. Anything to do with the software is seen as the domain of software vendors, up to and including the oversight of how and what those vendors are doing. But the software is the UI and the health insurance.

I’ve spent the past decade on helping with this problem in a bunch of ways, but all of the solutions I propose are inferior to simply hiring software developers. These are the people who can evaluating agencies’ existing software, understand the needs of the users, perform market research, test software, help prepare solicitations, evaluate proposals, and oversee the work of vendors. Heck, with enough software developers, the agency can even write software themselves, instead of outsourcing it.

So, sure, you can get better vendors to bid, do a better job of checking vendors’ references, and do a better job preparing to outsource, but better than all of those is simply hiring people who understand how software is made.

When government agencies need to have custom software built, as a matter of course they require that the bidding vendors have built that exact thing before. I understand why this seems like a good idea, but it’s a mistake.

At best, state agencies are willing to say (for example), “our state’s higher education financial aid processes are unique, but we’d be willing to tolerate a vendor who has previously built financial aid systems for state higher education systems.” On its face, this seems sensible. Getting a vendor with extremely similar experience would seem to reduce risk.

Here’s the catch: there are very, very few vendors with experience building that extremely niche software. Like…three? And that’s not to say that they did it well. Were their past projects completed on time, within budget, and within spec? Probably not. Did the delivered systems address the needs of the end users well? Almost certainly not. This is not a competitive vendor pool. The odds of success are not good. Imagine finding a homebuilder by limiting your pool to contractors that had built the exact house that you want—the same layout of rooms, same siding and roofing material, the same fixtures. You could do that, but no reasonable person would.

The solution is to expand the definition of “past performance.” Has built exactly this thing before is too narrow. The way to expand the vendor pool, increase competition, and get more bids from competent vendors is to use a more common analog, something that actually exists broadly in the commercial market. To return to our example of a state higher education financial aid system, it’s better to think of that as a case management system. Students complete a form, the application is subject to a series of automated checks, some applications are queued for review by a state employee, and ultimately each application is either accepted or declined, with a dollar value attached to an acceptance. I appreciate that there’s more to financial aid systems than that, but the core of a financial aid system sounds like a straightforward case management system with a public-facing component.

Case management systems: now there’s something that lots of vendors have experience with. A huge percentage of government software systems are just case management systems in a $50 million trench coat. There are commercial case management systems that can perhaps be configured to serve the current need, there are open source case management systems that can perhaps be modified, and even writing a new case management system isn’t wildly difficult. There are hundreds of vendors with experience implementing case management systems. Some of those vendors probably have experience doing things that are functionally near-identical to financial aid systems, despite the purpose of the implementation being to source auto parts or handle customer complaints or manage travel reservations.

With few exceptions, specialized government software can be understood to be minor variants of extremely common software that’s widely used in the private sector. Agencies will be best served by understanding what software that their need is a minor variant of, and seeking vendors with experience at that. Changing the scope of “similar experience” from highly specific government experience to something broader—but equally relevant—will increase competition, lower costs, and will damned sure make success more likely.