Most government software fails at the SOW, not the standup
The decisive failures in government software happen in the contract language, months before any team writes code. Where it goes wrong, and what good acquisition actually looks like.
I once watched a program spend two years and several million dollars building software that did exactly what the contract asked for and was still useless. Nobody on the delivery team did anything wrong. The agile ceremonies ran on time. The burndown charts looked healthy. The outcome was settled long before the first sprint, written into a Statement of Work that no one with engineering judgment had read closely.
This is the part of government software delivery nobody wants to talk about, because it isn’t where the visible drama is. The drama lives in the standup, the demo, the milestone that slips. But the decision that determined whether the program would work got made much earlier, in a document most engineers never see and most program staff treat as paperwork.
The SOW is the real design document. Whatever it says, and whatever it forgets to say, becomes the thing you are contractually owed. Specify deliverables by their format and you will get exactly that. “The contractor shall deliver a requirements document” produces a requirements document. Whether that document describes software anyone needs is a separate question the contract never asked.
Most of the damage I’ve seen traces back to three habits.
The first is writing requirements with no engineering voice in the room. Requirements get drafted by people describing the solution they already pictured rather than the problem they actually have. The contractor, doing honest work, builds the pictured solution. It arrives on schedule and fits nothing.
The second is acceptance criteria that can’t be enforced. “Shall be intuitive and user-friendly” is not a criterion. It’s a wish. When delivery day comes and the product is mediocre, you have no contractual footing to reject it, so you accept it and move on. The leverage you needed was supposed to be written down months earlier. It wasn’t.
The third is a contract structure that fights the nature of the work. Software that genuinely has to be discovered as you build it does not belong inside a vehicle that assumes fixed scope priced up front. Every thing you learn becomes a modification. Modifications are slow, expensive, and politically draining, so teams stop learning out loud and start hiding problems until the next funding cycle.
None of this gets fixed in a standup. By the time people are standing up, the costly choices are already behind them.
What good looks like is less exciting and far cheaper. Get someone who can read architecture into the SOW drafting before award, not as a reviewer brought in after the fact. Define each deliverable by the outcome it produces, and write down how you will decide whether it’s acceptable in terms specific enough to survive a dispute. Match the contract to how the work behaves, so iterative work sits in a vehicle that tolerates iteration. Treat the initial requirements as a hypothesis you intend to test in the first months, not a stone tablet to obey for three years.
The highest-leverage hour on a government software program is usually spent before the program officially exists, by one person reading a contract draft and asking the questions an engineer would ask. That hour rarely shows up in anyone’s metrics. It is the whole difference between a program that ships something useful and a program that ships precisely what it asked for.