Why Government Spends So Much on Software
- Written by
- Clay Johnson
- Date
- 07/13/2009 2:43 p.m.
Government spends a lot of money on software: $8.5 million is the price tag for Recovery.gov which is reasonable given what the Government is asking for. The White House Content Management System has a 16 Million contract on it. Or how about the 15 million dollars various agencies have spent this year on Sharepoint.
You may blame this on people saying "incompetent government bureaucrats are getting robbed by beltway bandits," but that's not usually the case. Now I'm certain there are incompetent people that work inside the government that are getting fleeced by contractors, but there are incompetent people everywhere getting fleeced by consultants. This isn't a problem of people: this is a problem of process. The real problem is one-size fits all regulations and procurement. Government asks for too much, in too short of time, and regulations require software to be too good at launch. Since a picture is worth a thousand words, perhaps a picture of the problem will better illustrate:
That's a flow chart of a procurement process. The end result of this process is expensive software that tries to do too much and none of it very well. If you want to keep your eye on the thing we have to change, print out this image, and hang it on your wall. Right now procurement is governed at a base by the Federal Acquisition Regulation, hundreds of pages on how government can procure just about anything. Non exhaustively, there's also the Clinger-Cohen Act of 1996 which delineates the responsibilities of CIOs and creates, legislatively, the Federal Enterprise Architecture. and, you've got to take a look at the Paperwork Reduction Act. That's a fairly big web. To truly understand why government spends so much money on software and where a lot of cost comes from, read these docs.
This is why things like Apps for America 2 are important-- see this isn't just about celebrating Data.gov but rather about creating a demonstration to the government. We're going to show Government a better way-- one model, outside of the current procurement process, that can work. This is the first time in history that government will be able to see what happens with a truly open process. Contests are one new model for procurement, but there are others, too.
So if you're a developer thinking that it is outrageous that Government is spending so much money on software, the best thing you can do is develop an entry into Apps for America 2. It is a way to shortcut the system, show the government what you can do and if you win, get in front of the right people. And if you don't, at the very least you've contributed to a body of evidence-- exhibit A if you will-- that will show Government what is possible.
P.S. If you're interested in a high resolution version of that chart, it is available in .ppt
Discussion
What are Your Thoughts?
Comments have been closed on this post.
I've always found it kind of interesting that government regulations exist in publicly-funded health insurance programs that require the use of "generic equivalents" in place of name brand drugs where they are functionally identical.
I've always thought it would be interesting to apply this concept to government software procurement.
If there is a functional equivalent to a commercial, closed-source application shouldn't there be a requirement to use it for government funded technology projects?
Just saying...
Very helpful. Just working on an RFP from a local municipal government. Must investigate Apps for America 2. Thx.
Here's the chart as a JPG, 4,000px wide.
It's worth considering, also, that the government is constrained to use the same process for all kinds of software.
The way you design, build, and deploy a small data visualization application is obviously not the same as a national-scale tax revenue tracking system (or the guidance logic for an intercontinental missile, for that matter).
Perhaps what we need is a conversation about when a phased, design-heavy approach to software is helpful, and when it is not?
@Mark Headd: That's an interesting idea. It could be expensive for the government agency if there is a significant integration component, however -- much of the cost is not in the initial software development, but in working out the kinks when you try to plug it in.
Michael, funny that you cite it as an example, but perhaps in light of their $4 BILLION dollar Tax Systems Modernization project failure last decade, the IRS might disagree that a phased, design-heavy approach probably is the way to go when you have extremely complex software requirements.
History is littered with the carcasses of large, bloated software engineering failures - our federal government has produced so many classic examples it's (almost) not funny - the number of writeups and case studies of the FBI VCF failure is ... well, educational.
That being said, we also know that there is an alternative methodology that has been much more successful - in fact the most successful (and probably largest scale) software effort ever with the UNIX->INTERNET->WEB lineage.
It's been particularly enlightening (and humbling, not to mention a bit terrifying) as a practicing developer and architect (and having seen first hand what software that touches half a billion lives a month looks like).
In the past there's been little crossover in terms of recognition within the (failed) enterprise world with this model, but the leaf has been turning - mostly by necessity. Beyond a certain level of complexity, the older monolithic/"classic" development models just don't work and the open standards, open source, "small pieces, loosely joined" ecosystem model does.
YES, YES, YES!!! Now you are asking the right questions and looking in the right places.
Initial attempts to bid this and later complaints when the award was announced showed how unfamiliar you were with the acquisition process. Now you're looking in the right places.
The process makes things outrageously complicated - and there are vested interests on all sides of it that benefit from the complexity. Just a few groups:
government employees who understand and work this complicated process
government organizations whose ensured existence is preserved by the complexity
contractors who understand and are experienced with this process. It is a huge barrier to entry to potential new competitors.
Keep looking here and asking questions here. There are some pockets in each of the groups seeking to change the process, but they need visibility and help.
For a fun exercise, try to figure out who built, and how much it cost to build, the graphic you have posted. I'm sure you'll be amazed by how much it was all in. It may make $8.5 million for a web site look reasonable.
I think the heavy focus on process has in part been because the Gov. has been fleeced before.
Attempting to codify who, what, where is admirable (but usually a lost cause) but I think this belief that process can be crystallized extends beyond government.
Talk to any large corporation and you'll see the same belief that people's jobs can be reduced to as much "if -> then" as a game of shoots and ladders... in reality it just comes out as a bad game of "Sorry"