Waldo JaquithBlog entry: It's a mistake to include a detailed list of deliverables when procuring custom software. https://waldo.jaquith.org/blog/2026/04/detailed-deliverables/
When procuring custom software, agencies commonly make the mistake of contracting for detailed deliverables. They think “our existing system has 16 workflows, so let’s require those the contract for the new system, so that we’ll know we’ll get all that functionality.” This ends badly.
The core proposition of an Agile contract is this: Instead of defining lots of requirements, those are introduced as user stories throughout the life of the project, based on constant user research, prioritized by a government product owner. When you define requirements up front, they'll be wrong.
In the case of those 16 workflows, it would be a real victory if user research found that, actually, only 9 workflows were needed. That's faster to build and cheaper to maintain. But only if the contract allows building just nine! Did it specify 16? Well, then you're getting 16 now.
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. This restores control to government.
...Unless you also tell the vendor that they must complete particular objectives. Then you’ve just destroyed that model. Now the vendor has to ignore the PO 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.
Every requirement is just tying your own hands.
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.
~fin~
Adam Millerchip@waldoj I guess it's a pretty hard sell to say, so you've identified you want to solve a problem with software. But... you're not allowed to ask for a specific solution, or schedule, or budget.