We respond to many Requests For Proposals (RFPs) from municipalities 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 too many paper copies of the proposals

This is one of the reasons why we created EvoBids - our own turn-key bid posting and management system. 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 exprires. Again, these are antiquated ways of protecting the bid process. Stilll, to this day, almost every RFP we receive requires “X number of printed and bound copies”. A recent municipal website design RFP that I responded to required FIFTEEN printed copies. Why?

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 committees 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 paper proposal 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.

Most proposals will mostly be thrown away at some point. Not very eco-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.

Below is a photo showing what the cost was to print and ship this one proposal.

cost.jpg

$366.17 is pretty expensive for a print package that will be thrown away after it is read. 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? The client. I will do what I can to win new business, but to a point. This one was right on the border line because of the small client size.

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. Please don’t make your RFP respondents use a medium (paper) that you yourself don’t use. Keep it all digital.

PDF files are much better for proposals. They can be emailed, searched, printed, and viewed on many different devices.  The PDF could also contain hyperlinks, which would make it more useful. If your committee members are non-technical, then you might want to ask yourself why they the ones evaluating a technical solution. These paper proposal requirements should go the way of the fax machine.

TIP
Do not scan documents into images for your PDF.
Make PDFs directly from a Word Document to keep the file size small.
PDFs made with images are also not searchable.

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. We have had some proposals that allowed us to respond digitally, and I look forward to getting a more forward-thinking RFPs soon. 

2. Have Adequate, Yet Realistic RFP Requirements

The bid package above was in response to a 5-page RFP document. The largest one I have seen? 65 pages. The average size? About 12 pages. If your RFP is longer than 25 pages, or less than 10, then you more than likely have a problem with your RFP.

When is your RFP is too small? - When there are so many requirements today for a modern web design project, such as; CMS features, mobile responsive websites, tablet websites, design, terms, features, timeline, social media, usability, structure, etc., then you can’t really specify those requirements in just 5 pages. Something is missing. Sales inquiries that state "we need a price on a basic website" don't cut it. We are very transparent with our pricing (http://evogov.com/pricing), and we post our pricing on our website. Our competition does not do that. 

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?

How do you know if your RFP is too large? Anything over 30 pages is probably way too much. Don’t use a construction project proposal that has nothing to do with a technology project and that requires insurance bonds. You aren’t building an office building that requires millions of dollars in many different types of insurance, so please don’t ask for it. A common requirement that is completely baffling is the requirement for us to have auto insurance for the company, when we are not driving to the municipality and we do not have a company vehicle. These are construction company requirements that are inappropriate for a website project. 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 Realistic Response Time Frame for Bids

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. PLEASE Write Your Own RFP, and Don’t Copy Feature Lists from Provider Websites

The largest RFP that we ever received was for a very small city. It had every possible bell and whistle thrown into it like a pot luck soup. It was blatantly copied from previous proposals, provider websites, resources that were found on Google, and even from active responses to the bid itself.

Please write your own RFP and don’t plagiarize one.
Here is a heads-up: We have proposals from all of our top competitors.
If you copy their proposals or website content for your RFP, we will know.

We know who our competitors are, what they charge, and what features they offer.  If you use the feature list from a provider’s website or proposal as  your RFP scope, it makes it impossible for us to take your RFP seriously and we will probably enter a no-bid on your project. It also raises red flags that your bidding process might be tainted and that you entered the process with a pre-selected vendor. Some of the features listed from our competitor also make no sense, which could affect your requirements.

Here is an example of a plagiarized feature that we commonly see, which we have yet to figure out: "Content publishers should have the ability to assign multiple content records to a single link, allowing for rotating content".  Why would you want your municipal customers to get a random web page when they click on a link? We have content sliders that animate the display of news and information, slideshows that customers can place into pages, but this requirement continues to baffle us. We know which vendor wrote it, and its disappointing to see people copy and paste this goofy feature request into their RFPs without ever really reading it. I'd love to hear why a municipality would want this, so please email me if you disagree with me on this one.  

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. It is becoming less common, but it still happens. “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. Be Realistic with your 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 six months or even longer? Would we still be waiting around to get paid?”. So I called the 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 are 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. We don’t have the money for the website in this year’s budget, so it will be paid for after the site is developed”. Aha! That is the true reason for this absurd requirement! 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.

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 this – the website does not go live until all payments are made. But we weakened and bent the rules because the city had an event that they needed to promote. 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”. Lesson learned. Websites will not launch without final payment - no matter what. 

The lessons? When you vendor delivers goods, pay for 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. Be Realistic with Your 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

We take a lot of pride in our design process. We do a lot of research and planning before we build a new website. They don’t usually come from templates, downloaded themes, or thin air. They come from careful planning, interviews, and research. So when an RFP basically says “show us what our new website will look like”, it is pretty laughable. I think that if a vendor tries to whip up a design without a solid process, that should be a warning sign to holes in their process. Perhaps they are just hacking templates to build websites? I’m not sure. But this requirement will cause you to lose bidders for sure. Or, perhaps committee members just want a “pretty picture” and they are basing their decision on that alone. The danger there is that they are probably not paying attention to the features or ease of use of the website management software, the usability of the website, the migration of content, and the myriad of other considerations that go into a high performance website. Asking for a concept without planning is not a good idea.

9. Be Realistic With Your Development Deadlines

Just last week I had a conversation with a city that went something like this “our server is bring turned off next month, so we need the new site built within 30 days”. I asked him what medication he was on. After further discussion, we came up with a plan to do an incremental roll-out so that their site would not go down. Their current website is very unattractive, so replacing it with a basic temporary site would work for them. But plan on your project taking about 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. Ask Questions and Conduct Interviews

After making the final round of bidders, we have won and lost projects without ever getting a chance to demo our software, explain and our process, and discuss design elements with the people making the decision.  That is a real shame. You should always conduct interviews and get a live demo of the software that will be used to manage your website. Basing the decision on a portfolio design without knowing how the back end works is like buying a car without driving it.

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


Posted in: