How to write RFP to find the best software development partner?

“Be careful what you wish for ‘cause you might get it” is an old saying to teach youngsters to think twice before they act. In the software development world, it would probably sound like “be careful what you ask for ‘cause you might get the answer.”

Since the birth of Merixstudio, we’ve gone through thousands of conversations about potential projects. In some cases, it was enough to present our portfolio showcasing our approach to building similar applications to the one envisaged by the client. In others, we went through a long and complex selection process that involved technical interviews. In recent years, however, more and more cases rely on requests for proposals – or in short, RFPs.

What is RFP, when, and why should you use it?

An RFP is a document that describes your project in enough detail to have potential vendors send you their proposals regarding technology choices, development process, deployment process, hosting, and more. Enough to say that an RFP makes sense for complex projects that demand a fair dose of technical information and recommendations. Software development projects surely belong to the family.

With an RFP in place, clients are able to address specific challenges and collect possible solutions from several potential vendors by comparing their offerings, key competencies, pricing models, or development processes. A neat RFP document gives you an opportunity to:

• Compare vendors and their alignment with your project and its specific requirements.
• Evaluate different points of view on your project.
• Save time on presenting the project introduction on multiple meetings with potential vendors. With an RFP, you’re able to send the project information and answer some of the common questions straight off.

Does it mean that a request for proposal can replace traditional sales calls? Not really. A call is still an efficient way to determine whether the service provider is knowledgeable and easy to talk to. In this sense, it’s a perfect introduction to a longer sales conversation with a formal RFP as one of the next steps. What’s more, in the case of long RFPs the number of sales and technical calls can reach from a few to over a dozen.

What is the difference between RFI, RFQ, and RFP?

Depending on what kind of information you’re looking for, you might come across several different definitions of requests. Let’s take a closer look at what is what.

Request For Information (RFI)

Sending a request for information, also known as RFI, is an official way to ask for a company presentation. The goal of an RFI is to give you an overview of potential vendor’s capabilities so that you can decide whether you want to continue discussing your project with them.

A request for information can help you preselect those 3-5 vendors for whom you’ll write an RFP later on.

What do you need to prepare for an RFI?  

• General information about your project along with your business goals.
• Open-ended questions that relate to your project and help you understand the vendor’s processes and culture.

Request For Quotation (RFQ)

A request for quotation, often referred to as RFQ, is what companies prepare when they want to compare multiple potential vendors by price. It looks straightforward, although there’s quite a risk in relying only on a price comparison.

An RFQ is a sign that you’re not looking for suggestions or solutions, but for the team to write the code within the lowest possible budget. If that’s the case, great. But if you’d like the vendor to be proactive in finding the best possible solutions for your project, you need to write an RFP.

What do you need to prepare for an RFQ?

• A detailed list of project requirements.
• User journey and UX flows.
• Application designs.

Request For Proposal (RFP)

A request for proposal is the most common type of document software houses process in their sales cycle. An RFP often takes the form of a document that describes project challenges and, in return, requests a solution or a list of possible solutions with recommendations.

What do you need to prepare for an RFP?  

• A list of project priorities and deliverables.
• Project scope.
• Specific questions or challenges you want the vendor to address (e.g. how they would handle scalability, quality assurance, or technology choice in your specific case).
• User journey and UX flows.
• Designs (if you already have them).
• Criteria for selection.

RFP process step by step  

Crafting an RFP to select a software development partner can be not only time-consuming but also difficult and stressful. After all, you’re going to dive into a process of choosing a vendor and you want to make sure the choice would be spot-on. In order to capture the potential of different bidders and secure your stakeholders’ best interests, you’ll need to plan for the RFP. It will require more coordination than you might imagine.

Planning

First things first. There’s some planning-related homework to do before you jump into writing the content for the RFP.

Assign a project manager on your end and make sure this person would be responsible for keeping the process moving, especially when potential vendors start coming back with questions.

Think of your business and project constraints such as your deadlines, the industry you operate in, the team you might already have in place, and the challenge you want the partner to help you solve. Your constraints will shape the context of the project and determine who you need to involve in your organization.

What are some common project constraints to examine?

• Desired launch date – as it is tightly connected with business goals and often determines technology choices.
• Existing software, hardware, and licenses – if you’re not dealing with a greenfield project, there’s always some infrastructure, licensing, and architecture in place.
• Budget – don’t risk falling for a proposal you can’t afford. Set your financial expectations upfront and make sure they’re approved by your CFO.

