Periodically, we talk about procurement at ComTech. For example, we had a CTRMRadio podcast episode on it back a couple of years ago and we have written about it frequently on this blog. We continue to envisage a change on how CTRM and other software procurement is done away from the old RFI/RFP process and to more of a trialing approach with solutions in the cloud. This, of course, driven primarily by the migration of CTRM to the cloud and to SaaS through time.
You see, the old RFI/RFP process is time consuming, expensive and, well, likely flawed as a process for a variety of reasons. A favorite of procurement departments especially in public companies that need to demonstrate an open process, this approach can actually be shown to be fraught with risks and expensive. Back in 2017, in a humorous blog on the topic by David Calmonson, he estimated the average RFP to cost 88,000 GBP and he claims that to have been a back of the envelope type calculation with the cost often far exceeding that number. In my follow up blog back in 2017, I went through some of the risks with the RFP approach…it is worth repeating so I reproduce it here.
The first thing to note is that these processes are often managed by third-party consultants. The consultants will usually have a template process and can save the customer time by bringing a pre-existing template replete with all the questions one might expect to the table. All that needs to be done to this document is add the customer specific questions and its ready to go. Well, is it? In practice, many of these template RFP’s have been round the block a bit and as a result may contain all kinds of totally irrelevant questions and requests to demonstrate functionality that is not needed at all. This is where the monster RFP document David refered to often comes from.
AdvertisingAdvertisingAnother commonly used approach suffers the very same fault. It may be that the buying company found or borrowed an example RFP and then simply adopted it. They add the specifics of their circumstances but forget to remove anything unnecessary.
Either way, the RFP is not efficient at all. It needs to be thoroughly scrubbed and checked before it is issued to anyone.
People have to make decisions one way or another and so scoring and demos are par for the course. The issue here is to ensure that the scoring actually represents the buyer’s needs. This comes down to weighting of course and making sure that the scoring mechanism is weighted to reflect true priorities. The scoring mechanism will undoubtedly cover all questions asked by the RFP right? So, if that RFP had a bunch of irrelevant questions in it dating back to another time it was used, they get scored as well. Which means that using a template RFP without really being rigorous in validating and scrubbing its content not only wastes time for all concerned but it could in fact lead to a result which is not the best for the company.
I have heard it grumbled that some consultants favor certain vendors – I am sure we all have actually. However, I don’t believe that they do so consciously. But, could it be that their template RFP, built up from working with certain flavors of software over time, accidentally favors a certain outcome? It is a possibility isn’t it and therefore another reason to scrub the template hard before re-using it.
To those observations on the faults of the RFP procurement process I might add the absence of any real opportunity to try out the software, generally bash on it and perhaps learn a bit more about the flexibility, configurability, and key strengths of the software. The problem with highly configurable software is complexity. Sometimes only a few key vendor staff truly understand the potential of the software. This can often result in costly mistakes when implementing with work arounds and enhancements that are simply not required. But that test drive is so important and usually either missing or very tightly controlled during an RFP process.
Compare and contrast that with a paid trial. There is no implementation as it is delivered in the cloud. Users can play with it in anger. Try to break it. Where they see problems or potential issues, questions can be asked and the vendor is able to show how the software could be deployed for specific instances. This can all be done in a fairly short timescale – weeks not months – and at a cost far below the 88k GBP estimated by Mr. Calmonson. Users can again familiarity with the software, the support staff and the vendor. In most scenarios, this approach surely has to be cheaper, less risky and result in a smoother implementation and better acceptance of the solution? It is probably cheaper as well.
To get to that point, rather than use an RFP process, buyers can utilize ComTech’s market sweep whereby we identify a small group of possible suppliers based on some high-level requirements and our knowledge of the market or similar process. Or, it could be via a series of demonstrations with a variety of vendors after doing some due diligence and fact finding.
Yet, as we talk to vendors, it seems the old RFP process still dominates. This process is supposed to afford visibility and fairness into the selection process but there are many ways in which that process may not be fair, well performed and open just via accidental factors like those cited above.
Isn’t it time to migrate the procurement process as well as the software?
What do you think?
