Sales · Project management

Why RFPs Suck?

George White Technology Enthusiast & Entrepreneur

September 7th, 2016

I found this interesting post on RFPs (Why RFPs Suck).  Pause. Can we all just take a moment on how much we dislike dealing with RFPs?  Thank you.  They're boring, lengthy, and they get you absolutely no where with your vendor.  But I feel this post might have a solution for it, let me know what you guys think?  Do you think this whitepaper has an apt solution or no?
A great idea is 1% of the work. Execution is the other 99%. In this course, we’ll teach you how to conduct market analysis, create an MVP and pivot (if needed), launch your business, survey customers, iterate your product/service based on feedback, and gain traction quickly.

Neil HereWeAre Want To find-close Business Online without competition Before They Google Search? We solve this problem 1(508)-481-8567

September 7th, 2016

How to Manage an RFP and instead, Write a Winning Proposal: Expert Advice

A recent post that contained a sales proposal checklist resulted in a comment in CBS Money from frequent Sales Machine contributor Neil Licht that's so useful, I've edited it and bumped it up to a full post. Here it is:

Q: What's the best way to get rid of a sales person

A: Ask them to write a proposal.

The truth is that sales professionals rush out to write a proposal or answer and RFP because they think it's a good way to win the business. But in most cases, it's just a waste of time.

Before you even think of responding to an RFP or writing a proposal, you need to know the price point, why the RFP was issued, by whom, purchasing or an actual decision maker, what the customer values, whether there's money available, whats the actual price point. And that's the minimum.

Beyond that, you'd better take a good hard look at the RFP. Many RFPs are "front loaded" so that they're actually just a specification that both the decision maker and your competitor have already agreed upon. When you read the RFP, look for the following:

--Exact recipe language that comes from the competitor's literature (but with the brand names removed).

--Strong statements like "no substitutes" or "no alternatives" scattered throughout the document.

--Short lead times for answering the RFP in order to make it more difficult for other vendors.

If you find these elements, it's probably too late for you to win the business. In fact, as a general rule, if you didn't write the RFP yourself, you are probably too late.

But let's suppose that you think you've actually got a chance to win the business. Maybe you've got a history with that customer, or you're entirely certain your offering is massively stronger. Here's what you do:

STEP #1: Confirm that it's a real RFP. Read the RFP carefully. If a competitor has already locked it down, it should be pretty obvious. If not, it will describe a real and non-partisan problem or need with some half-formed ideas about a solution. If so, then you can go to the next step,

STEP #2: Confirm that there's a budget. Sometimes people write RFPs simply to test the waters. In many cases, the RFP writer may hope that funds will be made available if the proposals make an iron-clad case. But, sadly, that almost never works, so if there's no budget, it's probably not a real RFP. If there is a budget, though, you can go to the next step.

STEP #3: Confirm that there is an owner. Sometimes companies will have a budget for something but lack the "will" to move the project forward and actually spend the money and manage the implementation. If there's not an owner -- somebody who really cares -- then your proposal or your answer to an RFP will probably go nowhere. If there is an owner, though, you can move to the next step.

STEP #4: Confirm that it's a priority. If so, the RFP will identify a real need and have some form of calculating ROI, so that the impact of the project can be assessed. Without these elements, it's highly likely that the RFP is simply a "fishing expedition" for some "free consulting"... from you.

STEP #5: Determine the decision-making process. If you write the proposal and throw it into the "black hole" of the customer's organization, there's a high likelihood it will simply disappear into the void. You'll need to be able to "work the system" in order to make your proposal a real contender.

STEP #6: Confirm that they're open to alternatives. Even if the RFP seems "independent", chances are a competitor was involved somewhere in the writing process. So don't bother to bid without first contacting the requestor and getting a firm assurance that they're willing to review and consider an alternative approach.

If you skip any of these steps, or can't get them completely answered, DON'T WRITE THE PROPOSAL BECAUSE YOU ARE WASTING YOUR TIME.

Next time, do the right thing and get into the customer account before they write the RFP -- and then write the RFP. Then you're the one with the inside track.

Thanks for hearing me out, Neil Licht

George White Technology Enthusiast & Entrepreneur

September 9th, 2016

