RFI or request for failure?
Having spent seemingly endless hours answering procurement RFIs over the years, I found myself working on something last night, when I had a moment of déjà vu.
Was this the document I received the other day from a small SME with low staff numbers and minimal procurement needs bar a large cultural hurdle, or the document from a large multi-national organisation with inventory requirements I worked on a year ago?
At RFI question one hundred and fifty, I got thinking…
It is endlessly frustrating reading requirements lists that seemingly do little to ask questions that address organisational needs. The lack of clear statement of goals and organisational vision is the most obvious omission, not made any clearer by the tsunami of questions.
The same thing in every document. No granularity. No differences. I get the impression that there is someone out there offering a service to duplicate and distribute RFI documents for a small fee. If this is the case, they are doing rather well!
I ask myself what is the result of a document prepared in such a generic fashion? An effective tendering process and best-fit solution or a failed implementation? A solution that misses the opportunity to harness the strengths of the solution provider? It seems silly to me that the organisation would not state its organisational procurement goals. Why withhold important information and aim for mediocrity?
If the premise is that an RFI forms part of a structured tendering process, this implies that there has been an internal process that aligns to the overall organisational goals. This process collated the needs of groups and individuals in order to best match potential candidate solutions to these requirements.
We all know that organisations are not homogenous entities. While there are always commonalities, each organisation has its own unique environment and approach to the business they are in. This means that when it comes to matching a set of requirements to these needs, there are always going to be some differences. Forming a direct link between requirements and potential solutions is the first step to ensuring that the chosen solution meets these needs and can be delivered effectively.
The standard approach of writing a document that includes every possible option, indeed trawling the internet for ideas on functionality, that may ‘possibly’ be useful to the organisation and then issuing this as a ‘considered’ RFI to potential providers seems to be a recipe for disaster. A successful solution needs to support all genuine requirements, along with beneficial cultural change.
Those tasked with such activity seem to spend little time really examining the requirements and producing a document that allows a potential supplier to correctly match the solution to the needs. Those that do are rare and it is always a pleasure to have these documents come my way.
This generic approach, in my experience, leads to a failed or badly received procurement solution.
Vast rafts of functionality do not a procurement solution make.
A badly written RFI is less a request for information and more a request for failure!
My point is that if companies want the best-fit solution with the highest chance for success, then they need to produce the best fit RFI document or use another approach, not just the longest or most complex. There is nobody to blame when the results are poor if the wrong questions are asked. The better the quality of the requirements, the more likelihood that the best solution will naturally be the most obvious choice.
Well that said, I should probably get down to completing these remaining two hundred questions….
We have a whitepaper to help you, 7 deadly sins of software selection, to download here.