From the very start, we assume that you know what RFP (Request for Proposal) is. So, we definitely won’t bore you with the basics, since you’ve done it over and over again. Still, we all know how important RFP is. Do it wrong, and you’ll end up with a lot of miscommunication and explaining to do.
In short, to help you write your RFP, we compiled a handy list of key steps. They are straightforward and should be enjoyable to think through. Plus, starting a new exciting project is in a lot of cases really fun! Finally, we want you to select a great vendor and have a terrific experience building a solution.
In case you’re not in a mood for reading the whole article, you can just use our Request for Proposal (RFP) Form that has all figured out for you.
Most probably, the vendor you’re evaluating knows as much about you like you about the vendor. So, be polite and introduce yourself and your project.
1. The Point of Contact (Name) – Knowing your name is a wonderful start of any conversation. However, for RFP, knowing whether you are a Point of Contact is a more vital thing to know. In a few words, a Point of Contact is a person responsible for all the communications with the vendor. If you’re not a Point of Contact, and still, you’re filling out the RFP Form, it’s better to let the vendor know.
2. Project description/requirements – You know your project best. So, give the vendor as much information as you’re ready to share. Don’t hold back! In the next chapter, you might answer a lot of detailed questions about your project that might duplicate with what you’re about to write. It’s not a bad thing. It’s a bad thing if vital information is not communicated at all.
3. How did you learn about the vendor? – It’s a nice tone of voice to provide some value to any conversation. Most new vendors are highly interested to know where did you find them. It’s not mandatory but if you remember how you found the particular vendor, share it. The vendor will appreciate it and you might end up with a more trusting communication further on.
1. Features of the software solution (name 5 or more) – the keyword here is more. The more details you provide to the vendor, the better the work estimates the vendor will give you back. As simple as that!
2. Links to similar software solutions – No doubt, you may have a truly unique solution, or it can have features that make the solution stand out. Still, trust us – there’s always a solution that has something similar to yours. It may be a design (or a part of it), content, programming language, some functionalities, etc, or even some combination of everything listed. So, if you know a solution that is even remotely similar to yours, provide it and write what’s similar. This is truly helpful!
3. Fixed budget/rate – It’s not about the money but about the resources you can provide the vendor for the current project. One can create a website for $500 and for $10,000. It depends on what you need. The cheaper website will be developed by junior specialists with cheap tools and minimum features. However, maybe, it’s what you need. By providing the vendor with, at least, a rough estimate of your budget, you will tell the vendor what’s the best way to do the project, and whether it’s financially justified at all.
4. Deadlines/Timeline – Sometimes you have a strict deadline, and you should provide it off the bet. It influences the price. Especially, if you want the project to be done yesterday. But even if you don’t have a strict deadline, some timelines are a must for using the Agile methodology and doing sprints. In other words, if you want the job done, provide the timeline for the job. Or else, you might not have it when you need it.
5. Preferred programming languages – This one is plain optional. Your potential vendor should be a tech expert, not you. Nevertheless, if you have some language or technology preferences, you should say so from the start or be silent forever! Or until the end of the project at least…
6. Is the design required? (if yes, specify) – This one is plain and simple. Do you need your solution to look good, and in what way? Links to solutions or print screens are very welcomed, at this point.
Besides describing the project in all its colors and shapes, you ought to look one step further and tell the vendor what’s it all for. It may sound unnecessary, but it gives the software development vendor a perspective of not only walking in your shoes but in the shoes of the end-user of your solution. This will result in better UX and probably UI.
1. Business goal – As written before, what’s it all about. What is the business concept? Are there any KPIs?
2. Target industry – Do you see an industry niche for your solution?
3. Target audience – Do you have a concept of your target audience? Maybe, personas? If you help your vendor by answering this question, the vendor will do a much better job with UI and UX.
1. Did you have experience with outsourcing companies? (if yes, specify) Every type of business has its specifics, including software development outsourcing. Having some experience (bad or good) with a particular type of business means that you have certain preconception (wrong or right). Having no experience means that you are a blank page in this regard. Anyways, at the end of the day, the role of the vendor is to understand what you’re expecting from its type of business. Moreover, it gives a vendor a clue on how to communicate the specifics of their business to you.
2. Is DevCom the only software development company working on the project? (if no, specify how we will cooperate) Oftentimes, when a company employs an outsourcing vendor it’s either to supplement a software development team that’s their own or belongs to a third party vendor. In both situations, it’s best for a vendor to have a clue how the collaboration between the teams will take place. Who will be responsible for what parts of the solution? How estimates and goals of one team will depend on another. What way of communication between the teams will be used? Who will be the Point of Contact between them? And much more details of the collaboration.
All in all, starting off a project on the right foot and with a right vendor is a key to success. No matter who you will choose as your custom software development partner, DevCom or another wonderful vendor, we hope this Request for Proposal (RFP) Form will help you. In case you still need any RFP-related or other assistance, feel free to address DevCom (follow the link). We will answer your requests in 1-2 business days.
Author: Oleh Romanyuk, Marketing Manager @ DevCom