Drafting

Now that you’ve gone past the planning phase, it’s time to outline the RFP document. In order to give your bidder the most accurate picture of your project, you should remember about a few important sections.

1. Project overview. By compressing the most important pieces of information at the beginning of your RFP, you allow the bidder to understand your product on a core strategic level. Then the following chapters add details regarding particular product areas. That’s a similar approach than in the case of product design workshops some software development companies start their products with.
2. Business perspective and goals. What problem are you solving with your product? Why are you making this particular project now? What do you expect to achieve?
3. Project scope with priorities. Collect as many details about the scope as possible. They don’t have to be technical. Try to describe what you’re planning to build, what will be the benefit of it, and how important it is. You can put it together in Excel or Google sheets to make it easier for you to compare later.
4. Milestones and deadlines. Even if there’s no clear deadline for the launch, you still should set it for the purpose of the RFP. It will help vendors assess whether they have the resources to complete the task.
5. Technical requirements. If there are any requirements regarding the operating system, preferred technologies, or licensing, make sure you get them from your IT department and put them in the RFP.
6. Questions. Give yourself space to ask a few open-ended questions, e.g. about support options, possible trial period, implementation process, or use cases and references from past clients.
7. Criteria for selection, submission deadline, and selection timeline. Make sure the bidders are aware of the selection process on your end.
8. Contact information. A simple and straightforward way to get in touch with you with regards to the RFP.

Issuing

Once your RFP is ready, you can distribute it in your network, publish on relevant sites, and start managing the responses and additional questions.

In order not to let your RFP process get out of hand, you’ll also want to shortlist potential development partners while the submission process still goes on. If you decide to have vendors find and respond to your RFP, now, in the global economy, you can expect tens of possible submissions. Get ready to coordinate responses, connect with vendors, and engage them to present proposals and unique strengths.

⚙️ Keen on IT outsourcing? Learn how to find a reliable software development partner!

Shortlisting releases the capacity of your team to engage with a limited number of preselected vendors. Usually, the companies we answer RFPs to choose no more than 5 vendors to continue post-RFP in-depth evaluation. What can help? A list of deal-breakers that outlines what you can’t work with and some baseline requirements to qualify for the shortlist. By listing what will not work for you in a specific project you cut short the unproductive time your team would spend on calls with vendors who would commit to an RFP response that has no hope of winning them the opportunity.

Depending on your organization’s goals and objectives, deal-breakers can be different - from the use of subcontractors to the lack of support or maintenance standards. Your objective at this stage of the RFP process is to stay open, flexible, and leverage your negotiation power.  

Reviewing process

To review potential partners and make the final choice, you’ll need to go through the RFPs as well as the rounds of questions of shortlisted partners. Preparing evaluation scores in advance might help you find a pattern in comparing several potentially similar proposals.

One of the ways to do so is to assign importance weight (e.g. in the range from 1 to 10) to each point and question in the RFP document. Then, depending on how much the vendor’s answer is aligned with our policies and expectations, we’d score the answers one by one and add the points to select the potential winner.

What makes a good RFP?

The most important characteristic of a request for proposal is clarity. A good RFP clearly points out what kind of a partner you’re looking for and what you want to accomplish together.

What to avoid when you write an RFP?

• Don’t mark everything top priority. It’s tempting to consider each feature equally important. In practice, however, in order to select a software development partner, you’ll need to prioritize. Give the bidder the opportunity to craft a fitting solution by showing them one or two critical features that bring the biggest value to the project. In return, bidders will be able to present their unique approaches to delivering business value fast and on budget.
• Don’t suggest solutions. The goal of the RFP is to let vendors suggest solutions to your problems. If you play the role of a problem-solver, you shut down the range of possible solutions to the one you find appropriate. If you did your homework and sent the RFP to a limited number of vendors, they probably solved similar problems many times before. Let the vendors surprise you.
• Don’t rush the response. An RFP takes time to answer. Beware that the vendor will have to analyze your document, brainstorm ideas, propose a solution, and calculate the budget. That’s not what you can do overnight. From our experience, 2-3 weeks seem reasonable if you’re looking for an individual approach. What’s more, by allowing vendors to respond in their time, you can check how efficiently they communicate.  

Curious how we design tailored solutions for RFPs? Give us a shout!

‍