RFPs are designed to express the interest to buy a solution/ system/product that meets all of the customer’s requirements. So what can go wrong with an expression of interest? Lots…
The customer wants to buy a car, with four wheel drive, central locking and six seats and air conditioning. He writes the details of the car needed in an RFP. Vendors bid and customer evaluates, ticks boxes and buys.
There is a lot the customer did not mention in the RFP. He wants to take the car across Sahara Desert, he wants the car to stay cool when he does this, wants a jack which will work in the desert. He is an explorer, and hence it could be a rain forest tomorrow.
You see the background makes all the difference, now suddenly only a few cars in the world qualify. So we are weeding now.
Unfortunately most RFPs that the vendors respond to lack a lot of these details, especially if the customer is a government or a PSU (Public Sector Units) organization. Even when Vendors set up calls or meeting to understand the background, the RFP process restricts the scope of these meetings.
Back to the car scenario:
The Vendors bid and the customer picks the dreaded L1 bid and takes delivery of the car. Boom! The new purchase fails to deliver and the customer blames the car vendor for it. Again!
Now imagine this in a technology evaluation and the complexity of the situation.
Today’s software market is quite mature with software fast becoming a commodity. There are many products on the market with similar capabilities and good reference-able clients. So what it boils down to is which vendor has the most for the least amount of money – that has to be the best deal? Not necessarily. Price is a valid argument to have only after its first established that the solution delivers on the intended benefits.
So what is the best approach?
Challenge the existing RFP process. Articulate your ideal solution, your current IT landscape and the goals you intend to achieve with the new software. Consider finer aspects like implementation procedures, ownership transfer, support SLAs and delivery timelines. Consider post three year scenarios as well, scalability and how do you want this software to adapt after three years, lets say. If you are going to evaluate based on all these aspects, then make them a part of your RFP, your pre-bid meeting will be less of a blood bath then.
Profile of author:
Bhavani Sidharth – Director of Sales and Marketing at stackArmor
With over 14 years of sale experience. Past sales leadership positions in Dell, Oracle, Akamai