I decided that I am going to tell you the truth!
Before that, however, let’s start with an opinion: the process of using RFPs as the means to select a software vendor, especially for business process management, simply does not deliver good results. It is fundamentally flawed.
My assessment comes from having sat on both sides of the RFP fence over the past 17 years: both as a purchaser and as a vendor. Of course, evaluations are needed. Sometimes at minimum to meet internal governance criteria. You need to review functional fit, architecture and integration, vendor experience, and assess the market for price comparisons to make sure you are getting a good deal. The question to ask is whether the RFP is fit for purpose.
The advocates for the RFP, including those consultants who offer their services to manage the process on your behalf (for a ‘reasonable’ fee, of course), will state that it is considered a tried and tested, fair, corporate governance conform, structured, control enabling process to purchase technology. A list of benefits would typically include the ability to:
- Make sure that the organisation gets together to define a unified set of requirements
- Set the structure and use cases for product demonstrations
- Enable direct comparison between vendors
- Define and agree on an undisputable and equitable selection scoring methodology
It sounds ideal. What could possibly go wrong?
The Things That Can Go Wrong
The RFP process is inherently divisive, both within and without your organisation. If the goal is to build a true, long-term partnership with a company that will support you in the journey to address significant major strategic change (for example, the optimisation of your commercial excellence processes), then an RFP is almost always a poor way to proceed. It cannot guarantee project success and it does not lead to guaranteed value.
Let me share a few examples from real-world experience….
What typically happens in the effort to gather ‘a unified set of requirements’ is that an Excel template is defined. This is loaded onto an internal shared-drive and anybody with an opinion is invited to add to the list of features. Each contributor individually decides what they consider critical to the companies’ future success. The more the merrier.
Truth # 1: I have worked on RFPs where the same requirement is included 3 or 4 times, in slightly different language, clearly documented by different individuals. These end up left in the RFP as the customer did not have the time or patience to consolidate the list.
This free-for-all, or avoidance of controversy, conflict and protracted debate, leads a long list of features and functions. Many of these may not actually be required, but as we’ve stated, it takes a big effort to get to a shortlist. These features then need an assigned ranking: from mandatory through some middle ground, to the lowest level ‘nice to have’. Erring on the side of caution, an overabundance of these features tend to be marked as ‘mandatory’. Vendors responding to the RFP are then forced to make on their mandatory feature compliance. Non-compliance raises a red flag and will require an explanation. So, what should one do?
Truth # 2: I can safely say that all vendors lie some of the time on their RFP responses*
(*) To put forward the case for the defence, it is not altogether the vendor’s fault. They are backed into a corner. The feature list appears more like a wish list. The question can be interpreted as whether it is possible and as we know, anything in technology is possible, it is just a question of cost. At the end of the day, the structure of the RFP evaluation means that Vendors don’t really have a choice but to state that they are compliant.
Then it comes to the vendor presentation and demonstration sessions. Companies gather the entire team into a room (or these days into an online session) for a week and ask them to evaluate the software: 4 vendors in 4 days or if we are all unlucky, 4 vendors in 2 days. It is an exhausting process for all. Each demonstration ends up blurring into the next. In review, the team finds it difficult to separate the solutions. Everything looks the same. The outcome being that “all vendors can probably meet the requirements”.
No wonder, after 30 minutes of introductions, each vendor has between 60 and 90 minutes to rush through as many key features of their solution that fit your requirements. At the end of it, the team is asked to make a judgment call on the software that is going to underpin your commercial excellence strategy for the next 5 to 10 years. That’s a hard ask.
Truth # 3: It is interesting how often in projects we are asked to deploy a piece of functionality that clearly belongs to another vendor’s solution; the proverbial red button as opposed to the blue button that we offer. The “demo blur” phenomenon really exists.
Respondents to RFPs are by default driven to try and make their proposal seem better and more economical. In responding to an RFP, instead of trying to include all potential costs, vendors will exclude any costs that can be taken out. Saved for later. Making their solution appear more attractive.
Lastly, there is supposed to be an indisputable selection scoring methodology for the evaluation and the RFP response. This scoring mechanism is however normally, to avoid unwanted bias, kept from the broader team. What happens if the owner of the scoring has a vendor bias themselves?
Truth # 4: I have witnessed, admittedly not too often, a project lead adjusting the score weightings to ensure that their preferred vendor comes out clearly on top. So maybe not as equitable as one might think.
Truth # 5: Projects don’t tend to fail because of the technology chosen. More often than not, they fail to succeed because of other reasons: namely people and process.
A 2019 study by NewVantage found that cultural challenges remain the biggest obstacle to business adoption. Executives cite multiple factors including organizational alignment, agility and resistance, with 92.5% stemming from cultural challenges (people and process), and only 7.5% relating to technology.
So here we have RFPs, that consume a huge effort and time, do not actually work so well, are designed to select technology, and that in the end only account for 7.5% of the total project risk. That does not seem to make too much sense to me.
Maybe there is an alternative.
Understand who you’re choosing
The first important step seems to me to be to understand that you are not selecting a ‘vendor’. From the Merriam-Webster dictionary: “Vendor: one that vends: seller”. It is just so finite in its definition. A single act of sale and purchase. The acquisition of commercial excellence software is however the beginning of a long, hard journey. Much better to select and work with a long-term strategic partner for that journey than a vendor.
If you accept that you are looking for a partner, rather than a vendor, then the logical conclusion is that assessing only their technology (and price) falls far short of the mark. You need to assess this more broadly. You need to understand ‘Fit’ and Fit comes in many forms: definitely functional (the technology does need evaluating – I am not saying ignore it), but also in terms of culture, competence, and value position.
This assessment cannot be completed as a theoretical exercise, with a question-and-answer-based response, and it will take more interaction than just a 3-hour presentation and demo session.
You need to validate the value and address the risks that will come from embarking on a commercial excellence transformation. The earlier you engage with a partner (even before final selection) the more likely it is that your project will achieve success. If you wait until the project has started to engage executive sponsors with each other and find out if there is a cultural fit, a meeting of minds, then it’s too late.
If you wait until the project has started before evaluating data and integration requirements to understand technical fit, then it’s too late. If you wait until after the project has started before loading your data into the software and checking in detail for user acceptance and likelihood of adoption, then it’s simply too late. If it is too late, you end up with significant project risk.
A good partner will work with you not only to build a joint business case, but to ensure that the solution is set up to measure success.
Truth # 6: Strangely, and even though all projects require a business case with a compelling ROI, many companies will fail to set themselves up to measure that ROI.
This means when the project hits a bump in the road (this happens) and you are not able to answer management’s questions around the value you are delivering, things get tricky for the project’s livelihood. A good partner will understand that commercial processes, especially around pricing, are unique and vary significantly from company to company. Making sure that there’s a good fit to your specific process is critical to long-term success. This needs to be tested, with your data, with your process in the partner’s software during value validation – again, before it’s too late.
Truth # 7: A good partner will understand and be honest that commercial excellence transformation is not easy. It takes hard work and collaboration to achieve long-term project success, growth and profitability.
“The pure and simple truth is rarely pure and never simple.”
Oscar Wilde