RIP RFP?

The Request for Proposal (RFP), often following the Request for Information (RFI), has long been the key selling/buying document, depending on which way you look at things. The process would usually go something like;

1. Requirements definition
2. Vendor research
3. RFI
4. RFP
5. Vendor demonstrations
6. Contract negotiations

At each step in the process, the field is narrowed from the vendors identified in step 2 to the vendor selected for contract negotiation in step 6.

But does is this process really still a good one – especially for smaller companies procuring CTRM software?

As we move inexorably to CTRM in the cloud in for many users and away from the more costly perpetual license and on premises implementation, isn’t this overkill?

I was talking to a vendor’s sales person this morning and he told me that an average RFP these days might take 4 man-weeks of effort to respond to. Imagine having a whole bunch of RFPs to respond to at 4 man-weeks of effort each and pretty soon you begin to wonder if it makes any sense at all any more to do things this way?

Who really benefits from an unwieldy RFP process anyway? It’s not the vendors as it increases cost of sale and, in many or even most cases, it’s hard to imagine the buyers realize a positive return on the effort as it increases their costs and there is no guaranteeing that it actually results in a good decision anyway. The happiest entity in this picture is most likely to be the consulting firm engaged to manage the selection process isn’t it? Surely, there is a better way than this?

For many years, I have questioned the RFP. When an outside consulting company is used, they often bring to the table a template RFP. Done correctly, this is useful and can save time and money for the procurer but I wonder how often RFP templates are reviewed to eliminate unnecessary content? I wonder, when they are tailored, how many requirements are added but how many unnecessary requirements are removed? I wonder how many RFP templates are in fact stacked towards a particular conclusion based on the originator’s natural and accidental bias?

One thing I do know is that all users are different (and often, there is quite a difference in requirements), this is why CTRM solutions are designed to be so configurable – they have to be. So does it not follow that cookie cutter RFP’s are equally as flawed and also need to be highly customized for each particular software selection process?

Just as software development technologies and methodologies have migrated from the old-fashioned sequential waterfall approach to a more flexible and more agile set of alternatives, why shouldn’t the procurement process? After all, it’s equally as complex and risky; not to mention – expensive.

As I stated above, as we naturally move to procuring cloud-based solutions on a subscription basis, the economics of the RFP surely will ensure its extinction anyway, at least for those for whom cloud products are a viable solution? Who in their right mind is going to pay possibly more for a selection process than they do for the solution? If there are cost sensitivities around the software then surely there are even greater cost sensitivities around the selection process?

What about the risks? We have already alluded to several key risks regarding template RFPs but surely the biggest risk is that the RFP simply doesn’t and never will truly reflect the actual requirements at a sufficient level of detail. Extracting needs from busy traders and risk managers isn’t easy at the best of times and this is or can be a truly seriously complex business. All of this adds up to ultimately making a poor choice because, by the time you actually get to see the software in action, lay hands on the keyboard and figure out whether you can use it or not, most commercially available solutions have already been eliminated. It’s a poorly kept secret that many selections end up going badly.

Furthermore, I believe that for smaller users of CTRM software, many vendors will ultimately simply no bid the deal if the RFP is unwieldy, overly long and takes 4 man weeks or more to complete, particularly if they have other more lucrative opportunities or prospects. After all, they are profit-based businesses too.

So what’s the alternatives?

Perhaps the best way to select software is by actually seeing a demonstration and getting hands on. In the cloud solutions (and even if you are leaning towards on premises, traditional, your vendor almost certainly has an in the cloud variant) can be made available, on trial, in minutes, so wouldn’t a short trial be a better approach? Perhaps this puts the emphasis back on those reluctant end users but its their system so by forcing them to get involved in a hands on manner as opposed to talking requirements with a consultant, perhaps you reduce the risk of a bad decision? There is still a good role for the consultants too.

Plainly, you still have to understand the solution landscape and narrow that down to a manageable number of demonstrations, which in turn can result in a trial (or two). But that’s easily done. In fact, we’ve worked with a number of buyers to do just that – leveraging our deep understanding and constant review of the vendors in the market, we been able to quickly (within a week or two) identify the best fit pool of vendors that can address the high-level (and meaningful) requirements of our clients. This short, sharp and low cost approach accelerates the selection process, quickly separating the wheat for the chaff and allowing the buyers to concentrate their efforts on a deep review of only a very small handful of solutions; not spend a week or more reading through a very tall stack of responses to an overly complex RFP.

However, this article isn’t meant to be a commercial for our services but rather a long overdue eulogy for the RFP as the buying document of choice!

Keep in touch and sign up to our Newsletter