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 how to create a product 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 the case of Celadonsoft 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 bespoke web app 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.
