Software RFP: How to Write a Request for Proposal

We should start with the basics. RFP is an acronym for ‘request for proposal’. A software RFP is a questionnaire-type document that companies send out to potential software vendors. The document list out all the key information about your company and your software requirements and ask vendors to respond with a proposal.

Selecting software developers through an RFP has several benefits:

• You clearly lay out all the necessary information in a single document, instead of doing it in an ad hoc manner through many calls and meetings where important information could be left out or forgotten;
• A software proposal makes it easier for vendors to propose viable and applicable software solutions for your project;
• You have a uniform document that you send out to all potential software vendors, allowing you to judge them by the same standard and apply the same selection criteria;
• It makes it easy for you to compare proposals, letting you make data-driven decisions;
• Experienced software service providers will often expect an RFP before they offer their services.

Do You Really Need to Write a Software RFP?

A software RFP is a valuable document, but it takes time and effort to write. Thus, it’s no surprise many organizations try to avoid it. While we would recommend you always send out RFPs to vendors, there are a few instances where it may not be strictly necessary.

One such situation is if you are looking for cloud-based solutions and vendors are offering free trials. Testing out their free solutions to see if that is what you are looking for can negate the need for a selection process through an RFP. On the other hand, testing out those solutions also takes time, so it’s questionable how much of a time saver skipping the RFP would be.

The second option where skipping the RFP could be viable is if you are outsourcing a very small project. If the software you need only has a few requirements, it’s possible to reach out to companies directly without sending out formal RFPs.

Again, the only reason not to write a software RFP is to save the energy it takes to write it. We believe this energy is well spent, even in the mentioned situations.

Now that we’ve explained what it is and why it’s important to have one, let’s get started with the steps you should take to write an accurate software RFP.

1. Explain Your Position

The first step is writing a high-level overview of your company, your capabilities, and the kind of software you need. Because this is a high-level, introductory overview, it shouldn’t be overly long – about a page to a page and a half.

So, explain what your company does and the goods or services it provides. Describe how your company is structured and the department that needs the software. Naturally, state what kind of software you need and what your ultimate project goals are.

Explain why you need the software – are you replacing existing software that no longer does the job you need? Or are you looking for long term-solutions for anticipated future problems? Maybe you want to optimize your existing operations and believe custom software could be the solution?

By understanding your reasons for buying software and your business goals, software development vendors can provide more accurate solutions. Maybe they will even come up with potential solutions you did not think of. Some of the things you could include in the introduction (in a summarized way) are:

• A description of your company
• The project description
• The software you already use
• The hardware you have available
• An ideal timeline for the project

2. Select Your Deployment Method

There are two ways you can host your software – on-premise or on the Cloud. On-premise means that the software will be hosted on your own servers, internally. On-premise hosting is becoming increasingly less popular as Cloud-based tech advances. It comes with certain scalability and functionality issues, and you often need to fulfill the associated infrastructure requirements.

In fact, more and more companies are paying to migrate their on-premise hosting to the Cloud. Cloud hosting means that your information will be stored on the Cloud, on your service provider’s hosting.

Regardless of the deployment method you choose, your software RFP should contain a section that details your existing IT infrastructure. That will enable companies to give practical recommendations on which deployment method would be best suited for you.

3. The Core: Your List of Requirements

The core of your request for proposal for software development is your list of technical requirements. However, accurately listing your product requirements will be a challenge that will take up most of your time when writing the RFP. The project requirements should contain all the features and functionalities that you need from the software.

Naturally, if you are in need of software with limited functionalities, the list will be much shorter. For example, an automated messaging service will have fewer functionalities than a payment processing platform or an internal workload and project management software.

At the end of the day, you don’t need to think of every minute detail. Your potential vendors can also give suggestions and recommendations regarding the necessary functionalities. But if you have a uniform document that requires minimal alterations and additions, then it will be much easier to filter the best responses to the proposals you receive.

3.1. Make Your List Easily Navigable

If your software RFP contains a lot of technical requirements, then you should try to make it easily navigable. You can make a spreadsheet where each requirement is a separate line. When vendors read your list, they can mark whether their software has the functionalities you need or not and can leave comments for each individual line.

This approach makes it much easier to sort through the best proposals.

4. Include Deadlines and Milestone

A software development project is not something that should be rushed. Further, not all companies are of the same size and have the same capabilities. A company may be able to create the software you need, but not by the date you need it. For these reasons, your RFP should contain a timeline of how you wish the process to go.

This timeline should also include a deadline for submitting responses to your RFP, as well as a date by which you will notify the candidates. Thus, your software RFP should include something along the lines of:

• A timeline for responses (giving vendors 30-60 days to respond is generally reasonable)
• A date by which the vendors will be notified of the selection
• The length of time which would be required to develop the software (you can further break this down into expected milestones)

Here are a few more tips that can help you write an accurate RFP:

• Distinguish between the necessary, functional requirements and wish-list functionalities – if your list of requirements contains a lot of information, you should try to classify it into the essentials vs. the non-essentials. A potential vendor may be able to meet all your essential requirements and build the exact software you need. At the same time, they may not be able to create the additional functionalities you would ideally like to have. Thus, you could separate the two. And no, just because an item is classified as a wish-list item will not make a vendor ignore it.
• Don’t send proposals to too many companies – filtering through responses to your RFPs will take a lot of time. The more RFPs you send out, the more work it takes to find the best software company. In practice, this amount of information can be overwhelming, causing you to miss out on good candidates. The solution is to research companies that would be a good fit before you start sending out RFPs. Shortlisting about 10 software development companies and contacting only them can help you find the best vendor.
• Lay out your evaluation/selection criteria – if you have clearly established evaluation criteria, it is advisable to include it as an appendix to your software RFP. This will allow vendors to focus on the most important aspects as well as encourage transparency.
• Who will create the RFP? – by now, it should be clear that a software RFP is not something that a junior associate or someone in a similar position can write in a day. You should carefully consider who should be assigned the task of writing the RFP. The RFP creator must have a deep, detailed understanding of the project. Ideally, they would also have the necessary tech expertise. If not, they should get the help of a dedicated team of subject matter experts to help them out. As an example, a product owner (assisted by senior tech experts) is often a good choice for the creator of the RFP.
• Designate points of contact – it is perfectly normal for vendors to contact you once you submit your software RFPs. Consequently, it is recommended to provide a single point of contact for any questions or requests for additional information they may have. This approach can speed up the process and avoid any unnecessary delays due to bad communication.
• Try to avoid internal terminology – each company has certain terminology that’s become the norm in its day-to-day practice. However, these terms may be unclear to anyone outside of the company. Thus, try to exclude internal jargon for your RFP or include a glossary of items that clearly define the potentially confusing terminology you use. In other words, clear, simple terms work.

As we’ve stated, it’s not advisable to send software RFPs to too many potential vendors – it will be difficult to filter out the responses and make the best business decision. Do some research and only send proposals to suitable vendors. That’s where we can help.

At Global Software Companies, we research, create, and curate lists of the best software development companies from different countries and from different fields of IT. So take a look at our lists and freely use them as the shortlist of the companies you will be contacting.