Both Sides of the RFP/RFI Process

Posted March 9th, 2007 by

Both as a technical sales consultant and as a product manager at a software company over the past several years, I have had the pleasure of assisting with responding to the dreaded document called the Request for Proposal (RFP).

At last week’s Toronto Product Management Association meeting, I had the pleasure of being involved in a discussion about both perspectives on this process: the fulfillment side and the creation side. Leading the forum were Kim Phelan, Director, Product Management, for Tucows, and Michael Kolm, President of The Outsourcing Lab. The room full of product managers represented the fulfillment side of the process, though the questions and the direction of the conversation tended towards the buyer’s perspective.

Tucows, whom you may remember as a leading software download site, now sells web domains (through its Domain Direct service), web hosting, web publishing solutions, spam protection, and other services. In order to fulfill the creation of these products, Tucows works with multiple 3rd-party vendors. Locating the appropriate vendors is typically accomplished through an RFP process.

The Outsourcing Lab (TOL), as you can probably guess, assists companies with finding outside subject-matter expert consultants and vendors to assist with project implementations. To achieve this, writing RFPs, evaluating their responses, and selecting a winner plays a large role in the work that TOL does for its clients.

Request for… What?

Michael provided a good place to start the meeting by noting that when opting to start down the RFP/RFI process, most of his clients wonder about what to do.

In general,

• A Request for Information is best used when the buyer doesn’t understand the playing field.
• A Request for Proposal is best used to establish specific parameters about the solution the buyer is looking for, and to determine pricing (more on that topic, later).

Michael gave an example where one of his clients asked TOL that they wanted to “establish an online presence”. Once understanding exactly why a client might want to do this (e.g., Is it to enable online sales? Or is it just because everybody else has a web site?), an RFI would be a good place to start. The buyer would then talk to several vendors with the purpose of learning more about their own needs, and how they are generally fulfilled.

Know your Requirements

One of the most important messages that I took away from this session is that the buyer must first intimately understand what the requirements are for a given project, before pursuing an RFP.

As with the previous example, buyers generally are not experts in the given domain that they are seeking help with. Poor understanding of the problem space then leads to poor requirements in the RFP. Michael noted that companies generally have no problems with things such as terms and conditions, but fall short on the requirements themselves. As a result, Kim recognized that when the vendors’ responses are prepared and presented to address these poor requirements, the quality of sales presentations and other deliverables suffer.

This topic prompted a question from the audience about whether or not one should consider bringing in an outside domain expert. This would obviously help, but the reality is that finding such a consultant is generally a hard thing to do.

The Pricing Game

Pricing in RFPs is an interesting topic in itself.

Kim commented that the pricing model provided by most vendors in their responses is almost always useless. Everybody has their own opinions.

Buyers, of course, want to leave pricing wide open to ensure flexibility when it comes to sizing the final solution, once the budget of the buyer has been discovered, personal relationships have been formed, and the “fit” between the buyer and vendor has been established. Unlike a traditional sales cycle, this usually takes place later in the RFP process once the buyer has narrowed down the its list of top incumbents.

As somebody who has been involved in writing proposals, having inadequate requirements to work with certainly doesn’t help when coming up with suitable pricing.

The “Wired” RFP

Sometimes the winner of an RFP has either already been chosen, or there is a clear preference for one vendor over another. In this case, proceeding through the RFP process is more of a formality for the buyer. The predetermined winner may have even helped write the RFP to ensure that their solution will come out on top. Unfortunately, a respondant not recognizing that this is taking place is wasting their time.

As a vendor, a couple ways to identify that an RFP might be “wired” include:

• Recognizing terminology used by competitors, or other companies in your market space. In Michael’s experience, they could generally tell who the incumbent was.
• Another red flag is an undefined time line. A company using this process may also have unreasonable deadlines, leading to what they hope will be a quick completion of the process, and thus skew the RFP with this intent.

On the flip side, Michael has seen RFPs where the buyer actually provided business references (of their suppliers), to demonstrate that they intended to proceed fairly through the process.

Some companies use RFPs as a means of performing market research. Using a proxy, a vendor pretends to be a buyer in search of a solution similar to their own, and submits it to their competitors. This endeavor can be costly, as Kim pointed out.

The Challenges of Responding to RFPs

The number one problem with RFPs is that they are usually very time-consuming and tedious to respond to. Some companies are not even allowed to waste their time responding to them.

Time can be a factor if you don’t have the help of a knowledge base full of answers to frequently-asked questions. On the other hand, completing an RFP response can be quite educational if you don’t already have such a system in place. In one instance I helped respond to an RFP that, as it turned out, was written by a consulting company that specialized in the market we had hoped to sell in to. The questions asked in the RFP actually helped plan the road map for our product, as the questions really outlined the necessary features and functionality that products in the market space needed to have. In addition, we now had a valuable resource to help with responding to new requests.

Then there are those questions that ask about features that your product doesn’t have. How do you go about saying “no” without actually saying “no”, or — the typical product manager cop out — “no, but it’s on the product road map”? In my past,we attempted to close this gap by playing the Professional Services card, for the most part. Kim’s suggestion was to try to turn the question around.

One last thing worth noting is that if you’re coming across a large quantity of questions that indicate some significant gaps, you should be asking yourself if you can partner with somebody to help supplement your capabilities. You should even consider whether your company is even qualified to answer the RFP in the first place, which may be difficult to admit.

Other Topics

Somebody asked how RFPs for software-as-a-service might be different from those for packaged applications. As this is a large part of Tucows’ business, Kim noted that service-level agreements play a big role, as well as terms and conditions around post-purchase support.

On the subject of potential land mines one should look for in an RFP, Kim and Michael both had a few examples:

• Escrow clauses.
• Non-compete clauses.
• Exclusivity. This can be bad because this means they may not improve their product/solution.
• Right of first refusal.

In the end, as with a traditional sale, relationships become a key factor for the buyer. Once the vendor list has been narrowed down to a select few, buyers tend to have more conversations with their representatives. Fit is important, as the chosen vendor should be able to work effectively with the buyer to fulfill the established requirements.

The Toronto Product Management Association

If you’re a product manager in the Toronto area, or are interested in how software products are conceived, developed and sold, I encourage you to check out the Toronto Product Management Association. The TPMA meets once a month at Metro Hall, downtown Toronto, and features presenters who speak about various topics relating to product management.

For more information, visit the web site at http://www.tpma.ca/.

Thank you for reading! Please sign-up for email updates, or subscribe via RSS.