Roberta Moore’s recent blog titled Less RFP, More PoC is one that will resonate with anyone who has been through the pain of writing, completing, or trying to evaluate an RFP which includes sections on functionality.
Including questions that are too broad is a common approach, e.g. “Do you handle derivatives?” One vendor’s view of supporting derivatives may be fundamentally different from another’s and one may support a much broader range of derivative types, but both will answer “Yes.”
So, is the answer to ask more explicit questions that require a detailed explanation? Experience says no.
I've done RFPs in the past where I spent many hours carefully putting together questions which explained in detail the functionality that was required and asked the question, "How does your system/service provide this functionality?" The key part of that question is the word "How." A question with "How" in it is asking for an explanation, yet so often the response would say something like, "Yes" or "Fully Supported." Those are answers to a different question such as, "Do you support this?", but not an answer to the question that was actually asked.
When evaluating and scoring RFPs, I always put the responses from each vendor side by side then work through each question in turn in an attempt to compare and mark them consistently. Usually I was thwarted by the difference in style of response—even where I'd carefully asked very detailed and explicit questions. Responding with "Yes" to a "How" question did not lead to a good score!
So, what approach should we use to get from a long list to a short list which can demonstrate that we have a proper process that is still efficient?
An approach Citisoft has used on a number of occasions is to issue a briefing document to long list members. This would be kept short, maybe 2 or 3 pages, and would give an overview of functionality required, volumes, locations, and other important information. Each long list member would then be invited in for a workshop lasting a couple hours with the objective of the vendor or service provider convincing the asset manager to put them on the short list—and to convince themselves that they wanted to be on the shortlist. The vendor/service provider would normally include a demonstration in these workshops, but we need to recognise that some products/services are very difficult to demonstrate, so it should be down to whatever is appropriate.
The short list was then determined based on the workshops. Vendors always appreciated this approach as the amount of time a vendor required to prepare for and deliver a workshop was far less than preparing an RFP response, and it gave them face time in front of the prospective client.
The evaluation of the short list would then be via POC and structured demonstrations, but at this point both the asset manager and vendors involved knew they were genuinely interested in each other, and that there was a good chance that vendor could be selected.
Many organisations insist on the search and selection process using a robust strategy that will stand up to scrutiny and where there is clear justification for decisions taken. The RFP is still part of that, but I strongly suggest that the bulk of the RFP relates to the financials, legal, and corporate structure side of things—and that RFPs are only requested from a small number of vendors.
Quite simply, RFP responses do not give reliable descriptions of available functionality, so should not be used to try and obtain that information.
