We respond to many Requests For Proposals (RFPs) from organizations of all sizes.
Many municipalities have a difficult time writing, specifying, and managing their Requests for Proposal (RFP) documents.
I wrote this article with the hope of helping someone who is in the process of writing their municipality's RFP.

Here is my top 10 list of RFP tips:

#1. Don't insist on paper copies of the proposals (allow digital submissions)

Paper is not necessary to protect the bidding process
This is one of the reasons why we created a Bid and RFP management feature in our CMS.  In my opinion, paper proposal packages are extremely wasteful, bad for the environment, and drive up your costs.  Paper proposal packages have become an antiquated way of doing business. Many municipal clerks insist on paper proposals so that they can time-stamp the paper bid package. Clerks also have somewhat of an opening ceremony, where the vendor name and cost quote may be read aloud, and then entered into their record once the submission date expires. Again, these are antiquated ways of protecting the bid process. Even if the Clerk has to stamp the proposals when they arrive, this could be handled many other ways. Requiring these paper-based proposals should (and will) start to make the project costs go up. Luckily, more and more RFPs are allowing digital responses. 

You may receive fewer bids
A recent municipal website design RFP that we responded to required FIFTEEN printed copies. Why on earth do they need 15 copies for a small town of under 10,000 residents? My guess (from real world experience) is that they have people on their committee or board that are “old school” or “non-technical” or “not computer literate” (their words, not mine). Those folks like to have the paper in their hands. I don’t mean for that to sound demeaning, but this is a challenge (non-technical board members) that is relayed to us from city managers, clerks, and IT professionals who work for municipalities. This is not a good enough reason to require paper proposals in this modern day and age. Even on some of our smaller projects, we have competed with as many as 25 other firms to win our projects. 25 vendors x 15 copies + shipping + printing costs is too much overhead to put on vendors. The reason why this should matter to you is because some vendors won't respond if they see anything in the RFP that makes the investment (not just money, but time too) risky. I have personally turned down many projects for this reason alone.

Paper proposals are bad for the environment
Most proposals will mostly be thrown away at some point. Not very ecologically friendly. Consider all of the effects to make the paper, deliver the paper, the printer ink, the electricity to print them, the gas to drive to the print shop up the street, the FedEx truck gasoline and exhaust, the FedEx Plane’s fuel and exhaust, the FedEx driver on the other end of the trip. It is just an enormous waste of resources that is completely unnecessary in this day and age.

Paper proposals will increase your costs
For a recent small city project, the total printing cost for us was $366.17. Typical costs are $200-$600 for printing, binding, and shipping a proposal package. That cost doesn’t include the time that we spent at the printers and doing the shipping. So we are into this for at least $500 at this point. Why? Because of the archaic requirements of the city’s RFP. Who ends up paying for these fees in the end? YOU, the client! I will do what I can to win new business, but only to a point. This one was right on the border line because of the small client size. The city could definitely make our job easier.  Here is the irony – How did we receive the RFP in the first place? They emailed it to us, of course. How were questions about the RFP handled? By the city posting responses to questions on their website and through a statewide online bid notification system. Please don’t make your RFP respondents use a medium (paper) that you yourself don’t use. Keep it all digital.

# 2. Have adequate, yet realistic requirements

Size is important
RFPs that we seen range in size from 5 pages to 80 pages. We see quite a range of specifications and complexity.  If your RFP is larger than 25 pages, or less than 10, then you more than likely have a problem with the structure of your RFP.

How to define your specifications
Perhaps have a pre-bid interview of firms to uncover features that you didn’t think to ask for. If you are not an expert on municipal web development, then how could you know the right questions to ask in the first place? “A well designed home page with a rotating image” is NOT an adequate description for a municipal website scope of work, or even a home page layout. Without asking specific questions about the software used to build/manage your new website, how will you know that it will even work properly?

RFPs that are too large
How do you know if your RFP is too large? Anything over 30 pages is probably way too much. There is no reason to include your standard contract in the RFP. That can be a separate document or a hyperlinked document. If your requirements state that the vendor has to sign YOUR legal agreement, then the legal agreement should be a separate document.

3. Have a realist time frame for bid responses

I have intentionally not responded to RFPs that did not provide adequate response times. Ideally you should provide at least a month. Why a month? Because unless you are very tiny municipality, there will be questions and your answers to those questions are important for all vendors that are submitting. One or two weeks is not enough.

4. Don't cheat. Vendors will know. And it will hurt your project.

If you can, be as original as you can be with writing your RFP. It will help to ensure that your RFP closely matches the true needs of your organization. The local government services industry is unique in that premier vendors that have been around a while (I like to thing that includes us) have seen each other's proposals, work, and software. For the most part, we know who our competitors are, what they charge, and what features they offer.  We also know how they describe their services.

Here is why copying feature lists and other RFPs is a problem;

1. Listing a vendor's solution list verbatim in the RFP indicates tremendous bias in the bidding process, because it makes it appear that the organization writing the RFP has already settled on a specific vendor's feature set.
2. RFP specifications that are plagiarized are typically not reviewed closely, leading to wasted time asking for clarification and eventual scope-creep issues with the project later on.
3. The features you request in your RFP may become limited to the list provided, so you could cheat your project out of additional features you should be asking for.

