RFP Process Muddled by Misconceptions and Inefficiency

For more than two months now, CodeTalk has covered topics related mostly to the editing side of the codification industry and the services Code Publishing offers to customers. Today’s post focuses on the sales side of the business.

Codification sales reps generally have two ways of making bids to potential customers. First, the tried-and-true method of cold calling and e-mailing, which establishes a more personal connection between sales people and customers. These calls go out to cities and counties regardless of how their code is currently maintained – either in-house or published through a professional codifier. The other method is to respond to a Request For Proposal, or RFP.

Code Publishing Company has responded to hundreds of RFPs over the years. Some customers send out an RFP every year, some every five years, and some just once. While almost all RFPs include similar basic criteria (cost, production schedule, credentials, etc.), no two are alike, as each one has specific instructions tailored to the needs of that potential customer.

Responding to RFPs can be time consuming, thanks to the variation in content. Depending on the size of the city or county and the scope of work, it can take anywhere from a few days to a few weeks to put together a high-quality, professional response.

Unlike the college application process, which has been streamlined, consolidated, and made simple for high school seniors, local government RFPs for codification are all over the place. It’s unclear why this is so, but here are two possible explanations:

  1. Outside of professional codifiers, nobody really knows what codification is. This is especially true of purchasing departments. In the past, some of the questions we have been requested to answer have had nothing to do with codification.
  2. Some RFPs seem to think codification is a Software as a Service (SAAS) project. It is not. Codification is about taking ordinances from local jurisdictions and putting them in a code. In the past, the codes were printed. Now, they are on the web. For some reason, jurisdictions equate the web with software.

While it’s true that a codifier uses software to produce the code, in most cases the web-based codes are static HTML/XML files updated as new ordinances are passed. A really good codifier will offer a myriad of bells and whistles for the online code, but it’s not the same thing as an executable deliverable the way Granicus, utility software or permitting software works. The “executable” software is installed on the customer’s network system and users will need to log in and activate the software, much as one uses Microsoft Word. Online codes do not use software which is executable.

[image via]