Death to the RFP!

If you ever want to make a salesperson cringe, just tell them that you’re going to be issuing an RFP (Request for Proposal)  for a planned purchase of software or services.  Uttering these three little letters can completely alter the nature of the relationship that you maintain with a vendor – and negatively impact the quality of the outcomes and organization can delivery with a service/product vendor.

In what likely originated within the bowels of the US Federal Government as an attempt to compare procurement prices between suppliers for $800 pencils, screwdrivers, or toilet seats, the RFP has morphed into a blunt object utilized by procurement departments everywhere to put low price ahead of everything else in the procurement process.  For this reason, my honest opinion is that the RFP must die.

Argument #1 against the  RFP: Comparing Apples to Oranges

It assumes that apples can be compared to apples – even if you’re buying oranges.  Unless you’re buying either a pure commodity or a completely bespoke product/solution for which you draft the entire set of requirements or specifications, using an RFP often results in the comparison of apples to oranges and in turn clouding the entire picture.

Often when procuring technology the focus is on features and functions. In the HR Technology market the maturity of product capability has reached the point where the differentiation between vendors is often not features and functions but instead factors such as viability, product roadmap, quality of the team, quality of support, etc.  Notice that I haven’t mentioned cost….. yet.

Argument #2 against the  RFP: RFPs Assume You Know Exactly What You Want

Let’s face it – you don’t know exactly what you want, and neither do I. I’ve been in numerous demonstrations where I have seen product capabilities which solved problems I didn’t know existed or could be solved.  We often create requirements based on either exactly what we do today (which by the way is going to change radically) or based on things we’ve read/seen/hear about.  All too often the “must have” requirement is based an abstract concept which may be rooted in marketing messages which have been pushed through the industry by various influences, vendor or otherwise.

Just like when I go to the grocery store with a list of things to buy, I often will come home with all the items on my list and more.  I went shopping knowing exactly what I needed, yet realized I needed more.  It’s hard to address the unrealized need through an RFP.

Argument #3 against the  RFP: Broken Scales

RFPs are best when you have very specifically crafted requirements.  The problem is the fact that all to often requirements are treated equally when they really aren’t.  I’ve heard the arguments before – “We’ve weighed, prioritized, etc our requirements”.  But, who is setting the weights and priorities?  Is that person(s) actually writing the check or are they simply shepherding the process?

Honestly most software purchases are made for reasons that have little to do with the formal scoring models.  The scoring model is a thinly veiled rationale for decisions that are made outside of the formal evaluation criteria.

Argument #4 against the RFP: Cost is not one of several considerations (it’s the ONLY consideration)

After it’s all said and done, the RFP process is simply a mechanism to qualify vendors.  Having sat through countless decision sessions as both a buyer and a consultant, the best functionality, the best user experience, and the best analytics capability, etc…. the question always comes down to cost.  Inevitably someone will ask whether the solution that prevailed in the formal scoring model is worth the extra cost vs. some of the other solutions.  The discussion quickly becomes about the value of the extra features vs the cost.  In the end this highlights that cost really is the only consideration.

We need to change this (and FAST!)

Page 1 of 2 | Next page