RFP stands for “request for pain.”
The practice was seriously awful when I first wrote about RFPs in InfoWorld back in 1996, and the situation has, if anything, deteriorated since then.
Requests for proposal and their request for information (RFI) brethren is to select the best vendor to handle a particular business need.
The actual results are, at best, hit and miss. What goes wrong?
Overspecification: I’ve seen RFPs that list hundreds of specific, detailed requirements, presumably as an attempt to minimize puffery, blow-hardery, and general-purpose hand-waving in the responses.
On the surface this might seem admirable — a way to minimize misunderstandings and assure solutions that solve the actual problems.
Regrettably, the requirements listed in the RFP are only as good as the business analysts who wrote the list. Strike that — they’re only as good as the insights provided to those business analysts by those who will be stakeholders.
Worse, even the best lists are just headlines and not the complete stories, and as responders weren’t part of the discussions that generated the list, their responses are sadly lacking in context.
But wait. It’s even worse! By insisting responders address specific and detailed requirements the requester loses the opportunity to take advantage of responders’ creativity, expertise, and innovation. Instead they force every vendor to submit a response that’s just about identical to the responses submitted by every other vendor.
Price tyranny: Overspecification leads to undifferentiated responses. As an inevitable consequence, evaluators are left with little beyond price and intangibles for their decision.
But intangibles are what RFPs are supposed to drive out of decision-making.
As for price, imagine you’re responding to an RFP for creating a custom application. The other vendors estimate the cost of building it. You also estimate the effort that will be needed to modify or redesign business processes, and to identify and deal with sources of organizational change resistance, something not included in the RFP but vital for real success.
But your proposal costs more. What a shame.
Agility exclusion: Those issuing RFPs understandably want responders to provide a fixed price for their proposed solution. Increasingly, they also want projects that make use of Agile techniques. The contortions needed to commit to a fixed price in the face of Agile’s core strength — dynamic adjustments to the project backlog as everyone involved in the implementation “learns their way into it” — are, to be as diplomatic as I can manage, something of a challenge.
Case studies: All RFPs ask for case studies — demonstrations that a responder has done this before. This would be logical if responders were individual human beings.
Actual responders aren’t. They’re corporations, which aren’t just like individual persons only bigger. Which means that even though a responding corporation might have done this a dozen time before or more, that doesn’t mean even one member of the implementation team will have participated in even one of the case studies included in the response.
This can’t be fixed, because even with all the best of intentions, even if a responder can state that several members of the response team were, in fact, involved in one or more of the case studies, there’s no way to guarantee any of them will still be on the bench and available for the project, given the multi-month delays that are typical between the time responders submit their proposals and the issuer signs a contract with one of them.
One more problem with insisting on relevant case studies: They completely preclude innovation. In case the reason isn’t obvious and self-explanatory, innovation means coming up with something new and different, which means there can’t be a case study.
The result of which is that proposers either (1) avoid proposing anything innovative; (2) propose an innovative solution and explain, clearly, why case studies aren’t possible; or (3) propose the innovation and stretch actual case studies to fit.
Most responders will play it safe and choose option #1. But to fix what’s wrong with RFP-driven vendor selection, proposers will have to take the lead, playing it the opposite of safe. They’ll have to try something quite different.
For example, speaking as a more-than-occasional responder, I’d love to receive an RFP that says, “Here’s the business problem we’re trying to solve,” followed by a clear and compelling narrative, followed in turn by this question: “How would you go about solving it for us?”
I think all parties would find the results quite refreshing.
How true! Nicely written.
Scott Mayer
“All RFPs ask for case studies — demonstrations that a responder has done this before. This would be logical if responders were individual human beings.”
Not necessarily. Reminded me of a true story told by a somewhat famous cinematographer who had been asked by an ad agency to respond to an RFP and submit his demo reel for consideration for a national commercial for a well known beer.
This person had been shooting beautiful commercial footage for a very long time, and after a week passed, he hadn’t heard from the agency to acknowledge the submission of his proposal and demo reel.
He called and asked if they had received it, and was told, yes, they had. He asked if there was a problem, and the agency person said “Well, although we didn’t specify it, we’re looking for someone who has shot left handed beer pours for the product shots, and all your reel footage, as lovely as it is, only has right handed beer pours. We are not confident you could shoot a left handed pour so beautifully.”
There really is nothing logical about any of it.
It is probably worse than you describe. In our company we respond to an RFP with a short email stating that if you want to purchase a specific service we have a price list (attached) but if you are trying to solve a particular problem send or call with a description and we’ll quote on solving the problem.
That gives us the flexibility to be creative in the solution and doesn’t lock us into their preconceived ideas. And it works.
This goes right along with what General Patton said: “Don’t tell people how to do things. Tell them what needs to be done and they will surprise you with their creativity.” (I might have a word or two wrong, but that’s the gist of it, anyway.)
He may not have been the greatest human being on earth, but he did know how to get the most out of his team.
I was heavily involved in one RFP process many years ago (’02). Our RFP did include many specifications (needed to be secured internet to be accessible by multiple partners who could change at times; screens needed to be easy to use – minimal to no training required), but there was a lot of “will require meetings between us and the vendor to clarify/approve design” and nearly every point either started with an explanation of what we were trying to accomplish and/or included an example (one partner agency was already doing much of what we wanted; we wanted to automate some of it and enable the other agencies to do the same).
I don’t know if you’d actually want to see the RFP or if it would meet your open “our story – your proposal” requirements, but I could send it to you if you want.
We received a handful of responses, from a full range of organizations – established corps, a start-up, an experienced local technological non-profit; with a full range of solutions – already created/customizable solutions to build from scratch; and a full range of costs; and we evaluated all of them, since they each had different strengths and limitations and concerns.
We went with an established corporation who provided one of the two solutions we requested off-the-shelf (it was adequately customizable) and promised to develop the other in concert with us (which is what we’d requested in our RFP; we hadn’t thought it already existed).
Unfortunately, as development proceeded, the corporation kept insisting that it knew better than we did what we wanted, and built it for its other hypothetical customers, instead of us. Its off-the-shelf product continued to work fairly well for that part of our needs.
I don’t know what this anecdote demonstrates, if anything, except maybe that solving problems (especially custom problems – uncommon ones) through software is hard no matter how you go about it.