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. Our clients 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 over $1 million each year continuously extending our platform to keep at the forefront globally.
There are still some organisations that don’t use our services. Eventually though, they decide they want more from technology for themselves and their community. So, now comes the tricky bit - how do you approach the market?
Sometimes they issue a formal RFP. What is an RFP? In our industry, a Request for Proposal is a document sometimes 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 those needs 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. Often vendors are also expected to travel to the client to present their proposal in person.
All of this is expected to be done by vendors for free, as some sort of investment in the hope of winning the business.
The cost of responding to an RFP in terms of time and travel is normally somewhere between $2,000 - $20,000 depending upon the complexity of the project, the number of staff we need to involve, and whether we must also fly people to the client's location to present our proposal. An average RFP normally represents around $10k of cost to each vendor, so if 5 vendors have been invited to respond, this introduces around $50k of total cost that vendors must ultimately collectively recoup back somehow (remember that only one of them will normally "win" the RFP).
Most RFPs tend to be highly prescriptive in detailing the technology or requirements. And they dictate a timeline for delivery. Typically, the client (or their advisor) is either self-diagnosing their needs, or they are simply describing whatever existing system they want us to replace. And the inclusion of a timeline assumes they have the expertise to know what a reasonable timeframe is for software development and deployment.
The RFPs we receive often describe the digital technology that a client is currently getting from other vendors, such as websites, online registrations, e-commerce, national database, member management, competition management, and third-party integrations. The expectation is that our proposal document will describe how we’ll replace incumbent technology. However, many RFPs fail to identify exactly why the client has decided their incumbent technology is no longer suitable. RFPs tend to deny us the opportunity to go through a discovery process that lets us use our own expertise to make recommendations. This can rob the client of the benefit of our years of experience.
Another failing is that RFPs often contain many unknowns. Although RFP processes normally include a formal opportunity for vendors to ask questions, it can take time for the back & forth necessary to clarify undocumented requirements. In the absence of clarity, vendors either make outlandish claims, or they pad their pricing, or they introduce loopholes and caveats to their proposal to protect themselves from the unknowns.
The other challenge with an RFP is that it ignores the fact that good vendors are normally heavily committed with other clients and projects. Let’s say that our company has the best solution, best support, and the best price. Now, if we're simply unable to respond to an RFP within the specified timeline because we're busy with other clients, then the RFP process has automatically prevented the client from getting the best solution. 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 often the first page they'll turn to. Knowing this, the vendor that needs the sale the most (i.e. often the vendor that is otherwise least successful in the marketplace) tends to submit cheaper pricing. If the client chooses this vendor, there's a real risk 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 NSO years of trying to work with a sub-standard product before they decide to go back to the market.
Lastly, there's the issue of timeline. Often, national sports organisations or their advisors have taken weeks or months just to create the RFP document. Translate that into thousands of dollars of time and effort. NSOs tend to justify this time and expense because the project is important to their organisation, and it will commit them to years of whatever solution they choose. But here's the rub. These same RFPs often give vendors just days or a few 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 a better alternative to the RFP process?
We recommend engaging vendors for a technical discovery process instead. Not just with us, but possibly with another vendor as well. The starting point is a free discussion for you to satisfy yourself that we're likely to be able to help. Ideally you will then allocate some budget to engage us to explore your requirements in greater detail. This allows you to receive recommendations that are likely to go way beyond anything anticipated by an RFP. And you’ll gain 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 project we can 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 of a paid discovery process is normally 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 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.
Lastly, we must be convinced that you've selected us with care and we are not just one in a list of multiple suppliers. If you haven't been in touch with us to discuss your needs during the weeks and months prior to issuing your RFP, then we need to be convinced you have still 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.