How effective is RFP process for projects?
It is quite common for buyers to use Request for Proposal (RFP) to solicit interest in an IT project implementation.
Buyer floats an RFP after collating the requirements for the project, short listing the potential vendors/suppliers, and securing a high-level agreement on priorities. Vendors compete to get the best product and service to you - at least in theory.
RFPs can require anywhere between one month (ha ha!) to more than an year. Both the buyer and supplier spend considerable time on the proposal. The impact to buyer is a direct cost, but it is potential business for supplier. That can give you a good idea of how the process is looked at from both sides of the prism.
In one the recent posts, Forrester analyst Kate Leggette details the risks of RFP process and how to address them. That triggered a few thoughts on my own experience with RFPs.
- RFPs are expensive
- If there is a trusted vendor who has been doing some related work, the buyer will as well get this on the road, rather than spend time evaluating more vendors
- There is always a risk of not involving the right people to drive the process through including business, financial, IT and management stakeholders
- Organizations often have external consultants overseeing the RFP process increasing the expenses
- Complex process
- Complexity of RFP process should be the best incentive for vendors to keep their prices competitive, service great and in general be helpful to customers
- Even with at most care, influential vendors can tilt decisions in their favour by fully leveraging organization politics
- Apples-to-apples comparison is made difficult with details being glossed over, complexity of the solution landscape, and the complexity of business processes
- Vendors’ interpretation of requirements and recommended solutions do not get detailed out effectively
- Lengthy duration is harmful
- Requirements become stale in months if not weeks. A lengthy RFP process does more harm than good
There are a few simple activities that you can embed within an RFP process to make it more effective.
- Demos are important.
Ask for demonstration of the said capabilities. Bring all relevant stake holders to the demo, not IT alone. - References are a must.
Unless you are floating an RFP for something drastically new, it is absolutely important to understand how vendor is supporting other customers in the same line of business.
It really depends on your risk appetite to accept vendors who do not have previous references. For mission critical applications, I would simply ignore them. - Start small.
Outline the vision, encourage vendors to demonstrate how they would want to address the vision, but scope-down projects. Never go with a RFP that takes more than 6 months (thumb rule, duh!) - a lot can change within months. - Make requirements directional.
If you make requirements directional rather than part of the formal requirements for the project, you may discover something new about the proposed solution. Unless you are enhancing an existing system (and you are 100% sure that you will not get a new system for the said capability), go to RFP with directional requirements.
I have been part of RFPs with both product/service vendors and as a buyer. Even with focus on the most simple principles, I am always amazed how bloated and useless proposals can become and how quickly they can be invalidated.
What do you think? Have any RFP horror stories?
Suggested reads -
