An excellent post from Adam Hyde (February 2022) pointed out one of the limitations of the request-for-proposal (RFP) process, used when a purchaser wishes buy a large-scale software solution.
As Hyde points out, one obvious limitation is that simply asking the vendor if they provide X or Y is somewhat pointless if the requirement is obvious. Now, I can see this from the customer point of view. When buying, say, from Amazon, how many times do we realize once we have purchased a product only to find that it doesn’t have a feature that we expected to be present? It is that feeling of powerlessness that makes purchasers of goods or services compile a list of features offered by competing products, for example, a smartphone with 5G, or NFC.
But for an RFP, the problem is rather different. You don’t use an RFP when you are buying a smartphone or a TV. Buying something less distinct is not the same. RFPs have multiple issues, in this case:
First, as Hyde points out, the presence or absence of a feature may not tell the whole story. A classic example of the cloudiness of features is the dreaded word “free”. Does the software have a free option? Of course, everything nowadays might be free – but only for 14 days, or 30 days, or only for one user, or for a limited functionality. Perhaps not all terms are as full of ambiguity as “free”, but in my experience RFPs abound in terminology that turns out to be less specific than intended in the document.
Secondly, you can only ask for features that you know about. If what you really want is someone to rethink your business process from start to finish, and to come up with a new way of working that saves you £££ in coming years, it is difficult, if not impossible, to express this in an RFP feature list. This is particularly true of new technology such as AI tools, which often provide solutions users are simply not aware of when they carry out processes by hand. The plagiarism check, for example, is something that simply was not feasible by hand –comparing a text with thousands, even millions of other texts, simply was not possible. A machine-based approach provides a highly effective check for examining boards and for publishers (and for researchers, if they choose to use it).
Trying to define a user experience via an RFP can be described by the analogy of the restaurant. As a diner, I can choose anything from the menu – which is fine, as long as I like what the restaurant provides. The restaurant does not exist, to the best of my knowledge, that produces no menu but offers to propose something suitable for you following a discussion about your preferences and interests. Some waiters might argue that is exactly what they do, but for the most part, the job of the waiter is steer you to the options on the menu.
To summarise, there is a fundamental problem with RFPs. If you are buying an off-the-shelf too that works as an API, then you don’t need an RFP – you just state the specification. If, on the other hand, you are seeking a service alongside a product, and you want a relationship with a software provider that includes an element of creativity, then an RFP is not the way to go. If you treat purchase of what is essentially a service like a shopping list, then you deserve all you get. That magic sauce that you read about on the menu may not at all be what you need.