At times, it seems as if the RFP and RFI process can garner answers that are nearly as jumbled as the endless alphabet soup of technology acronyms themselves. Are vendors partially to blame? Of course. But if you find yourself on the technology-purchasing side of the equation, there are several things you can do to improve outcomes and the quality of information you receive. And as someone who has worked on many an RFP, I’m here to give a few pointers borne from experience.
First, the basics. An RFP (Request for Proposal) and RFI (Request for Information) are invaluable tools for companies and organizations and are an integral part of the buying process. Oftentimes a company looking to purchase a new product will distribute an RFI or RFP which will contain questions that outline the exact performance functionalities or features that the company requires or desires as well as any information on the vendor itself. The bidding companies will in turn answer these question to present to the potential client the performance capabilities of their products. This question and answer exchange works to allow competing vendors to best frame their product, and for the potential customer to gather holistically all the information that is required to make an informed decision on which vendor to ultimately choose.
Although both an RFI and RFP contain similar outlines in terms of questions (features, functionalities, vendor info, etc.), they are vastly different in terms of functionality in the buying process workflow. An RFI is not an official solicitation from the potential customer; and as such, the questions tend to be broader and less specific. In addition, most RFI’s do not require pricing… whereas pricing is a ubiquitous feature of RFPs. Once an RFI is completed and the customer has gathered all of the information from the proper vendors, an RFP is issued to these vendors. But then again, not always: it should be noted that some purchasing processes occasionally skip over the RFI altogether. If a potential customer is already aware of the possible vendors out in the market they will often bypass the RFI stage of the process and move straight to the Request for Proposal.
Unlike the RFIs which have less specific questions, the RFP will feature questions that are more in line with the customer’s envisioned scope of work. In addition to the change in the specificity of the questions, RFPs will almost universally require some form of pricing and will oftentimes require a number references from current customers. Once the customer has all of the RFP responses, pricing information, and references, they will look to select one or a couple vendors to move past the RFP stage to purchasing the product or move onto further ‘testing’ such as demos and Proof of Concepts (POCs).
For the most part, RFP functionality questions are separated into two sweeping categories, questions that require some form of description (such as “Describe the capabilities of your eDiscovery application”) or rather what might be called “checklist” questions. Checklist questions are yes and no affairs that aim to pinpoint specific capabilities, such as “Does your product support Boolean search operators?” While both of these types of questions have their merits, there are some precautions potential customers should take when constructing the questions that are to appear in the functionality portion of the RFP.
There are several reasons RFPs will fail to produce or gather the information that the customer requires to make an informed decision: the first and foremost being the vendor responses themselves. Because the RFP is often the springboard for solicitations, many vendors take the foot-in-the-door approach to RFPs and will do their very hardest to never respond “no” to a RFP question, even if it means proverbially shooting themselves in the same foot they’re trying to sneak in. This will often lead to long convoluted answers that attempt to convey a work-around to a functionality that they may or may not be able to provide and ultimately will end up creating more work for the customer team reading these responses. Other times, vendors will skirt the ‘work-around’ altogether and respond with what can only be described as marketing banter. Sure, it’ll make the product sound more appealing, but provides absolutely no clarity or information to the customers themselves.
So to avoid these pitfalls when distributing an RFP to vendors, here are some points to help ensure that you get the answers that you want.
- Try to be as specific as possible:
For example, the question “Describe your product’s eDiscovery capabilities” will most likely net you a response from the vendors that will list out a couple of the features, but will also follow with large chunks of marketing spiel. You may get the occasional vendor who does go the whole nine yards and list out every eDiscovery feature of their product, but that again will produce an answer that may contain large portions that are irrelevant for you as the customer. Instead, questions like “What are you product’s capabilities regarding legal hold?” or “What is your product’s approach to early case assessment?” will lead to answers that are far more specific, informative, and overall more helpful.
- Include Use Cases:
Every company has a unique way in which they handle their workflow processes for Information Governance. Therefore it becomes tricky as vendors to answer questions because, although our products remain a constant in its functionalities and features, the way companies will integrate them into their daily workflow will vary with each customer.
As a customer attempting to learn more about the product, information that does not pertain to their companies specific use case is next to useless and will not aid in making an informed decision. The solution to prevent these disconnects between the customer expectations and the vendor’s preconceived notions are to provide as many use cases on how the product will be used within your company. If the vendors are aware of how the product will be used within the company, then we will be able to tailor our responses so that you may make an informed decision based on your circumstances, rather than the standard information about vendor product capabilities.
- Don’t be afraid to use “checklist” questions:
- Do your Research:
In the end, though, even with any tips that I can provide regarding the construction of good RFP questions, the quality of the RFP — as well as the RFP response from the vendor — really hinges on the knowledge that the customer has. If the customer has gone through the RFI process, learned about the market, researched their exact needs and requirements, and knows their specific scope of work, then the RFP will reflect this knowledge and will likely return equally relevant responses from the vendors. We the vendors are by no means expecting our customers to be experts on Information Governance software; however, the more information you provide us with, concerning your desired/required functionalities, performance benchmarks, and other needs, the more informative your response will be and the likelihood of receiving answers that contain a ton of marketing effluvia will be decreased.
The most important thing to ask yourself when gauging the success of an RFP response is “Did the vendor answer the question that was asked?” This may seem like a rudimentary benchmark, but we’ve interacted with many potential customers who seem to indicate that the direct answers we pride ourselves on are not necessarily the norm. Apparently there are vendors out there who — in the fervor to market their product within RFP responses — forget to even answer the question was actually asked (or so we’ve been told!). It would be unfair to state that these vendors’ failure to produce satisfactory answers is due to the construction of the RFP by the customer; however, as we discussed today, there are ways that the customers can control their RFP process so that the responses they receive are far more informative and helpful.
Don’t let vendors obfuscate or obstruct your path to making an informed decision. With the right objectives and a little direction, these tips can be used to create a smarter and more efficient RFP as you move forward through the technology purchase process.