The RFP process is failing businesses and tech vendors

I think I speak for just about everyone when I say, RFPs - we hate them. A necessary evil? Perhaps. Optimised, result-focussed, and efficient? Absolutely not.

For a good chunk of the last decade I ran the sales function for an enterprise/public sector-facing software and services business. Some of our sales opportunities came to us direct, some through our partners, some through recommendation, and many via the old-school, tried and tested (but not trusted) RFP approach.

Whenever a prospect would tell me, “We’re going out to market later this year”, my heart would sink. And not because I didn’t think we could win it (we often did), but more because in our experience the traditional RFP procurement process is not optimised for meaningful business outcomes. It’s often little more than a box-ticking beauty contest. Not to mention a complete time-sink and mood-hoover for everybody involved.

For those who have seen me speak publicly over the last few years, you’ll have already heard some of this, as I’ve been long advocating for a different approach to digital procurement.

But here are the top five reasons why I believe the enterprise RFP process is failing organisations:

1. Long-winded

Time waits for no one. In my experience an RFP process will take 4-6 months minimum. And believe me, many have taken a lot, lot longer than that.

But your customers and competitors are not pressing the pause button whilst you write your RFP, distribute it, score the responses, down select, negotiate, and then contract. With every passing day, week, month (sometimes year) your customers are being courted by others, and becoming more and more tempted by their faster websites, more reliable apps, and ultra-responsive service. Whilst your functional leaders are becoming more and more jealous of their profit margins, CSAT scores, and staff retention.

The problem here is that RFP processes are just so resource intensive, and generally being run by people who have a million and one other things to do. That’s why timescales can drift so dramatically. I was once involved in an RFP process in which the GSI (I’ll keep their name out of it) claimed to have sunk £500k in people costs during the process. I’ll leave you to work out who ultimately paid for that. 

If you’ve been fortunate enough to survive the process, and it turns out you are indeed the fairest of them all, every ounce of excitement, enthusiasm and energy for the project has dissipated – much like your competitive edge. 

2. On-prem focused

Let’s face it, on-prem is all a bit 2010. But virtually every RFP that hits my desk is still written with an on-prem outcome in mind. For example, we’ll often find questions about provisioning hardware, or how upgrades or change requests will be handled. Because for the prehistoric vendors, that’s a big part of the cost of the solution. But where’s the consideration for modern, innovative vendors, where the solution is multi-tenanted and runs in the public cloud?

Now, you might tell me that this doesn’t matter, because we could simply explain to the prospective client that half of their RFP is irrelevant, and then we’ll save loads of time not having to answer most of the questions, so what are we complaining about?

Wrong! On more than one level.

Firstly, RFPs are often scored on yes/no answers, and if yes is a pass, no is a fail, and irrelevant isn’t an option, then that’s a problem.

Secondly, and more importantly, in the 2020s on-prem probably isn’t the right solution (that’s not always a hard and fast rule, but it’s generally true), and if your RFP is scoring responses based on previous-generation tech assumptions you’re not going to get the outcome you wanted. Henry Ford allegedly once said, “If you always do what you’ve always done, you’ll always get what you’ve always got”, and he died before on-prem was even a thing!

If you’re looking for transformative innovation, you won’t find it via an RFP. I see so many RFPs where the questions assume the old way of doing things, and the format doesn’t allow for innovative vendors to highlight how they are different from the incumbents. Just stop it!

3. The kid in a sweet shop

Primarily because the RFP process doesn’t work very well, the response documents are often written with the objective of finding a solution that will do absolutely everything the writer can think of right now. The operative phrase being “right now”. How do you know what you’re going to need in 3 years’ time? How do you know what’s going to be available in 3 years’ time?

I get it – you needed to find a way of scoring the various responses and, asking yes/no questions about features (“does it do this; can it do that”) is one way of sorting one provider from another.

But this approach is flawed for multiple reasons, not least the one mentioned in point 2 above, but also because features are not business outcomes… they’re just features. It also encourages poor behaviour from your responding vendors because there’s a clear incentive to claim as much functionality as possible in order to be down-selected. Regardless of whether the claims are true, or not.

It’s a bit like having Max Verstappen’s RB18 on your driveway. Sure, it’s a fabulous car, jam-packed with the very latest automotive technology, and one of the fastest vehicles on the planet.

But you can’t drive it to work.

4. Technology focused, rather than problem focused

Somewhat linked to point 3 but deserving of its own airtime is the matter of technology. By its very nature the whole point of running a technology RFP, is to... well… source technology.

But technology doesn’t solve problems on its own. It may provide the means, but it’ll never provide the answers. So, whilst the majority of enterprise leaders understand that business survival is all about solving problems, I’ve rarely seen an RFP that even references any meaningful problems they’re trying to solve.

And by ‘problems’ I don’t mean, “our existing solution is out of support”, or “I want to cut infrastructure costs”. Both of those might be a good reason to make a change, but they are not something to measure or compare prospective tech vendors against.

By problems I mean, “we need to improve business agility”, “we need to automate 50% of contact”, “We need to improve staff productivity”, “we need to increase sales conversion by 30%”, “we need to fully integrate our tech stack”.

Not only are these examples of the real problems businesses are trying to solve, but they are also a much more meaningful way to compare tech providers and partners.

5. Often undermines the relationship

For me, building a strong and trusted relationship with our clients is basecamp one. We’ve always been pretty choosy about who we work with. We want everybody to be pulling in the same direction, we want to enjoy the project, and we want to deliver meaningful outcomes for our clients.

However, in my experience RFPs do not start relationships on the right foot.

Let’s say we survived the process and managed to get through the contract negotiations. Now, we’re both contractually obliged to deliver on whatever is in that contract.

But what if something new comes to light during the project, that will dramatically influence its outcome? Do you really want to hear, “sorry, that’s not in scope” whenever a new idea, or a better way of doing something is found? Because that’s what happens. Every single time. And then frustration builds. The all-singing, all-dancing tech platform that you just committed the next five years of your life to isn’t going to deliver the outcomes you need today. Because you tried to define the project’s entire scope 24 months ago when the RFP was launched. Eventually trust breaks down, and the relationship turns sour.

And all because of that RFP.

Introducing the RFS

In my experience, most RFPs are terrible. The process feels like it’s been around since the dawn of time, and much like dinosaurs, penny farthings, and Blockbuster video, it’s simply no longer fit for purpose.

Responding vendors can be qualified-out for several reasons, but features should never one of them. Just because a solution doesn’t offer a particular feature, doesn’t mean it’s not the right solution. Features are of no consequence if the solution solves your most painful problems.

Your RFPs should be focused on problem solving. So rather than asking vendors to answer standard feature questions, instead ask them to submit a solution to your problem(s). At Acceleraate we call this a “Request for Solution” (RFS): Rather than creating a response document with a list of required features, start with what you are trying to achieve, define how success will be measured, and work it backwards from there.

The vendor scoring then becomes quite straightforward:

Problems solved

(multiplied by)

The impact of solving said problems.

…And so too is your business case.

A core tenet of our approach at Acceleraate is a laser-focus on problem solving with technology. In fact, we can even help you identify the problems that you most need to solve. So, if you’re planning to run an RFP soon, get in touch with us before you do. We can help you to design and deliver a modern, appropriate, and impactful RFS process, which will not only make sure you purchase the right solution, but also ensure you deliver the most impactful and meaningful change.

All whilst consigning that pointless RFP process to the history books, where it belongs.