A request for proposal (RFP) is a critical step toward getting funding for a project. Typically, those in charge of fundraising have to gather a certain number of responses from potential vendors to bring back to investors, effectively proving the cost of the project. The problem is, if RFPs aren’t smartly written and researched, they could create gaps in features or pricing disparities that lead to underfunding and project failure. Here are some tips to ensure that your RFPs bring back thoughtful, all-inclusive, well-researched proposals that will get your project off on the right foot.
First and foremost, you must put in the work upfront to make sure that your RFP is as inclusive and detailed as possible. We encourage a line-by-line feature list so that when you’re comparing proposals you can do so in as much of an apples-to-apples way as possible. This way, you can quickly identify features with large pricing disparities amongst vendors and get straightforward answers as to why a certain vendor priced a feature the way they did. Given that the concept is a work in progress, it is inevitable that there will be a certain amount of assumption made by a vendor in order to complete the estimate, but a thoroughly documented feature list will help limit this variance. Furthermore, these variances can actually come in handy, provoking dialogue between you and the vendors that will help you gain an understanding of their experience and capabilities. For example, if one vendor includes a dollar amount towards routine updates and maintenance to keep a certain integration working where another fails to, this may help you weed out candidates that lack the experience or the expertise to see your project through.
Another way that the RFP process can get sticky is when you’re tempted to simply take the lowest cost option. It is easy to become laser-focused on dollars when that seems like the sole piece of information standing between you and the technology you want to build, but it is critical that you are seriously considering whether or not a potential vendor is actually a good fit for your project and/or your business. Custom software development is most often a complex and lengthy process, so the quality of experience you will have is heavily dependent on compatibility between you and your vendor. Some things to consider when choosing a development partner are: where the vendor is located (for example, onshore, nearshore, or offshore) and whether or not they have US-based project/account managers, what their customer satisfaction rate is, how many customers they serve per year, and whether or not they can provide examples of relevant, recent work. It is always advisable that you talk to vendors on the phone to really get a feel for their communication style, but at the very least you should have a substantial Q&A time window built into your RFP process. Quality vendors will ask smart questions and sometimes even make recommendations, so hearing from a vendor (often more than once) before they submit their proposal is always a good sign.
Understandably, It can be tempting to throw together a rough feature list and send it out to get things moving, but taking the time to put as much detail and effort as you possibly can into your feature list and doing your due diligence on vendors can be the difference between an underfunded mess and the technology you dreamt of. Similar to how the quality of a paint job relies heavily on the quality of preparation, the accuracy of estimating how much time and money you’ll end up spending to achieve your desired results relies heavily on the accuracy of your feature list. Do the hard work during the RFP process to protect your project from risk down the line.