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!)
The whole point of evaluating new solutions, new vendors, new technology, etc is to deliver new business outcomes. By utilizing a requirements-based RFP process the emphasis becomes on “the HOW” and not about “the WHAT”. What I’ve personally see work extremely well with the clients I’ve advised is an outcomes-based evaluation process with potential suppliers. The discussion quickly becomes about how the solution can help deliver the desired outcomes, and the relative value of those outcomes for a specified price.
By changing the rules of the game we are able to refocus on WHAT we need to do without getting bogged down in details on HOW it will get done. While the process is important, what is ultimately critical is the outcome. Your CFO doesn’t care about the fact that it takes 3 steps instead of 4 steps to complete a transaction, or that the solution is built upon a .NET platform instead of a J2EE one, etc. They want to know what value will be delivered back to the organization in exchange for the investment necessary. Your CIO will want to make sure that the solution isn’t going to introduce additional risk into the technology environment and can be compatible with the existing technology investments. Your CEO will just care about how the solution will enable the organization to achieve greater results.
A RFP will never answer these questions. And for that reason – the RFP MUST die.