How Government Software Procurement is Not Like Buying a Car

I've been thinking about government IT requirements lately.  In my mind, the process of getting something purchased in the government is a little like the following analogy.

You need to buy a new car.  Step one: tell the manufacturers and dealers that you have money and want to buy a car.  Step two: ask them about the state-of-the-art technology in cars.  Step three: formulate a list of what your new car has to be able to do.  Now that you've decided what you need and what can be done, you come up with a budget.

It has to be a complete list of requirements, because once you are done with it, it will be handed to a group of expert buyers.  They will go to the dealers and manufacturers get you the lowest priced car that meets your list.

Oh, and you can't specify a particular car.  You can't show preference to a particular manufacturer  without going through a long process of explaining why Audi is the only source that satisfies your requirements. It’s all easier said than done.

So what you will get is a car that will do exactly what you said it needed to do, made by someone, possibly a major manufacturer or maybe a small boutique shop), who came in with the lowest price that satisfied your list.  If you didn't specify the number of wheels, it may have three; it may have six.  The process is designed to protect the interests of the program while complying with spending legislature and preserving competition in industry.  And it’s all required by law.

This may work fairly well for buying gears, and gadgets, but what about software?  

I'm fond of mutilating Carl von Clausewitz’s saying: "No requirements list survives first contact with the user."  Over-specification on requirements only fosters scope creep and feature bloat because every potential stakeholder gets equally weighted input.  Or you wind up "shooting from the hip." Both accusations have been levied against the FBI's Virtual Case File system.  With your budget tied to the requirement specification, you aim for the largest possible scope in order to secure the largest possible budget.

Software is more fluid than people often realize.  If you consider the current state of Facebook, do you really think they have been toiling away at a complete requirements doc set down by Zuckerburg 10 years ago?  Of course not. It's evolving as users drive changes to the system by using it.  And it's not just Facebook; the hottest thing in software venture is still the minimum viable product.  This is not a new idea, but still a highly effective way of determining what features people are actually willing to pay for.


Dan Risacher has an interesting way to address some of these issues without rewriting legislation. In that post, he calls attention to a particular project that has been successful in divorcing mission from requirements.  Getting the budgeting horse before the detailed requirements cart is key in the model Dan proposes.