Although we have met dozens of extroverted and extremely communicative programmers asking hundreds of questions (as well as the investors who needed digital consulting), in the world of software development, it is worth being guided by the assumption that people still need precise guidelines written in the form of an exhaustive document. This is the best way to thoroughly understand each other's needs, avoid misunderstandings and get your project to a happy end. One of the most important documents allowing to establish promising cooperation with a programmer, software house, or extended development team will be Request for Proposal or RFP for short. In this article, you will learn why you should use this kind of written specification and how to properly prepare it.
The RFP is a solution that we meet increasingly often in the world of digital transformation. Its benefits are undoubtedly successful in the IT industry. A well-prepared project request will save a lot of time - both if you are a customer who is looking for a development team, or if you are a mentioned development team and want to precisely assess your processing capacity and prepare a quote.
What is an RFP (Request for Proposal)?
The RFP is one of the best first steps you can take when looking for a vendor for a specific project. The investor sends such a document to software houses or extended development teams and collects offers, getting to know the details of cooperation with individual teams. Thanks to an RFP, the client can compare the prices of various services, benefits packages and learn about different ways to adapt specific ideas. For the software development team, on the other hand, a document with a detailed specification is the best way to prepare a more accurate valuation and an ideal introduction to the project. In times of the COVID-19 pandemic, when we cannot meet in person, a well-prepared RFP will be even more helpful.
A good alternative for RFP: Request for Information (RFI) and Request for Quotation (RFQ)
Before we discuss the RFP in more detail, you need to know that there are other types of requests depending on your needs and the information you are looking for. If you are just starting to do research for your project and you do not know the specific needs yourself yet, it is a good idea to send much simpler Requests for Information to potential vendors. An RFI works well when you are just building a pool of vendors from which you will later choose. This is an exploratory document that will help you identify companies that you can consider as potential collaborators. In an RFI you include general information about the project and your business goals. The open-ended questions will help you understand what processes are used by a potential vendor and what work culture functions in a given company.
If you know exactly what changes, solutions, or implementations you need, and what you are most interested in is the price of the service, the document that the vendor should receive from you will be a Request for Quotation. It’s a list of requirements prepared for price evaluation. It's a good solution for simple projects. Remember, however, that a comparison based solely on service prices can be risky. If you value suggestions, advice, and feedback while working on a project, selecting a service provider based on an RFQ may not be the solution for you.
Request for Proposal - I choose you!
Now that you know about the other options and the situations in which you should use them, let's go back to the main character of this article, which is the RFP. This kind of request can be very useful when you have cleared up your project goals and deliverables, but you are still open to ideas on how to actually reach them. The RFP is also very good for complex and large-scale projects where many criteria need to be assessed before hiring a vendor.
The RFP has no rigid framework or one and the only right structure. However, based on our experience, we can define a few specific elements that this document should contain:
A project’s overview - Start with the most important information and outline the project. Focus on the specifics straight away. At this stage, the vendor should already know whether he wants to engage in cooperation.
A company’s background - Write what your company does, what products and services it provides, and what’s the story behind it. A sentence about how your company stands out among your competitors might also be a good idea. Companies often forget quite an important detail - it is also worth mentioning where the office is located!
Project goals - define what you want to achieve with your project, what problems you want to solve, and to whom the service should be addressed.
Scope of work - Define the stages into which the project is divided. Describe exactly what help you need. Indicate the services of which specialists you would like to use (project management, UX / UI, testing, etc.). When describing the structure of the project at this stage, you don't have to be super technical. It's about outlining your needs and priorities.
Technical requirements - At this stage, the project manager responsible for submitting the Request for Proposal may need some support from the IT department. It is worth writing about the existing technological solutions, integration with other applications and platforms, devices that are to support the project, and technical requirements.
Deadline - Even if the project does not have to start on a specific day or month, be sure to set a time frame. It is worth defining milestones, thanks to which vendors will know when to reserve specific human resources.
Budget - If you know what your upper limit of expenses is, it is sometimes worth honestly informing the company to which you are sending the request. In many cases, this will save you time if there are completely different expectations on both sides.
Selection criteria - It would be a fair practice to inform the vendor about the key criteria that are used by the company looking for specific services. Such criteria may be location, experience with similar projects, or certificates.
Questions - If you are not sure about some solutions yet, don't be afraid to ask questions of potential vendors! Already at this stage, you can help your project develop.
Submission requirements - Specify what documents you expect (case studies, testimonials, references) and in what format they should be delivered (PDF, paper documents, etc.). Do not forget to also state the deadline for offers from potential vendors.
Contact info - In addition to the e-mail address and telephone number, the document should contain a few words about the person representing the company who will contact the vendor.
Request for Proposal: what do you need to avoid?
We hope that the flood of information has not yet discouraged you from preparing an RFP yourself. You can be sure that good preparation of this document will not only help you find a good vendor but also improve your project. After all, every time you try to frame it and structure your ideas, there will be room for improvement! You already know what you need to keep in mind when working on your RFP. However, there are things you should avoid.
Don’t send too many requests - If you are overwhelmed by the pre-selection of companies, start by sending out the RFI. Shortlist potential vendors and only then prepare an RFP for them. It should not be more than 5 companies!
Do your homework - Respecting your time and potential vendors, make sure your RFP is done properly. Provide context, useful attachments, and as many details as you can!
Money is not everything - Remember that an RFP is not intended to bring you the cheapest offer. Slightly more expensive software engineering with a team ready to advise and improve your product is a much better investment.
Define project priorities (but not too many) - Identify the key elements and goals of your software project but leave room for creativity for the potential vendor. Remember that you have to make some compromises within your specified budget.
Leave some space - Asking if the answer is ready the day after submitting the RFP is not a good idea. It takes time to gather materials and prepare an offer. You can only get worried after 3 weeks of silence. Only then is it worth asking if you can still count on an answer. And finally - at the stage of looking for the right vendor, it is worth refraining from suggesting ready solutions. We are convinced that software developers cannot surprise you with their creativity and propose something that you could lose if you showed them the way in advance.
