Why RFP’s don’t seem to work

When ColoAdvisor was in it’s “v1.0″ stage (like a week or 2 ago), we offered a consulting engagement that involved the creation of RFP’s for clients seeking hosting or colocation services. Recently we removed this from our offering because we felt that RFP’s weren’t effective in getting the required info from vendors. Here’s a few ideas as to why RFP’s are even issued:

1. to let folks know that you are looking at numerous vendors

2. to attempt to capture like for like service quotes

3. to get in writing what the service offering will be

4. to ensure you reach out to many vendors in that particular space

5. to get competitive bids in writing

6. to gain in depth knowledge about the provider in writing.

7. To get a favorable deal for the firm overall.

As consultants, we felt that if we did put together an RFP for a client, the only way to charge a reasonable amount of consulting hours for this would have been to build a massive document full of appendices, references, spreadsheets, diagrams and lists that would need to be filled out by perspective vendors. While this ensured lots of consulting hours could be billed for our effort, did this really get our client the proper tool to find the best hosting or colocation provider? Being on the receiving end of many RFP’s in a past life, I know several things held true:

1. The RFP broke out our services in a manner different that how we delivered it.

This forces vendors to break up their products in weird ways to match the response in the RFP. This disguises the delivery model of the vendor and may be a sign that another vendor was involved in the creation of the proposal. Another thing vendors will do is just to answer the question with a canned response that doesn’t address the specific request.

2. The RFP asked for client references right in the document.

I used to answer 1 – 5 RFP’s a month. Had I actually put references in each response, my clients would have killed me (or started to bill me for their hours of answering emails/phone calls from potential clients).

3. The RFP was way too long.

We’d start answering all of the questions in earnest in the beginning of the document, but as we grew sick of the redundant questions, we’d begin to put in the bare minimum needed to convey an answer. In many cases we’d put in something like, “please refer to section 5.6 for the response to this question”. We felt that any firm that successfully answered all the questions could only do so because they had an RFP response team in place.

4. The RFP focused on everything but the technical solution.

100’s of questions about financial stability, Sarbanes-Oxley and legal issues but no clear questions or even a space to write about the technical solution. Even better are RFP’s that paint 10% of the technical picture and include a section that prospective vendors need to fill out for pricing.

5. Little or no allowance given to actually discuss requirements verbally

There are sometimes vendor conferences that allows for vendor questions during the RFP process, however in many cases we’d refuse to ask good questions because it would give insight to our competitors on how our service worked. We’d prefer that everyone be kept in the dark about a specific question allowing us to make assumptions. Other folks would ask the questions to show off to the client as if they “get it”.

6. The RFP timelines were far out into the future.

We’d get lots of RFP’s that stated that the decision would be 6 to 12 months away. While I am a big believer in building future pipeline, so many things happen in a year. Too much revenue at stake right now to answer RFP’s that are slated for a year out decision. That is, unless you have an overworked RFP team you can dump the work on!

7. The RFP allowed no room for free form thought or suggestions.

I remember when I was 17 years old, I decided that working for the local hardware store for $4.30 wasn’t cutting it. I started my own lawn service using my parents van and their lawn mower. I designed some killer invoices that were customized with my logo so I went to a print shop with my design for the form. For the next year I had to make a box for the subtotal and total on the invoice because the printer didn’t stop me and say, “hey, I don’t want to tell you how to run your business, but wouldn’t a ‘total’ box on your invoice be a good idea?” I guess my point here is that sometimes the vendor has a real clue as to what works and what doesn’t. RFP’s sometimes don’t allow free form thoughts to flow to the RFP issuer. This is particularly true for RFP’s that request responses to be pushed into an excel document.

8. The RFP clearly is written by someone who doesn’t get it

I’ve had RFP’s cross my desk that were poorly written. The questions in it clearly showed that the client had never sourced a similar product before and their questions were irrelevant. Most vendors will answer out of courtesy with some generic responses. It would be impossible to put together a solution based on the lack of details from the client.

I guess I could keep writing more about this, but I think the gist of this post is the following. Here’s what your RFP should look like IF you choose to issue one:

1. BRIEF background on the goal of the project

2. Minimum requirements section that allows a freeform dialog from vendors worked as such, “hi, these are our minimum requirements, we expect if you meet, fall short or exceed these requirements to elaborate in paragraph form using less than one page.”

3. Specific diagram or request for a technical solution that the vendor can follow – a phone number should be provided for questions to be answered (or at least an email address).

4. A request for pricing in the format that the vendor choose (be sure to emphasize that unit costs must be shown).

5. Another freeform section that allows vendors to elaborate as to why they are the vendor to choose. In this section they are welcome to use anecdotal stories, client references or just some good decent writing. Maybe a killer case study would be good here.

The RFP should be distributed in WORD format and vendors must keep their entire response to less than 7 pages. Feel free to warn them that marketing slicks that use buzzwords from Dilbert will immediately get them disqualified. :-) We feel that this type of RFP will get you far more mileage and a good understanding of the marketplace out there.

If you’d like a sample template to use for an RFP, email us at info@coloadvisor.com and we’ll send one to you. For our services that may eliminate the strain of running an RFP process, check out our services section at http://www.coloadvisor.com/services/ .

Update 1/21/2013

We’ve gotten so much feedback (and this blog article) on RFP’s that we launched a service that allows ColoAdvisor to tailor make an RFP for your business.

 

Share This Post - Tweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone
About Shirin

Shirin started selling and designing web architecture in 1999 for UUNet Technologies. His belief is that leveraging service providers to host IT infrastructure is more cost efficient and practical for most firms.

Speak Your Mind

*