Re:Typical government efficiency... (Score 5, Insightful)

This is less of a "government efficiency" issue than it is a "contracting" issue.

Imagine you have a gigantic system like this that you need to replace. So you want to hire someone to build the replacement. You can't just go give $1B to company X and say "I'll see you in five years when you've built me a new pay system" - the taxpayers (and their representatives) would never go for that. Instead, you first go build a set of requirements that such a system must meet and then you award the contract to build the system to the company that convinces you that (a) they'll build the system that best meets those requirements and (b) they'll do so in a cost-competitive way (if not cheapest, then close to cheapest).

Therein lies the crux of the problem - building large complex software systems over multiple years "to spec". In short, it can't really be done:

• 1. You won't get the requirements right. At best, if you spend a ton of money, you'll get a decent set of requirements, for some narrow segment of your user base, that is appropriate for the state of the world at contract award. But they'll be woefully out of date by the time the system is actually built. More often, you won't pay enough money and you'll get an RFP that is 50%+ "cut and paste" from previous RFPs, and has only a passing resemblance to what is really needed.
• 2. Managing a multi-year software development project is tough enough when you're the one building it. It is many times more difficult to try and look over a contractor's shoulder and make sure that they are (a) meeting requirements, (b) meeting schedule, and (c) not wasting (or stealing) money. This is even more difficult when you have thousands of crappy nonsensical or ambiguous requirements (the norm for such large systems).
• 3. Even if you get decent requirements and decent/lucky contract management, you still have huge product and engineering hurdles that don't often show themselves until you get the software in the hands of real users. And (more often as not) find out that it doesn't work for them.

I've only ever seen one model work successfully (in my time in the USAF and as a contractor):

• 1. Put organic (e.g., military or civil service, not contractor) resources in charge of the system development.
• 2. Don't try to spec and build the system as a whole unit. Instead, start with something small and easily defined and then work *directly* with end users to evolve and enhance the system over multiple years. At some point in the evolution of the system (neither the beginning nor the end), you make the call that the system is functional and stable enough to deploy.
• 3. Use contractors as labor, project-managed by your organic resources. This tends to mean fairly integrated teams (organic and contractor) and a different sort of contract vehicle. It also means that swapping contractors out is actually feasible and doesn't cause the failure of the entire project.

The above system works beautifully. And Congress, contractors, and contracting agencies within the military hate it. Which is probably why it isn't done more often.