How To Fix Procurement 3: Ask for the Right Stuff

This post is written by Clay Johnson, the co-founder and CEO of the Department of Better Technology, and cross-posted from the Department of Better Technology blog.

So far we’ve talked about two ways to decrease government’s IT costs: streamlining the process that agencies use to vet and certify new businesses, and leveraging APIs to make it easier to interface with government for those registrations. These two things are important because it increases competition and thus increases quality and decreases cost. But good information technology at a low price isn’t all we’re after. We also want government to pick the right information technology for the job.

An important lesson If you’re a programmer is to take a look at Recovery.gov, which cost $18 million dollars. But why did it cost $18 million dollars? For the answer to that, let’s take a look at the RFP and the somewhat-redacted winning technical proposal written in response. If you’re a technologist, you might come to the same conclusion I did: Government is paying a reasonable amount of money for what it’s asking. The problem is that it’s asking for the wrong thing. XML Firewalls? Data-cubing services? Seriously?

So how do you fix it? One might say: “hire a consultant to look at the RFPs, and she’ll tell you what you do and don’t need.” But government already has this – both in Technical Representative Programs (COTRs) and in open requests for comments in the procurement process. Unfortunately, each has its problems; COTRs tend to work on COTRing, not on remaining up to date on technology and its costs, and in an open request for information, the people who have the best input are also the people who can do the best job. This doesn’t sound like a problem, but often times you cannot bring someone in to help steer what kind of work to do, and then do the actual work.

The long-term fix for these problems is to partially separate the RFP process from the procurement process. This helps on three fronts:

• It helps get feedback from outside the context of a particular procurement. Instead of commenting on an RFP for “this” website, we can comment on an RFP for “a” website.
• It promotes reuse. RFP content gets written over and over again, without tracking any success or results. This adds expense to the project since a), you don’t know if what you’re asking for is the right thing, and b), you’re doing work that’s repetitive.
• It improves language. By soliciting feedback from a wider community, you stop the atrocious act of using phrases like “Information Distribution and Discovery Platform.” By calling them “websites,” you’ll be using the same language that’s used by folks who do the work regularly.

One way to solve these issues is by creating an Open RFP Library. It’s something we hope to work on here at the Department, and it’s something that others (like Beth Noveck’s WorldBank/NYU Wagner collaboration on Innovative Procurement) are working on too. Imagine an open library for RFPs where a government agency can contribute their documents and share them with other agencies of all kinds, across different levels of government. And where the vendor community, the open government community, and other governments can comment on them and make them better. Imagine if people could ballpark what each RFP should cost, and imagine if you could circle back with them after the job was done to see how the work turned out.

While it would be difficult to show returns in the short term, this is a long-term play that reduces cost by making the requests better and faster. In other words: knowing what to ask for is just as important as asking the right people.

Questions? Comments? Hit us up @codeforamerica.

Original post