There’s a big disconnect between modern software development practices and government contracting. It can seem intractable, but there is a solution.
It’s the job of contracting officers to get government the best value for their money. That means being sure that they’ll get precisely what they need, within budget and on time. Normally, the best way to do this for a “firm, fixed price”: buying X gizmos that meet Y spec for $Z.
Firm fixed price (FFP) is by far the preferred method of procuring stuff. And for good cause! Contracting officers are taught that nearly any other contract type (i.e., labor-hour, cost reimbursement, or time and materials) is more risky. And that’s generally true.
That’s what has led us, for decades, down this path of wildly over-specified software RFPs. FFP for complex software means you need to have hundreds of pages of specs, because you’ve got to specify exactly what you’re getting for your money. That’s seen as safe.
In the meantime, software developers gave up that kind of software development and moved to Agile. We know that if you define all that stuff up front, you’re sunk. You’ll build something bad that the users hate, but that sure does meet the spec.
This has left a fundamental disconnect between contracting practices (specifying everything is safest) and software development practices (specifying everything is dangerous).
The solution to this is the obvious one: contracting officers need to stop using FFP for software development. There is literally nothing you can FFP for Agile software development. (See my article about doomed efforts to FFP story points.)
The way I’ve sold this to contracting officers is with this point: When buying custom software, you’re not buying a product. You’re buying a service, the service of developers building software, with features as prioritized by a government product owner.
To many contracting officers, this is nonsense. But to the right contracting officers, they get it. They see how Agile + a time & materials contract allows for extremely close oversight, tight control, and severability for non-performance. It’s safer than FFP.
There’s no way around the disconnect between contracting officers wanting FFP contracts and how software is actually created in the 21st century. The solution is to tackle the problem head on, to educate contracting officers, and let the solicitation & contract reflect the work.
To learn more about this, I recommend “Use time and material contract types for custom Agile software development services” in 18F’s “Federal Field Guide.”