Before collaboration with a software vendor, lots of questions may arise. What kind of vendors are suitable for my tasks? Who will bring more benefits and what solutions will work best for my project? To effectively address these and even more issues, companies use Software development RFP or Request for Proposal.
Why care about this document? A request for proposal is an opportunity to advocate for your needs. Properly written RFP helps quickly uncover the strengths and weaknesses of a potential vendor in relation to your project. Moreover, you can both check the expectations of each other and evaluate mutual satisfaction.
How to write an RFP for software development? The problem is, even after research, the concept of RFP may still be blurry. For this reason, I decided to share explanations, best practices, and knowledge based on my experience working on various IT projects. The purpose of this guide is to help you to conduct a good RFP, so that you receive more adequate vendor estimates and ensure your vendor selection is objective.
What is RFP?
What does RFP stand for in software development? RFP is an acronym that stands for Request of a Proposal. It is a common practice for IT companies that is used prior to concluding a deal with a contractor (vendor). RFP announces a project, describes it, and solicits bids and ideas from vendors. The outcome is, you get proposals from vendors with possible solutions on how it is possible to do what you want.
The whole point of RFP in software development is a specific need. It is not about the acknowledgment that vendors are qualified to do your task. It is about seeing what solutions vendors can propose and whether they can cover all the expectations.
One side (IT company) writes an RFP to receive feedback (proposal) from vendors. The vendor obtains a clear picture of what is needed to be done, so presents more precise proposals. As a result, both sides can enter a contracting phase without the slightest hint of doubt. And even if something will go wrong, you can always go back to RFP, and rely on this data.
How do Software Development Companies Use RFP?
Software development companies use RFP when a project is sufficiently complex, requires a great deal of technical information, and demands hard data for analysis and comparison. It is used more rarely (and not advised to) when projects are too obvious to perform and all issues can be clarified in frames of traditional meetings.
How does RFP differ from other contracts? Generally, RFP is a part of RFx - request for documents or ‘x’:
- request for information (RFI)
- request for proposal (RFP)
- and request for quotation (RFQ).
When a company (startup) needs to develop something, but it has no resources or knowledge to do it, the advisable strategy is RFx: to find out how to do the project, determine who can make it, choose a vendor, and conclude a contract. Each of the steps is performed through the use of the corresponding document:
Step 1. RFI: How is it possible to develop functionality (generally)?
In RFI, you state your needs and problems, and give this doc to potential vendors to receive such information as ideas, technical assessments, and potential solutions. The purpose is to increase the knowledge about the problem and thereafter decide what to do more specifically.
Step 2. RFP: Who can make the project? What are possible solutions (in detail)?
That’s the right time when RFP comes to play. After a few suppliers (or it can also be a one) reply with some general information, you can gather more details about your project and state your dreams/objectives more specifically. Here, the purpose is to filter out the most convenient vendors.
Step 3. RFQ: How can we price the collaboration?
After you decide who exactly can perform your tasks, you should clarify the price with RFQ. This document states all specifications and requirements and asks a vendor to define a certain price. After agreeing on certain costs, you can both conduct a contract and start collaboration.
Who usually writes an RFP for software projects?
RFP in software development is usually written by primary stakeholders or project managers. It can be created by one person or led by a team (it depends on the nature of your business, project, and budget). Nevertheless, the curator of RFP writing should be familiar with Agile or Scrum methodology, know the project well, and be good at decision-making.
What is included in the software development RFP?
To make RFP work, it is important to present relevant and well-structured data. After all, what is included in software development RFP defines what kind of proposals you will receive. To succeed with delivering a proper document, I suggest using this structure.
Statement of purpose.
Start RFP with a short and clear explanation of why you actually refer to a vendor. State an overall idea of what should be done in a few sentences.
Background information.
Tell more about what your company does, what your core values are, what you stand for, who are your customers. It is like the starting point of what you have right now, and what was done earlier. This will help vendors to understand not only your project but your vision.
Project overview.
This is a brief overview of your project. It should provide general information on what needs to be done so that vendors can quickly determine if it’s something they would like to respond to, or not.
Scope of the work.
What piece of software should be done? Lay exactly what you want from the business and technical perspectives. Present a detailed list of expected outcomes, and highlight several types of requirements:
- Business requirements. Describe functionality from the customer’s perspective and business logic. These are customer needs, expectations, and descriptions of what actions will be performed by functionality.
- Functional requirements. Here, you also describe desired functionality, but in the form of suggested use cases. More specifically, how specific functions can be achieved to fulfill the business needs.
- Technical requirements. If you think it is important to use specific programming languages or frameworks, use this block and specify such or any other technical requirements.
Keep in mind, business requirements are the why, functional requirements are the what, and technical requirements are the how.
Outcomes and performance standards.
What outcomes, and performance, do you expect? The next logical move is to state basic minimums of what should be accomplished, and how you would like to monitor suppliers (access their performance). I advise making a checklist, so in the end, you can both check the performance.
The Deliverables & Deadlines.
Specify deadlines for all processes. When you put all these things down, vendors will know when they should plan their next project, or find new customers.
Payment.
How will you pay a vendor? State all figures and don’t overlook cases when something may go wrong. For example, if a vendor will not deliver the project by the agreed day, maybe you will offer some percentage. The whole point is to make sure everyone knows what the rule is.
Requirements for Proposal.
Once you state everything from your side, describe what you want to receive. What kind of proposal will suit you? Give clear instructions (volume, type of doc) on how you want a proposal to be constructed. It is important to obtain the same kind of facts, so make a better and faster comparison.
This structure contains all logical segments and a detailed explanation. As practice shows, all of these components will eventually help you in case 'Hey, you didn't tell me I need to do this because there wasn't included in an RFP’. Make sure you don't miss anything important.
How to write an RFP?
Creating an RFP is a multistep process. To minimize ‘negative’ scenarios, I suggest adhering to this algorithm:
Select one leader of the RFP process.
Define who will join and curate the RFP writing process. Identify stakeholders and decision-makers, form a committee. One person should be responsible for the whole process to make sure everyone is on the same page.
Form an initial vision. Core Problem.
What is the core problem we’re trying to solve? Communicate within your team. Gather overall needs and propositions, what actually is important to do. From ‘the field of your dreams’. The opinions of your team members may often help to find a common consensus faster.
Use Q&As sessions.
Once you decide what is the idea for your project, gather more information on how it is actually possible to make this happen. A lot of companies use Q&A sessions at the beginning, both within a team and with a vendor. If your team lacks knowledge, start with RFI.
Define the readers of RFP.
Research the market of vendors, review and analyze profiles of different companies. Define who can potentially meet your needs and ‘make a portrait’ of your desired partner. When you narrow down your focus, the possibility of success is much higher. Otherwise, you risk getting mixed outcomes and information from ‘too many people’.
Set deadlines for RFP.
Set a timeline for each step of writing an RFP, so everyone will be aware of what's to expect. Make sure to give enough time to the RFP to get quality results. As a rule, the process may take up to 2-3 months, and include stages like project planning, drafting, sharing, reviewing, final decision.
Set price limitations.
Gather budget information. Otherwise, you will not have a clue what kind of criteria you need to give them, so they give you the price properly. Learn how specialists price similar projects, and then proceed to state all your requirements in accordance with that information.
RFP best practices
A lot of information is already said about RFP, but empowering yourself with best practices is not superfluous. Especially if you want to write an effective document. Here are some of the practices I find useful.
Prioritize requirements.
RFP may contain a huge number of requirements, and some of them may be more or less important for you. Access your product functionality and leave remarks for each requirement. This will help vendors to focus on top priorities, so give you more objective feedback.
Here’s possible gradation with remarks you can use:
- required - feature is required to participate in RFP process;
- nice to have - feature is important to have to succeed;
- like to have - feature is valued, but not required.
Take care of readability.
Make RFP look appealing and approachable at first glance. Avoid complicated explanations, bull text, lots of description. Instead, use simple paragraph headings and short sentences. I suggest choosing highly readable fonts and keeping the same formatting for all elements like titles, headings, bulleted lists, etc.
Select tools suitable for teamwork.
Don't draft RFP in hard-to-read and edit formats like Word, or PDF. Use tools that allow doing joint work in real-time. For instance, Google Docs, or Microsoft Teams are perfectly suitable for direct discussion, reviewing recent changes, autosave files, and adding comments.
Take a look at different RFPs.
Analyze how other companies conclude RFPs, especially for similar projects. Pay attention to this RFP for software development pdf, I find it very informative. Also, get utmost from templates. Here is a good sample RFP document for software development you can use as a reference. Remember, there’s no standard template and no single RFP template can be replicated. Take into account your specific case.
Summary
The picture of writing an RFP document may be blurry at first glance. Nevertheless, dealing with it is a ‘must do’ task if you want to build an effective collaboration. After all, writing a good RFP is key to receiving adequate vendor estimates. I hope this guide will help you to get a clear understanding of what RFP is in software development, make the right choice and minimize possible failures. Good luck!
Want to run your project, but have not much knowledge or time to form a team? Altigee helps IT companies, especially startups and non-technical founders, to find and hire the most appropriate specialists. We hire, manage, and retain engineers, so that help to spend less on engineering and reduce burn rate.
You can always contact us to find out more information.
.jpg)
.jpeg)
.svg)
