5 Reasons Not To Use RFPs

By Jack Ades, Co-CEO InterDyn AKA-

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 an 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 is Hell

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 assume they know 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 | 2017-10-21T20:28:57+00:00 October 19th, 2012|AKA Culture|1 Comment
Alternative Text

Contributor: AKA Enterprise Solutions

AKA is comprised of professionals with deep experience in business, technology, and their respective industries. Our team members regularly share their knowledge and expertise through blog articles. We hope you find them helpful, and we welcome your comments.

One Comment

  1. bet365 November 14, 2010 at 7:02 am - Reply

    how are you!This was a really quality post!
    I come from itlay, I was luck to come cross your blog in wordpress
    Also I get a lot in your blog really thanks very much i will come again

Leave A Comment