Everyone has a lot of valid points.  But I still do maintain that RFPs are outdated (to all those who keep saying maybe I just haven't done an RFP the right way).  After dealing with close to 50 of them in my career, I think it's not's them.  Pun intended.  It's evident that the developers who have commented on this also prefer doing a workshop of sorts because it's a more "hands-on" experience where the client gets to see what the actual product will look like as opposed to words on a page.  Regardless, thank you everyone for sharing your amazing points!

James Hipkin CEO, Managing Director at Red8 Interactive

September 8th, 2016

In our experience, Discovery is the first step in a successful project. The RFP is a huge, expensive distraction that in no way guarantees that the project will be successful. And to the commentators who say you are doing it wrong, please show me an example of someone doing it right. I've been on the receiving end of the RFP process for many, many years and can count on one hand and not use any of the fingers the number of times I've seen one that was useful.

Aleksey Malyshev Software Engineer at iTouch Biometrics, LLC

September 8th, 2016

I work for a small software company and we need some third party library. There are a few vendors out there who provide this kind of software. Two weeks ago I sent an RFP to some of them. So far no response. I think I should just call them.

Riyaz Shaikh Entrepreneur at heart, technologist by trade

September 7th, 2016

I think the goal of RFPs is to make it easier to compare vendors. If you get into a collaborative scope-defining exercise with each vendor, that will take 3x longer.

I understand your frustrations in responding to nonsense RFPs, but do you really think spending 2 weeks of unpaid interaction is better? I liked the initial part in that whitepaper talking about an open discussion on RFP details, before each vendor submits private bids. Couldn't find details about it anywhere though.

James Hipkin CEO, Managing Director at Red8 Interactive

September 7th, 2016

This is something I can comment on. The article provides an alternative, Discovery, that we use successfully.

I would add that another disadvantage of the RFP process is qualified vendor will just say no, which is our position. We don't respond to RFPs. Sorry, but they're just too expensive for us to do with little/no guarantee of a return. This means that qualified vendors may not be willing to play, and I'm equally certain that the RFP issuer will be paying more for the work than would be required if they invest in the Discovery process.

Shingai Samudzi

September 7th, 2016

If they suck, then you are doing it incorrectly.  After years of dealing with poor developers and corner cutting vendors on freelance sites, we went through both an RFI and RFP and found an extremely underpriced high quality partner (not vendor but truly a partner).  The ROI on the time we took to complete the RFP was literally a 50% reduction in total expected cost.

Shingai Samudzi

September 8th, 2016


As stated in my previous comment, my company successfully leveraged the RFP process to secure not just a good vendor, but a company we consider to be strong partners, with significant realized ROI.

The RFP process itself was not huge nor expensive.  We built out our functional and business requirements internally (1 week), put together an RFI (1 week), and solicited vendors (2 weeks).  Post RFI, we then finalized the RFP (1 week), narrowed down our list, and solicited from our shortlist (2 weeks).  

7 or so weeks to not only clearly define our technology requirements, but also identify a competent development team is not "expensive" by any means, especially when we were using this process to find a partner to help build out a very extensive backend for a healthcare analytics platform.

And yes, Discovery is basically just the first step of doing the RFP right.  Again, I come back to the fact that RFP only sucks if you don't know what you're doing.  

Valeriia Timokhina Eastern Peak Software: Custom software development

September 9th, 2016

RFP makes your communication with the vendor easier. If you don't find this document helpful, maybe you just do it wrong? I'd recommend you this article: How to write a great RFP.
This is an extensive step-by-step guide. It will be useful for a company and for a vendor as well.
There's nothing complicated in composing an RFP, but you'll greatly benefit from clarified requirements at the initial stage.

Victor PMP Director of Business Technology at PermaPlate Co.

September 8th, 2016

What I find interesting is that a Discovery Workshop is the first step in building an RFP.  This is a vendor trying to sell a service by declaring that their service is better than the traditional method, when they are in fact selling the traditional method in a new catch phrase.  I agree with all the comments above that if your RFP suck, you are doing it wrong.  The RFP is an internal focused document where you as the company define what you need.  An RFP should never be more than 10 pages, and should be a learning experience for the company team that will be running the eventual implementation.
My 2 cents worth!