5. Honor the bidding process

In cases where an RFP process is compromised (it happens), a municipality will make up their mind on who they are using as a vendor, but send out an RFP anyhow to maintain the appearance of a fair and legal process. How do I know this happens? Because I have been on BOTH sides of the situation.  “We have chosen your company, but we are forced to put this out to bid, so you will need to submit a bid”. Hearing that never leaves me with a warm and fuzzy feeling. My advice – maintain your RFP integrity and let us earn the work. We don’t mind earning it.

6. Have realistic payment terms

Cautionary Tale #1
We received an RFP from a city in Massachusetts to rebuild their website. They are a popular city that we would love to have in our client portfolio. They held pre-bid interviews to qualify bidders. We were told that we were a frontrunner, and that there was one other company that was close to us (and they mentioned who it was). We reviewed the RFP documents, and had a proposal written and ready to go. But on further review, the last page of the RFP revealed a statement that we didn’t catch at the outset. It went something like this: “Vendor will build the entire website project and launch the website before any payments are disbursed”. I thought to myself “hrm… there is no deadline here.. what if they drag their feet and the project takes a year? Would we still be waiting around to get paid?”. So I called the IT manager, who wrote the RFP and was the designated contact at the city. His response? “No, you have it right. The whole project will be built, finished, and launched before we make any payments.” I replied, “without a deadline, we would be taking a lot of risk and expense at the outset here. This is unusual because if the project is delayed on your side, we are left holding the bag.”. His response was basically “That is our terms, take it or leave it.".  He then admitted that the city "didn't have the money for the website in this year’s budget, so it that is why we have to wait to pay for it". We politely declined the project.  A few weeks later, I received a call from one of the committee members. She said “Why didn’t you bid?!? You were going to win!”. I explained that I wasn’t comfortable with the payment terms and after hearing my logic, she understood. The number 2 bidder got the bid, and I didn’t feel bad at all that they won. After all, they would be tying up resources on this project for probably 8 months or longer with no income from it. Problem averted.

Cautionary Tale #2
We build a website, and the project goes great. The project launches and everyone is happy. Only one problem – we didn’t get the final payment. Our proposals are pretty clear about payment terms. When the last payment became past due, I asked for the payment, and the response was this: “council voted on your payment at last night’s meeting and they voted to not pay it at this time because we had to pay for snow plowing”.

Lessons
When your vendor delivers the services, your should pay them in a timely manner. Don’t put out a bid for a project that you don’t have in your current year's budget. If you need rough numbers to create a budget for your project – Great! Call us, we will give you a quote, and you will get an idea of what the ballpark price will be. But don’t go into the RFP process and waste vendors’ time if you aren’t really ready yet.

7. Have realistic insurance requirements

One of our smaller projects we won last year had a requirement for about $15M in insurance coverage. Everything from car driver insurance, to fidelity bonds, performance bonds, general liability, electronic fraud insurance, it was ridiculous. It turns out that one of the councilpersons is an insurance agent. We met the requirements of most of what they were asking for, and the ones we felt were not necessary we ignored. A web design project is not the same as a project to build a wastewater treatment plant. So please don’t use contract language and requirements from other construction projects for building a website. It isn’t appropriate.

8. Don’t require a design up-front, or multiple designs to "choose from"

We take a lot of pride in our design process, and we provide a fair amount of research and planning before we build a new website. Design inspiration can come from many sources, including; branding guides, photography, websites you admire, photography, and more. So we prefer to use a more procedural process to build the perfect design the right way, the first time. We don't rely solely on pre-built themes like many of our competitors do. One large company in the Midwest literally has 6 design layouts that all sites are built from. That just isn't us.

We just responded to an RFP that requires four designs to choose from for the home page, interior pages, department pages, and application pages. This has the potential to increase the cost by a factor of four, so that forced us to apply a  pricing factor to cover the expense of that effort. The proposal was over $50K. It didn't need to be if the design scope were better defined.

9. Have realistic deadlines

More frequently than I would like, we here things like this: “Our server is bring turned off next month, so we need the new site built within 30 days”. It is possible to do an incremental roll-out to avoid a lapse in your website being live, but that is not the best way to begin a project. But plan on your project taking at least 3 months. That is pretty much standard. No matter how good you think you may be at being organized, putting content together and getting it from your staff can take time. Don’t forget there is time needed to move all old content as well.

10. Get live demos or pay the price

After making the final round of bidders, we have both won and lost projects without ever getting a chance to demonstrate our software, explain our process, or even speak with stakeholders.  That is a real shame. You should ALWAYS conduct interviews and RECEIVE A LIVE DEMO of the software that will be used to manage your website for years to come. Basing your buying decision price alone or potential look of your website alone is a huge mistake. The software, its features, and its easy of use are as equally important as the look of your website. After all - it will be your employees that use it. We have had MANY customers move very handsome websites to us from other providers simply because the other provider had an inferior CMS.

I hope this helps folks that are preparing an RFP. If you have questions or suggestions, please shoot them my way.

John McKown, President
EvoGov, Inc.