Is responding to RFPs a waste of time?

By Deane Barker on October 21, 2008

I was having an email exchange with my friend Kevin Shoesmith. He knew I had been with the guys at silverorange, and he pointed out a blog post from Dan James earlier this summer, about how to grow a Web development company.

One of the pieces of advice he gives might be shocking to a lot of people:

Don’t bid on projects, respond to Requests For Proposals (RFPs), or do mock ups for free. Number of proposals silverorange has written in nine years: 20-30. Number of projects silverorange has won by writing proposals: 0.

I was a little taken aback by this. No RFPs? Isn’t that how stuff gets done?

I mentioned this to Joe today, accompanied by “isn’t that nuts?” or something. But Joe responded thusly:

Well, remember that we’ve never won a wide-call RFP.

I was a little stunned, but he’s right. We have never “won” an RFP process at Blend, despite completing 12-15 of them. I know David complains about them as “cattle calls,” but I thought for sure that we had landed at least a couple deals from them.

But no, the RFP response effort at Blend has been a total bust over the years. And they’re so time-consuming — to really respond well to a typically in-depth RFP is a 6+ hour proposition, stretched over several days as you go back and forth, getting questions answered, rolling the dice and guessing on hours, etc.

As for never writing a “bid,” I’m not quite sure how they get away with that. We write “bids” all the time, though they’re usually just comprised of a couple pages that essentially say, “this is our basic understanding of what you want to do, and this is roughly how much time we think it’s going to take, and how much it’s going to cost, but this is just an estimate…” A lot of companies need these for internal documentation, budget approvals, etc.

But, the traditional RFP process — is this a complete time-waster? I mean, someone has to be winning these things…right?

Gadgetopia

Comments

  1. Problem with wide-call RFPs is that very often client already has an idea who he would like to hire. RFP becomes a way to make sure that pre-chosen provider isn’t overcharging and to have backup proposals if something goes wrong.

    Personally, I don’t do wide-call RFPs. Instead I have a sort of pre-screening process for potential clients. First I have a short talk (or exchange couple emails) about gist of the project and perhaps throw in some ideas/suggestions regarding the project.

    Next, I give them a very, very, very rough estimate just so they know what kind of budget they are looking at. Then I write a short bid, just one or two pages (similar to the bids you mentioned), that contains a more precise estimate.

    Finally, if needed I write a full proposal outlining whole project in details, including final estimates.

    Of course during each step I ask client if they want to proceed. This does wonders to filter out clients. :)

  2. We only do RFPs when we helped write them and are positioned to win. And that is only when the prospect has said that they need to do them as part of their process.

    So many companies spend more on the procurement process than they do on the software/services that it is getting silly. A lot of the times it seems like it is just a contractor looking for more bailable work. In then end, I think they are just used to negotiate a final price.

  3. I love Joel Spolsky’s take on RFPs. He describes it as something where a “…small company works on the 200 page laser-printed proposal like mad for three weeks and Fedexes it in great expense and at the last minute, where it gets put in the trash because the large company has their favorite vendor who takes them on a helicopter to Atlantic City on junkets involving blackjack and strippers…” http://www.joelonsoftware.com/articles/FogBugzI.html

    I procure via RFPs (frequently!) and my attitude going in is that I only let an RFP if I am confident that there is at least one vendor who is capable of performing the work. I then welcome the possibility a vendor other than the one I thought of wins.

    Sadly, RFPs regularly come in that make me wonder, “Did they even read the RFP?” For example, I might identify Java expertise as a mandatory, but some people will submit on the possible assumption that nicely bound, shiny, full color docs are a substitute for the requested skills.

  4. I totally agree w/ the above poster’s quote from Spolsky. I’ve ben involved on both ends of the RFP process, and as filler-outer, we knew the likely outcome more often than not. Sometimes we had an existing relationship with the requester, sometimes it was clear that they were simply out to get enough responses. In that business, though, the RFP cycle was the only way things got done.

  5. I agree with David K.. Not all RFPs are worth responding to. I have both written and responded to several RFPs. I actually enjoy preparing the response, as it often represents the “start of the game”.

    One of my favorite responses was when I was working for a small CTI / IVR company. Through the RFP process we took on a very large Telco and a very large (& blue) services company. We were invited to the table because of the RFP response. Subsequently we stayed at the table because we did a great first presentation. We eventually won $2million plus in business because we had a great sales person who made sure he built relationships with the client and kept in communication with them.

    Dave J. http://www.marketgogo.com

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.