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.





5 thoughts on “Death to the RFP!

  1. Semantics. You obviously aren’t arguing for RPO’s death and, instead, are calling for a change the proposal’s focus to performance outcomes.

    I’m sure your failure to match your title with your text wasn’t suggesting we eliminate the ”fair’ competition that an RPO is designed to foment( or we would be returning to back room deal making)

    And so no one could argue with your well thought approach…unless, of course, the client sets the vendor up to fail….not that any client would ever ask for an unrealistic outcome.

    1. Gerry – thanks for the read and the comment. I would never advocate for death to the RPO – It’s a great model that delivers tremendous value to many organizations (unless you’re an in-house recruiter who fears redundancy). As for unrealistic outcomes…. that’s where consultants can & should be adding value to prevent clients from expecting the impossible.

  2. I think I would have to disagree. I agree that RFPs are limited in their ability but – in my view – they should not be used alone but in conjunction with business case analysis and evaluation for outcomes. You are correct that they alone cannot address the areas of ROI, technical risk, or enabling the organization to compete more effectively in the market. That is the job of the the person asking for the money – whether it is HR or some other function. The problem is that all too often, those questions aren’t answered by the project team and the internal sponsors. The RFP then is the only “structured” process of analysis that is used in the entire purchasing decision. So I think removing it would encourage the subjectivity of the decision. I have worked with too many clients who have poorly developed requirements, poorly designed strategies and project plans, and burden IT with poor execution to believe that the reduction of structure for HR projects is a good thing. It’s like encouraging bad habits.

  3. Excellent points. As an applicant tracking software vendor, we stopped responding to RFPs about a year ago based on our experience with the process. Having worked for a government contractor in the past I can understand the necessity of RFPs for large government contracts. But when a company is looking to spend a few thousand dollars a year and want a modern ATS it’s a waste of time on both sides.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>