Writing an RFP for software is no different from writing an RFP for any technology requirement. It can also be easy to think that writing an RFP for HR software is going to be very different from writing an RFP for finance software - but you would be wrong. The same process and fundamentals apply to whatever software you are looking to buy. In this article we will look at everything you need to know about writing an RFP for software - so there is nothing stopping you from getting on and doing it!
Viewpoint Analysis works with companies of all shapes and sizes to run their software RFPs and we are unusual in that we are from the software sales arena. As such, we know exactly what the software vendors want to see when they read your RFP - and we know what they don't want to see and what will lead them to qualify out of your process.
What should the software RFP look like?
Your RFP document should be short, simple to understand, and focused on the problem that you are looking to address. It should be sent electronically and should be in Word or issued as a PDF.
The name of the game is to keep the RFP document concise. There are no prizes for making a project of creating the RFP. Too many businesses fall into this trap - they spend weeks creating the RFP and then follow this up with weeks or months to run the process. Following this path will lead to problems and potential failure. Keep the document tight - and keep the process short.
What elements should be included in the RFP?
The RFP should feature a number of key areas. When we write our Rapid RFP it includes the following sections but more areas might be added or removed depending upon the type of requirement.
The purpose of the RFP
Company information and background
The problem we are trying to solve
Timelines
Instructions for the response
Questions that need to be answered
Evaluation criteria - How will we make the decision on what is good?
Contact information for any questions
Sales qualification criteria - Budget, Authority, Need, and Time
Additional information that should be responded to
How should you issue the software RFP?
It is important that you speak to the vendors BEFORE sending the RFP. Too many companies still issue a 'blind RFP' - meaning that it lands on the sales team's desk without any prior warning. This is an instant red flag for the salesperson and they will almost always inform you that they are unwilling to take part in your process.
Call the vendors and talk them through your challenge. Tell them that you are going to issue an RFP and explain why you are following this process and why you have chosen them to be included in the RFP process. It is important to sell your project to the vendor and their team. No salesperson wants to respond to an RFP - yours will be no different. You need to inspire them and let them know why it is going to be a worthwhile exercise.
When you issue the RFP, make sure that the vendor has been given plenty of warning and always deliver it on time and as they are expecting. It should be sent via email and the vendor should have the ability to call someone to ask any questions.
What mistakes should you avoid when issuing a software RFP?
There are some key mistakes to avoid or you run the risk of losing some key vendors from your process:
Do not issue it blind - call the vendor to let them know it is coming.
Do not overcomplicate the writing of the RFP - keep it simple. The sales team will want to read through your requirements but they do not want reams of information at this stage (unless there is a very good reason to be very detailed).
Try not to set unrealistic timescales. Also, if there is a public holiday (or it is the summer vacation period) take this into consideration. If it looks like you will be hard to do business with, the vendors will likely spend their time elsewhere.
Do not issue hundreds or thousands of questions - not only will this be extremely difficult and offputting to the vendor, but your team will almost certainly not have the time or patience to read through them all. It might look detailed and you might think others will be impressed - but they probably will not be....
Do not issue to a 'long list' of vendors - keep the RFP to a 'shortlist'. An RFI process should have taken place before the RFP - this means that the RFP should only go to the very best options, not every possible contender.
Do not borrow another RFP and send it out - vendors can tell when little effort has been put into the document.
Sample RFP Template
An RFP template is a simple way of starting to build an RFP that you can use for your particular requirement. We have a free RFP template that you can download and get started with your own selection process or you can find them in other places across the internet. Take the advice and expertise that is included - but make it your own.
How to send out an RFP
When you are ready to issue, there are best practices for how to send out an RFP. Our advice is:
Issue in the morning when your partners and vendors are available.
Try to issue at the start of the week, not the end.
Try to issue outside of the main public holidays.
Ensure that you call ahead - and call the vendor after the RFP has been sent.
Ask for confirmation of their intention to bid.
Send the RFP via email and make sure it is written in a standard format (e.g. Word)
For any sensitive information, consider using an NDA before issuing the RFP.
How to run the best RFP process
Now that the RFP document is done, you might want to understand the best hints and tips to run the best process. You can learn more in our "Unlocking Success: An Inside Look at the Perfect Example RFP".
Conclusion
Writing an RFP for software requires following a similar process and fundamentals as any other technology requirement. In this article, we have discussed the essential elements and structure of a software RFP. It should be concise, focused on the problem at hand, and sent electronically in Word or PDF format. The key sections to include are the purpose of the RFP, company information, problem statement, timelines, response instructions, evaluation criteria, contact information, sales qualification criteria, and any additional information.
However, it is crucial to speak to vendors before sending the RFP. Issuing a "blind RFP" without prior communication can raise red flags for vendors, and they may decline to participate. Call vendors to explain your challenge, why you are issuing an RFP, and why you have chosen them. When sending the RFP, make sure vendors are given adequate warning and deliver it on time as expected. Provide contact information for any inquiries.
To avoid mistakes that could result in losing key vendors from the process, take note of the following:
Do not issue the RFP blindly; inform vendors in advance.
Keep the RFP writing simple and avoid excessive information unless necessary.
Set realistic timelines and consider holidays or other factors that may affect vendor response.
Avoid overwhelming vendors with hundreds or thousands of questions.
Send the RFP to a shortlist of top contenders, not every possible vendor.
Do not simply borrow another RFP; vendors can tell when little effort has been put into it.
By following these guidelines and avoiding common mistakes, you can increase the likelihood of receiving quality responses from vendors and ultimately find the best software solution for your needs.
---
If your team needs help, Viewpoint Analysis can write your RFP and run the entire process. Our Rapid RFP is the quickest way of finding a new technology partner. Check out our Rapid RFP as part of our Vendor Selection solutions.
If you would like to run your own RFP, why not take a look at our free RFP template - helping to guide the writing in a simple RFP structure.
Comments