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 in other countries such as 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 remain 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 our solutions have greater popularity than many of 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. In extreme cases, the RFP requires vendors to provide prototype software or a 'sandbox' environment.

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 not. 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 done, 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 many RFPs we receive. Either the client is self-diagnosing their needs or they are simply describing whatever existing technology they want us to replace. The RFP assumes that the client (or their consultant) has enough technical expertise to dictate a 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 unfortunately 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 can 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 stated 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 vendors 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 they'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. Some clients have taken weeks or months of painstaking effort to create their RFP document. Translate that into thousands of dollars of time and effort 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 to whatever solution they choose. But here's the rub. Those same clients will often issue RFPs that give vendors just days or weeks to formulate a response. 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) both up-front and ongoing.

Vendors need to know that the value of the project is sufficient to justify the significant investment necessary to create a proposal in response to your RFP. And we must be convinced that you've selected us with care and we are not just one in a list of multiple suppliers all jumping through hoops, each with only an equal percentage chance of success. If you haven't been in touch with us to discuss your needs during the weeks and months prior to issuing your RFP, then it's hard for us to believe you have performed the due diligence necessary to understand our capability and treat us as a serious contender.

We're here to help. The starting point is to please just contact us.

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