Online Support Centre


Why we may respectfully decline to respond to your Request for Proposal

Firstly, some context… our company provides an online platform for the sport and education sectors. We are the market leader in New Zealand and growing rapidly in Australia. Clients stay with us because we’ve proven they can rely on us to provide digital solutions that are well supported, on time, and within budget. We stay aware of advances in technology and we invest continuously in extending our platform to keep at the forefront globally. We’re recognised as experts and we have greater market share than all our competitors combined.

But there are still some organisations that don’t yet use our services. Maybe they’re stuck in an old contract or maybe they haven’t identified the need yet. Eventually though, they decide they could be doing better. So far, so good - they’re probably right. But now comes the awkward bit. How do you approach the market when your budgets are tight and your ambitions are... well, ambitious?

Unfortunately, they often issue an RFP.

What is an RFP? In our industry, a Request for Proposal is a document normally provided by a national sports organisation looking to upgrade their digital technology. It attempts to articulate what they think they need and asks vendors to submit a document in return that details how they are going to meet that need and at what cost. The vendor’s response document is usually expected to contain a host of other information about who the vendor is and their credibility, case studies, references, and the processes they will use during the project.

All of this is expected to be done by vendors for free, as some sort of investment in the hope of winning the project.

Now, some RFPs are well written, and some are clearly copied and pasted from other documents to the extent they become almost nonsensical. Most lie somewhere in between. But almost all RFPs are fundamentally flawed. This is because almost all of them attempt to prescribe the desired solution and dictate the timeline for delivery.

Think about it. Imagine there’s some unknown mechanical problem with your car. Would you take it to a mechanic and say, “Here’s my car. I’m asking you and a number of your competitors to provide a detailed quote on how you would fix its Flux Capacitor, including case studies of others you’ve fixed, along with references. Also, my timeline requires your work to be completed by Wednesday.”

The mechanic would hopefully reply, “A Flux Capacitor is not a real thing. It’s part of the fictitious time travelling car in the Back to the Future movie. Just describe your car’s symptoms and I’ll then use my expertise to identify what needs to be fixed, and provide a cost estimate and timing for you. By the way, this diagnostic exercise is itself chargeable and the soonest I can take a look for you is Thursday.”

As silly as this example may sound, it’s exactly what occurs in almost every RFP we receive. Either the client is self-diagnosing or has used a consultant to help prepare the RFP. The RFP assumes that the client (or their consultant) has enough technical expertise to dictate a highly prescriptive list of requirements that will solve whatever they perceive their problems to be. And it normally includes a timeline for implementation that assumes the client has enough experience in complex software development and deployment to know what a reasonable timeframe is. Both these assumptions are normally just plain wrong.

The RFPs we receive often describe the digital technology the client is currently getting from other vendors, such as websites, online registrations, e-commerce, national database, competition management system and third-party integrations. The expectation is that our proposal document will describe how we’ll replace the incumbent vendor. The RFP typically fails to identify why the client has decided the incumbent technology is no longer suitable for its needs. RFPs deny us the opportunity to go through the discovery process that is necessary to let us use our expertise to identify the real issues and recommend solutions. In doing so, RFPs rob the client of the real benefit of our years of experience.

Another failing is that RFPs normally contain many unknowns. An example received recently included the requirement for us to deliver a ‘World class CRM’. This was a single line item with no further description. Although RFP processes normally include a formal opportunity for vendors to ask questions, it could take weeks of communication to clarify the exact requirements of this single line item. In the absence of clarity, vendors either make outlandish claims (such as that ‘our CRM can perfectly meet everyone’s every need’), or they pad their pricing or introduce loopholes and caveats to their proposal to protect themselves from the unknowns.

The other challenge with an RFP is that they carry the risk for the client of being a ‘party that nobody comes to’. Let’s pretend that our company has the best solution, best support, and the best price (actually, we don’t need to pretend this, but I’ll say it anyway to avoid argument). Now, if our policy is to not respond to RFPs and the client is determined to issue an RFP, then their decision has automatically prevented them from getting the best solution possible. Increasingly, the vendors we see responding to RFPs are those who struggle to get business any other way.

Another flaw of the RFP process is that it tends to draw too much attention to price. As much as we might like to think that clients carefully weigh and balance all aspects of a proposal, the reality is that the price section is almost invariably the first page that you'll turn to. Knowing this, the vendor that needs the sale the most (ie typically the vendor that is otherwise least successful in the marketplace, and possibly for good reason) sharpens their pencil as much as possible.

So if the client chooses this vendor, the odds are they’ll end up with a supplier who exaggerated their capability, or whose price is inadequate to cover the cost of delivering a well-supported solution. By the time the client discovers this, it’s typically too late. The New Zealand and Australian sports sectors are littered with examples of oversold supply relationships that resulted from RFPs. Typically, it takes the sports code 3 - 5 years of dissatisfaction before they go back to the market (and hopefully don't just repeat the RFP process all over again).

Lastly, there's the issue of timing. Most clients have taken months of painstaking effort to create their RFP document. Translate that into many thousands of dollars of work and/or consultant's fees. Clients tend to justify this initial expenditure because the project is typically critical to their organisation and will ultimately commit them for 3 - 5 years and to a total expenditure that can exceed hundreds of thousands of dollars. But here's the rub. Clients will often issue RFPs that give vendors just a few weeks to formulate a highly detailed response document. If the vendor happens to be busy with existing delivery deadlines and prior commitments (and good vendors often are), then the client will either get a rushed response or the vendor may simply decline to submit a proposal.

In almost all uses of RFPs in our industry, the outcome for the client is poor.

So, what’s an alternative to the RFP process?

We recommend a paid technical discovery. Not just with us, but probably with another vendor as well. If the project is important enough, then it will justify the relatively modest expense of this process. By spending the time and money to do this up front, to use our expertise to examine your requirements in diligent detail, you’ll receive recommendations that are likely to go way beyond anything anticipated by an RFP. And you’ll have gained the experience of working with us through this discovery period. So you’ll develop a sense for our people and our capability that you simply can’t get from an RFP response document.

During the technical discovery, we talk with your key stakeholders – those people who know what’s working and what’s not. And we separate the ‘must-haves’ from the ‘nice-to-haves’. We also get a sense for capability within your organisation and we help manage expectations to ensure they align with your budgetary constraints. The outcome is a document outlining what we’ve learned, along with our recommendations for the best path forward and pricing. Our recommendations may include third party solutions where they are the best fit.

The benefits of this sort of discovery process are clear. It dramatically reduces the likelihood of the client selecting the wrong technology. It decreases the chances of key functionality having been overlooked. And it creates the foundation for a relationship between the client and the vendor that is essential for a multi-year project delivery. If we can’t earn the trust and respect of the client during the discovery process, then we are arguably not the right vendor to deliver the solution.

If you’re contemplating issuing an RFP, hopefully this article will encourage you to reconsider.

However, if you are determined to do so, please ensure it thoroughly describes the outcomes you wish to achieve, and avoid the temptation to prescribe exactly how and what vendors must deliver. Make sure you give vendors plenty of time to make the resources available that will be necessary to formulate a proposal document for you. Importantly, please ensure you indicate your budget, or at the very least an expected range for the entire project (and ideally an indication for each of the major components for complex projects).

Vendors need to know that the value of the project is sufficient to justify the significant investment necessary to draft a response document for your RFP. And we must be convinced that you've selected us with care and we are not just one in a list of 10 suppliers all jumping through hoops with a 10% chance of success.

If you think we can help you, please just contact us.

Was this article helpful?
0 out of 0 found this helpful