Viva la RFP

RFPs aren’t the problem.

FULL, 100% disclosure up front:  DelCor writes and manages requests for proposals (RFPs) when it is an appropriate part of a solution selection process.

It appears folks are getting excited about not using RFPs any longer.  They seem to feel that the RFP is an inherently flawed approach to technology selection and acquisition projects. It’s the RFP’s fault?  I don’t think so.

When I consider all of the RFP documents I have seen in the past 20+years, I quickly realize they can be sorted into piles of effective and ineffective pretty quickly.  The same goes for the RFP process – which is just as important as the RFP document.  A well written RFP used in a poorly designed or managed process can be just as ineffective as a poorly written RFP used in a good selection process. 

Here is my short list of an effective RFP’s attributes:

• Appropriate level of detail - appropriate means appropriate, not copious or anemic levels of detail.  This depends on the overall process being followed and the solutions being considered, of course.
• Targeted – an RFP isn’t the tool one should use to determine if a solution provider might be an appropriate resource.  If the RFP is going to more than six candidates, chances are there has not been enough pre-RFP work done to help narrow the field.
• Clear – goals, requirements, process, selection criteria, and success factors should all be as clear as possible.  Naturally this relies on having clear goals, process, selection criteria, etc… which we all know is easier than it sounds.
• Simple – it should be as simple as the situation allows it to be.  See Occam’s razor.

Another reason I want to keep the RFP alive is because the value of an RFP isn’t in the actual document itself.   Perhaps folks that haven’t done it correctly don’t realize that.  The value is in all of the conversations and work that go into developing the RFP.  During the process DelCor follows, there is a great deal of discussion about business process, culture, the organization’s goals, training needs, and both functional and nonfunctional requirements.  The discussions that happen along the way and the decisions that are made are as much of value to the organization as any solution that is later selected as a result of the process.

On the flip side:

Not only do we produce RFPs at times, we also receive them.  Maybe it’s a benefit of our work, but we know better than to respond to bad RFPs or even a good RFP that is part of a bad process.  If the RFP is distributed to more than half a dozen firms, I am very likely not to respond.  Not because we fear competition, but have learned that if an RFP is distributed to a dozen firms, chances are it’s a buckshot approach.  No work was done to filter the list to the most appropriate set of solution providers.  A simple RFI (request for information) will help narrow down the list of RFP recipients.  One RFP I received went to over 30 firms.  I didn’t respond to that RFP.  Another red flag is a lack of opportunity to meet the decision-making team.  If there is no meeting before the selection, that’s an automatic decline as far as I am concerned.  We are in the consulting business, so personal interaction, chemistry, and communication are critical components of our success with a client, as well as that client’s success.  If the prospective client can’t meet us as part of the process, how will they evaluate those elements of our potential relationship?

Solution providers/vendors/firms – whatever you want to call us - need to keep in mind that responding isn’t a requirement.  Responding to an RFP is your decision.  If the RFP stinks, don’t respond.  If your firm isn’t selected when you respond to a poorly written RFP, or even a well-written RFP that is part of a poorly run process, don’t blame the RFP.

The RFP isn’t the problem.  If you’re issuing or working with a consultant to issue an RFP, make sure the process is focused on the goal – clearly communicating as much as you can with potential solution providers so that the most successful match can be made.  If you’ve received an RFP you owe it to yourself to spend time evaluating the process and the RFP before you respond. 

Viva la RFP!

Comments

[Loretta M. DeLuca]

Surprise - I agree with you, Dave! A couple of other points to keep in mind when it comes to the value of RFPs in a system selection process:

(a) If well documented with useful information, the soliciation document will follow you throughout the entire selection and implementation processes and beyond. It will form the foundation of a design study the vendor may select as well as for the development of SOPs, it can aid in the generation of testing scripts, training documentation as well as assist in conducting an audit later on (did we get what we thought we were getting?).

(b) Use of an RFP or any carefully crafted solicitation document (can be high level or provide many details) as a means of selecting a vendor will start to normalize the risk between the organization and vendor. When the vendor is asked to document system features, functionality, costs, etc., risk starts to shift away from being entirely on the organization to the vendor.

Of course, there are different levels of "RFPs," and an organization must select the right type of document that makes the most sense in a given situation.

'Nuff said (for now).