5 Reasons Not to Use RFPs

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 business application software for long enough to have experienced many RFP processes and the primary lesson I have learned from those situations is never to use an RFP for my own buying process.  Here are my reasons to avoid it at all costs.

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 implementation.  A customer is choosing a system without the correct information, and that result is counter to what the RFP is meant to achieve.

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 software and services are almost always erroneous.  This favors the disingenuous vendor, who can purposely lower the estimate and can point to faulty assumptions later.  The prospect’s prescription is to require a fixed fee implementation.  We know how that works: fixing the cost during a competitive sales process based on an inaccurate project scope.  That makes for an unhappy customer or an unhappy vendor, but usually both. 

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 software application has the best features.  Now let’s face it, if you are sending your RFP to prime time players they will all pretty much have all the core required functionality you are seeking.  The fact is that an RFP will not weed out products based on functionality because the vendor is unable to show the product.  In the end it’s the skill at answering the RFP that gets a vendor picked.  You may as well use a coin toss to select a product.

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 evolving technologies.  The RFP process takes no account of the special value that each product possesses, instead relying upon a dry list of features which all the products in question would likely possess.   In order to discover the unique proposition of any application, a prospective buyer should do everything possible to create an interactive dialog with the individual developers.  Read my next entry to learn an alternative to the RFP that will enhance the buying process and create the prospect’s best chance of success with technology.                                                                                                                                                                                 By Jack Ades Co-CEO InterDyn AKA, New York Microsoft Dynamics CRM Partner