The Request for Proposal (affectionately known as the RFP) begins with the best intentions but almost always results in a bad outcome. I have been selling and implementing
When You Assume…
The RFP is essentially a one-way dialog. It is the prospective customer communicating (in a rather demanding tone I might add) what is required of the vendor’s system. In some situations the prospect will allow questions to be asked, but those can only revolve around clarification of one or more of the RFP questions. In certain cases, in order to be entirely fair, the prospect will not answer any questions. Yes, this is to keep any one vendor from gaining an advantage during this extremely controlled process. Thus, the individuals answering said RFP are left to assume a great deal while responding. When do these assumptions bite back? You got it—during the
The Price is NOT Right
One of the key assumptions a software vendor must make is the price of the system. Because the dialog between buyer and seller is limited, prices for
Functionality War
In effect what an RFP creates is a battle over functionality. The document contains a laundry list of features and functionality with the intent to distinguish which
Time is Money
…Which brings us to the point that a tremendous amount of time is wasted by both prospect and seller as a result of the RFP ritual. First, think about the time spent creating the RFP itself, the days and sometimes weeks it takes each firm to answer the RFP, and the then the process of evaluating the RFP results. I know that there is nothing revelatory in saying that this amounts to hundreds of hours that could be devoted to making a decision in a more enlightened fashion. But the RFP continues to be a time burglar after the purchase is made. Throughout the implementation process, as issues arise that were not foreseen during the sales process, the client will invariably refer to the RFP. I have seen implementations delayed months while client and vendor dispute whether or not the answers to the RFP implied that the project should include certain large areas of functionality. This is valuable time that costs both parties a fair bit of money.
Beauty is in the Eye of the Beholder
But the chief sin of the RFP is that it forces vendors to compete over requirements that are created by prospects who might not know exactly what they need. The fact is that each software developer possesses a unique vision of how they can solve business problems, not just through a checklist of features but through an innovative approach utilizing continuously
Hi Jack,
You've done a good job of summing up why the traditional RFP is not an ideal way to evaluate vendors, and I am interested in hearing more of your thoughts.
However, the 'alternative to the RFP' link is not working.
I've been on both the buying and sales side in the software world for over 10 years, and I have ideas regarding alternatives to the RFP of my own. If you have the time, please visithttp://www.vendorcourt.com and check out a beta version of what my colleagues and I are trying to build.
Thanks,
Vito