Why Your RFP Is A Request for Problems

I have never been an advocate of the Request for Proposal (RFP) process. The concept seems valid: send the description of your needs to multiple providers and then select the provider offering the best solution. Unfortunately, in the world of unified communications and collaboration, many organizations end up more confused at the end of the RFP process. Instead of helping move toward a solution, the time and effort dedicated to the RFP process creates both internal and external conflict -- and your RFP becomes a "request for problems".

There are several factors that can cause the RFP process to fail:

1. Your requirements are not clear.
Unfortunately in the world of UC and Collaboration, few organizations have documented and prioritized measurable business requirements. This often means vague requirements are included in RFP documents, creating a lose-lose situation. Clients aren't sure what they want, and consequently, respondents aren't sure what to propose. However, propose they must, and as such the responses typically suggest specific features and solutions regardless of the requirements. Responses become more about what can be "sold" as opposed to what is actually needed.

Phrases in RFPs such as "complete integration with x" or "full mobile support" or "support for Microsoft Outlook" -- unless explained in more detail seldom serve as valid solution criteria.

If you cannot clearly explain what you need, please do not issue an RFP; it will waste everyone's time.

2. A fancy template that hides unclear requirements.
Some organizations "borrow" (cut and paste) fancy, legalistic RFP templates that add structure to an RFP document, but this does little to make up for vague or undefined requirements.

I would argue that using a bombastic template often fools people within your own organization, they erroneously assume that you actually have a good handle on the solution requirements simply because the RFP document is 50 pages in length and it has impressive heft. They don't realize that 49 of the pages are boilerplate text and only one page, containing a handful of vague bullet points, describes your specific requirements.

You can fool some of the people some of the time; but all of the time, you can make people's eyes glaze over if you begin an RFP with ten or more pages of legal jargon.

3. Organizations abdicate decision making.
Issuing an RFP is a terrible way to decide if you want an on-premises or hosted solution. Likewise an RFP is not an effective way to decide between Cisco and Microsoft UC. Important strategic decisions should be made ahead of issuing an RFP-based on your specific business objectives and organizational situation.

If you hire a consultant to help evaluate alternatives, they work very hard to try and accurately compare the options. A consultant should ensure that different cost models include or exclude similar items; a balanced comparison ensures licensing, usage/consumption assumptions and redundancy and resiliency parameters are similar across the solutions being compared.

In contrast, respondents to RFPs are solely driven to make their proposed solution appear better and more economical. In responding to an RFP, instead of trying to include all of the potential costs, any costs that can be excluded will be, in order to make a solution appear more attractive. Additional networking costs associated with hosted solutions or the need for additional real-time traffic prioritization are often (un)intentionally excluded from RFP responses.

4. The RFP process is inherently divisive.
If you are looking to continue or build a true partner relationship with a company, then an RFP is almost always a poor way to proceed.

The RFP process is inherently confrontational, causing organizations to ask for long lists of features, many of which are not actually required, going so far as to denote many unneeded features as "mandatory." Respondents then over-promise, answering "yes" or "complies" to all mandatory features (they don't really have a choice) while simultaneously trying to include the most minimal of actual costs. Many respondents figure they will sort out the pricing details (i.e. add in items or clearly exclude services) during the contract negotiations, once they are selected as the preferred vendor.

5. You punish the incumbent.
If someone has been managing your existing network, voice, or UC environment, chances are they know a few things about how your organization operates. Given this, evaluate carefully pricing and timeline differences between the incumbent and other respondents. Don't punish the incumbent simply because they are providing the most accurate timelines and pricing based on their more detailed understanding of your requirements and environment.

Transitioning from an existing provider to a new provider will always increase risk and potentially incur unexpected costs. Similarly, transitioning from an on-premises solution to a hosted solution often introduces unanticipated risk and cost. Major changes in platform require additional end-user and support staff training. Make sure you add budget and timeline contingency to transitional responses.

Making Your RFP Better
As noted above, organizations can sabotage their own RFP process in many different and creative ways. Here are six things you can do to improve the RFP process:

1. Be very clear on your specific requirements. If you are not sure what you need, you are not ready to issue an RFP.
2. Only denote as mandatory attributes and features that are truly "make or break". If there is debate around whether an item should be mandatory then you have more internal work to do before issuing the RFP.
3. Make strategic choices before you issue an RFP: hosted versus on-premises, Cisco versus Microsoft, etc.
4. Only ask for features you know you need. Don't be tempted to include a request for features "you might need." If you are unclear on which features are required, again, you should not be issuing an RFP.
5. Communicate actual timelines. Asking for an implementation date earlier than required may cause respondents to increase cost estimates; however, if the actual implementation takes longer, because delays on your side, vendors may be justified in billing you more.
6. Make sure you have documented and prioritized your specific business objectives associated with the project. If the evaluation team is not clear on whether price, security, risk mitigation or user experience are most important then you are not ready to issue an RFP.

Conclusion
Some organizations issue RFPs because governance requires them to do so. Other organizations issue RFPs because they believe this helps them procure a solution at the lowest price. Still others think an RFP will help them better understand the market choices. I would suggest that for organizations who have a choice, if you truly have quantified the business benefit a UC solution will provide, and you should, consider negotiating with a strong provider of this solution, perhaps an incumbent. As long as the total incurred costs are less than the provided business benefit you will have a positive return on investment. And a positive ROI is a fantastic demonstration of project success.

RFPs work well for commodity or near-commodity items. Need office chairs? Then issue an RFP. However, in the complex and quickly evolving world of UC and collaboration, an ill-conceived RFP may yield more problems than solutions.

Has the RFP process worked well for you? Has the RFP process left you more confused? Please comment below, connect with me on LinkedIn and send tweets telling me where I went wrong to @kkieller.