Running a Technology Software RFP
Conducting an RFP can be a daunting task. Here, we explain what an RFP is, what you should know before you issue one, and how to run a smooth RFP process.
What is a RFP?
An RFP (Request for Proposal) is a document issued to organisations requesting a written response to outline how their services meet your needs, including a pricing proposal.
​
More broadly, we refer to an RFP process as the stages through which a tender is managed.
​
Here, we consider how to effectively scope, document, issue and manage the responses and subsequent process of an RFP in the context of procuring a technology service, although the majority of the guidance here applies in any other context.
What is the objective?
Get clear on WHY you're buying something first
Once you have a clear objective, do your research. Understand what products may be a good fit for your needs - use tools like Gartner, internet keyword searches, and discuss with your network. Informal discussions with potnetial vendors can be invaluable in clarifying your thinking and understanding whether you can get what you think you can get from any vendor.
​
If you can't articulate what you need, you're going to struggle! This may seem obvious - you'll likely already have a good idea of this to have determined that you need an RFP. However, the more clarity you have, the greater chance that you're efforts will be a success. Common pitfalls include convincing yourself that a lack of clarity is OK - the RFP will help you answer it. Sometimes, that can be true, but often this subconscious delaying tactic. This can lead to unwieldy responses trying to tick all boxes but leaves you with many options to understand and try to compare.
​
Ideally up front, but certainly before RFP responses are received, you should agree your scorecard. Firstly by section, then by sub-section or even question. You may have pre-requisites - often 'yes' or 'no' questions which, if cannot be answered in the affirmative, disqualifies the vendor from the process. Then, based on your objective, decide how much of the available 100 'points' will be given to the relative commercial, functional and other sections. If you're highly price sensitive, perhaps 50% of the weighting should be based on cost (total cost, not headline cost). If securing the very best functional fit is critical, then perhaps 50% of the weighting should go to that.
There's no one-size-fits-all answer, but agreeing on this before getting responses means you objectively remove the emotion from the process later.
​
How complex is your requirement, and how time-critical is the selection? Deciding on how long to give vendors to reply is a key decision, along with what access you give them to you during that time. Three to four weeks tends to be an optimal period but could be shorter for simple requests or longer for more complex needs. Allowing vendors an opportunity to ask clarification questions during the process is a critical step - though should be timeboxed - e.g. all questions to be submitted within two weeks, responses provided within one week, with a further week to deliver the RFP responses.
Get clear on 'must haves'
Not everything needs to be questioned.
If you're buying a new TV, you don't check that it comes with a plug and that it generates light when turned on.
The RFP should follow this logic. It is not a complete list of all your possible requirements - it is trying to look for ways to separate the key strengths and weaknesses of the products or vendors you're considering. This is truer than ever now: when many of your options will likely be SaaS products, you have a good overall fit to your needs rather than a promise to build a bespoke solution.
​
Every RFP will be different but typically will include:
- introduction - sets out who your organisation are, what you're looking for, and some context to help potential vendors understand how they could fit into the bigger picture
- functional - what it is that you need to product to do
- architecture, infrastructure and security - including non-functional requirements
- service management - what level of support do you require?
- commercial and pricing - ensure you're asking for clarity on what pricing covers, what it doesn't cover, and any other costs you should reasonably expect may be incurred. This could include standard and optional modules and a rate card for work they may carry out.
You may also ask vendors to agree to your standard T&Cs and confirm that they hold relevant accreditations.
​
To reiterate - the RFP is a means to an end, not an end itself: don't feel the need to ask every possible question. You're simply trying to filter out those who are not a good fit for your needs, and provide a platform for further discussion with those that do.
"The RFP is a means to an end, not an end itself: don't feel the need to ask every possible question. You're simply trying to filter out those who are not a good fit for your needs, and provide a platform for further discussion with those that do"
What commercial arrangement do you need?
Make it possible to compare the reponses you get
To bring enterprise-grade software into a large organisation, it should be expected that some degree of configuration or customisation will be required.
​
Are you looking for software alone, to implement yourself or through an existing delivery partner? Do you want to procure the software and the implementation through an implementation partner? Or maybe a hybrid of both - work towards selecting the software and determine the implementation partner in tandem?
​
This is a critical decision!
​
For any development services, how do you want to contract - a fixed rate or variable based on how much effort is incurred (T&M) - and how strongly do you feel about this - is it up for discussion? It may be excusable to ask for a couple of options at this stage (though see the next section).
​
Next - how long do you want to contract for? As a rule of thumb, the longer you commit to, the better deal you can secure. Of course, this needs to be traded off against the risk of changing needs and the product no longer being required before the contract period is over. The same applies to the scale you commit to (e.g. number of users) - a higher commitment should secure a better deal - but unused licences are not good!
Get consistency
Make it possible to compare the reponses you get
A major pitfall is to leave too much open for the vendors in the RFP. It may feel safer to leave open questions and options ("we might take this or that additional service - please quote separately"). It can seem like you 'buy time' and defer decisions until you have more information back from vendors. But invariably, this can prove a costly mistake.
​
​
By being decisive upfront, you ensure that, as far as possible, you can compare the responses on a like-for-like basis.
What next?
Moving forward to a decision
So you've issued your RFP and received the responses. You've scored the responses based on your prior agreed weighted criteria. You've maybe removed one respondent when it becomes clear they can't meet your needs.
​
Next, you'll typically move to a more in-depth discussion with some vendors, usually involving a solution demo, a presentation on key areas, and a Q&A. The more information you can give to vendors up front, the more effective this will be. Tell them what your concerns are so that they can prepare a response: you're not trying to catch them out, you want to understand what they can offer.
​
Beyond this, you want some evidence that the product does what they tell you it does. This is best achieved with interaction with their existing customers - in the form of a meeting or perhaps even going to see the product in action. These 'reference customers' are cherry-picked - they won't take you to the customer who has never got value from their product! But careful questioning can demonstrate the strengths of the product and test your own understanding of the areas of weakness.
​
Onto commercial negotiation, and the above guidance on the engagement model is key once more - remove as many options and uncertainties as possible to allow focus on the key topics. Understand their drivers to seek win-win outcomes - e.g. if getting revenue through the door this year is a top priority, can you front-load costs to get a better deal?
​
Finally, be kind
Remember, behind the corporate, there is real people
OK, so you're working for a big organisation, looking to spend a lot of money on a new package. You hold a lot of the cards - you can push the boundaries in a way you wouldn't with an internal stakeholder... short deadlines on a complex request, making people squirm with abrasive statements and questions.
​
But that's not a great approach.
​
The people you're working with from your potential vendors do not really want to spend their weekends writing up the RFP because you set a short turnaround time on it. This is the start of a (hopefully) strong working relationship, and goodwill can get you a much more transparent and constructive dialogue than grinding people down likely can. So don't be a d*ck.