How to Write a Request for Proposal to Find Your Best Software Development Partner
There’s a misconception regarding software development, and the key point in it is that the development is mostly about code writing. But it is far from the point. In reality, the main goal of any provider should be to offer an effective solution to the issue, stated by the client. It is possible to create a competitive product only if the previous steps were conducted, and a profound market study is a thing here that matters because it allows us to check and investigate the solutions that already exist.
The results of this research, the resources, and limitations from the client’s side, the issue the product should solve being developed are the points the software development provider considers while offering the technology stack.
There’s a way, though, to simplify negotiations from the client’s side. For that, he needs to study the issue, the particularities of the selected field, and also provide a list of recommendations. In any case, communication with the provider is the thing one should be ready to do. If you are about to start an interaction in writing and request a consultation, look through the guide. A well-organized and clear request for proposal, or RFP, isn't just a way to provide the potential partner with essential information but to prevent misunderstanding in the future. In the guide we will make decomposition of RFP, providing you with the successful templates which can be used later on.
Tell about yourself and your market
Business describing is not just a formal part, it helps the development partner to figure out which techniques to implement and narrow the scope of the possible technology stack. However, when the business is described it is much easier to define the initial business problem, as well as related ones. It’s always better to start with static information. For example, tell about the number of workers, location, and the target audience.
What problem do you want to solve?
An effective and clear RFT impossible without telling the potential partner about the market demand and the issue the product is about to solve. If the demand is satisfied, the users are attracted and the revenue grows. If there are issues to be resolved in the product which already exists, describe them as well. For example, if there are issues with extended documentation, mention it. The same works for any kind of issues, including workflow control or any functional issues.
How do you see the solution to your problem?
As a business owner or a stakeholder, you have an idea of how the issues can be solved. Do not hesitate to share them with a potential partner. For example, if you feel that the documentation flow can be maintained with the app automation, tell the team about it. And if creating an app for workflow optimization seems a good idea to you, share it too.
What features do you think your solution requires?
There’s one secret we are about to share about the features in the RFP. Ready? Here it is - the features are the matters of secondary importance. And the common mistake is to describe the features the customer considers to be needed in the RFP. Why is it a mistake? The answer is simple. During the process of research and analysis, the provider can and, in most cases, discovers that the features which seem to be reasonable turn out to be extended and not needed at all. On the contrary, the features to be initial might be missed. Instead of describing the features you consider to be essential in detail, state them as clear and sharp as you can, so the provider can understand how you see the logic of the product.
Are there any constraints the provider should know about?
Are there any constraints worth considering? Do not hesitate to provide them, regardless of the kind - technical, time, legal ones, or related to the project budget. It will be helpful for the provider, so he can offer the best solutions during the first call, so the work will begin sooner.
Share specific requirements (if you have any)
Another point the clients miss mentioning during the first contact is, surprisingly, the requirements and needs. In most cases the reason is simple - people think that it's not high time to mention such matters, or they seem to be too obvious to spend time on. But requirements are things that have to be provided at once, especially if there are some special matters or conditions. Thus, the risk of misunderstandings will be decreased and the provider can offer the most efficient solutions along with the appropriate technology stack. For example, if the staff needs training with new software, it has to be pointed out at once.
So, the final request for proposal would be the next
We're a London-based medical center with 200 employees. We would like to solve some operational issues:
- a lot of internal and external documentation
- difficulty handling patients' past records
- we need more control of the overall workflow.
We suppose to use the web and mobile apps to automate the documentation flow to reduce the paper forms and to track all the phases of the workflow. We also would like to keep all patient data in one place for staff to access it easily.
The most important functionality is:
- access to patients' EHR/EMR
- scheduling, changing and canceling appointments
- processing prescription refills
- doctor profiles and reporting documents.
The budget is allocated for this year only, so we need to spend it till the end of the year.
Our staff is not accustomed to using an electronic document management system. They might require additional training to learn how to use the system.
We are looking for a team to deliver an excellent app design as well as robust frontend and backend code. Also, we would like to get continued support after the project is finished.
The number of active users, average session length, number of sessions per day are the crucial points to focus on. There also may be the number of clicks on the "order" button and the number of completed orders.
If we could get 50 monthly orders in the first month the app launched, I say it's a success.
As you have noticed, this RFP is little about the technical aspects. At the same time, it contains all the necessary information that the provider needs to start working - the issue is explained, so the solutions can be suggested already.
Things to add
Apart from actual issue solving there’s another challenging part, and it is about the metrics, the scope, and success indicators. It is impossible to pick these points without a deep and profound understanding of the software development process. Sometimes it is even difficult to estimate the project scope, not talking about other metrics to be considered. So it is fine if the service provider changes it later on after performing a preliminary analysis.
There are things you still can share with the provider to make the work more efficient:
An explanation of the intended scope
Here it’s fine to explain to the team what you expect to be done, so the partner will have a clearer vision of the project and will be able to make at least a draft of the project development roadmap.
Metrics you’ll measure
Sharing the metrics, important for you, has yet another profit - while designing an application, the service provider will design an app, having these metrics in mind. If you want to focus on some specific figures, mention them. For example, if you need a booking app, the possible merits can include the number of orders and bookings, reviews, and other specific characteristics you consider to be important.
If you share what metrics matter most to you, your service provider can design an application.
The end goal of the collaboration
The first and foremost thing the provider should think about is the rate of customer satisfaction and meeting the customer’s final goal. Share it with your potential partner for further work.
You’ve sent an RFP. What is the next?
Different companies have different rules and practices. In case with Celadon when you send an RFP to the company, the first thing to be done is the requirement collection, performed by our business analyst. After the scope is analyzed by the solution architect, so an engagement manager can focus on checking if your needs as a client are met. After that there will be several calls from our side to make the requirements as clear as possible, so you can be provided with two types of estimates - rough and detailed ones. In case everything is OK and you decide to start working with us, both sides sign a service agreement. Our customer success manager will eagerly answer all your questions related to the topic, starting from the signing of the agreement till the end of the project.
Sounds interesting? Or, perhaps, you want to know more about the way the preparatory and development processes are handled in the organization? If so, feel free to have a look at our articles, related to the roles of a business analyst and a project manager.
An important point to be mentioned and underlined: the service provider focuses on the problem your product should solve, not on its features. The way features to be implemented and built depends on the way the initial issue will be solved.
Keep in mind one basic thing: no matter how basic or comprehensive the request is, a good service provider will collect all the information needed, so an effective solution will be provided. Request letters, having been written in an effective manner, help save time at this stage.