Reader reply: Federal procurement is the problem.

Jonathan Shepard replies to Dear Bureaucrat’s column on a useless computer system:

While you’ve identified some useful workarounds here, I do believe that the root cause of this problem (across the government) is a fundamental mismatch between the strictures of the federal procurement process and the software development (and support!) lifecycle. As you know, when federal agencies need to procure an IT product or service, they have no choice but to go through their agency’s procurement systems, often with a set of half-baked requirements. Nothing inherently wrong with half-baked requirements; many requirements (even in the most innovative companies) are only partly articulated until they get deeper into product development. That’s why there is such a thing as agile software development. But the problem is that the federal contracting process is fundamentally ill-equipped to support agile software development. And as the example you cited demonstrates, there is little consideration in most federal contracts for ongoing support and evolving needs. Federal IT systems are generally regarded as one-time “projects” in a project management sense. They are not. They are products with sophisticated users, evolving needs, and changing requirements. A FOIA request management system is a product in the same way that Uber (or Gmail) is a product.

Federal IT systems are inexcusably terrible. I am a former PMF, currently working in the tech sector. The “technological” challenges facing federal agencies are (for the most part) very solvable, sometimes laughably so. If tech startups were able to compete in a truly free market for federal agencies’ business, judged solely on the quality of their products and customer satisfaction, it could revolutionize federal IT systems and bring them up to par with the private sector, probably at a fraction of the cost currently being expended by federal agencies. But there simply isn’t a way to do it today, with existing procurement processes. Great developers don’t bid on RFPs. Great developers make great products, and let them speak for themselves.