Civic Innovations

Momentum seems to be building around public sector procurement reform.

Governments are starting to experiment with new ideas and new approaches to procurement that hold the promise of streamlining the process for bidders and producing better outcomes for public sector purchasers. Startups are emerging with new tools to make the procurement process easier, and the issue is on the radar of public sector innovators.

But with all of the focus on improving the procurement process – making it more transparent, more streamlined and simpler for bidders and governments – I think there is a case to be made that in order to improve the public procurement process we have to make the process harder. Let me explain.

How can governments responsibly evaluate proposals for work when they are not able to effectively and clearly articulate what it is that they want?

One of the biggest problems with procurement is how Requests for Proposals (RFPs) get written. Having written and responded to state and local government RFPs, and having evaluated more vendor proposals than I care to remember, I have a pretty good sense of how most RFPs get developed.

It essentially boils down to this: copy + paste.

Most government RFPs begin as a template that is provided by a procurement or legal department. Much of the content in these templates contains all manner of byzantine legal language that includes specific things vendors must do, information on how and when and in what manner to respond, etc. Much of this language will not change from RFP to RFP, and most governments typically employ language that is tailored to their own local processes and requirements.

The heart of any RFP is what is usually referred to as the “scope of work” – the section of the document that is added to the initial template that describes the specific deliverable(s) that a vendor is to provide. This is the most important part of the procurement document because it describes the thing (or things) that governments want to purchase with taxpayer money.

Yet all to often, this core piece of the RFP document gets cobbled together by looking at other RFPs that have been issued for projects that are further along in the development cycle. If another RFP – so the logic goes – was issued, received responses and has moved into the work phase then it might have language that can be reused in a new RFP, particularly if both are for similar kinds of projects.

So, for example, if a government agency or department wants to build a web or mobile app, construct a data warehouse or obtain an analytics tool they simply need to go and find and RFP that was issued for a similar project and use that as the basis for building the scope of work for a new project. And while there is some value in identifying RFPs for similar types of projects to help ensure that language used across different projects is consistent, I think this practice is dangerous and leads to bad technology choices.

Far too often, the process of writing what is essentially the heart of an RFP is done by simply copying and pasting text from other documents that have progressed to a later stage in the process.

This means the author probably has very little idea what they are really asking for – the process requires no effort on the part of the requesting agency to clearly describe what it is that they hope to get from the RFP. How can governments responsibly evaluate proposals for work when they are not able to effectively and clearly articulate what it is that they want?

This is the part of the procurement process that needs to get harder – we must avoid the temptation to create shortcuts that gloss over this important function of accurately and clearly describing what it is a government agency hopes to get from engaging with an outside vendor.

Part of the reason that governments are lousy at describing what they want – particularly from technology vendors – is that there is a lack of people in government with hands on experience building or maintaining technology. There is a dearth of makers in government.

Until we find better ways to more broadly raise the technology IQ within governments – by bringing more hackers and makers inside government, or exposing those already inside to the hacker culture – we’ll continue to see copy + paste RFPs and poor technology selection by governments.