1. Requests for Proposals pay for themselves
The RFP document will be how the development team provides an estimate on both the work described in the document and the risk you represent as a client. Better RFP documents will result in a higher response rate, more accurate estimates, less time in meetings talking about the RFP, and less padding to account for risk.
The customer acquisition process is the most expensive operation for a custom development shop. Every lead that comes in the door represents a mix of opportunity, risk, and expense that development teams work very hard to mitigate. The good news is that you are the one with the money to spend, but to get the most for your money, you need to maximize your vendors’ opportunity and minimize their risk and expense.
Start your RFP with the the project working name, who to contact with questions, and how and where to submit the RFP to. Next, write a short, high-level project summary that includes what you want to do and how you will define success. Follow the project summary with a project timeline with a deadline for submitting proposals, a start time, and when you need the project completed. If you have any specific technical requirements, include them. If parts of the project are already completed or will be sourced to other vendors, make that clear as well.
Make sure each page of the RFP has a page number; this will save you time when going over the document in phone calls. Section headings also help to quickly steer conversations to the relevant portion of the document.
Focus the RFP on what needs to be done and avoid how it is going to get done. Sometime there is a temptation to get into details, but a decent web development team will quickly figure that out on their own. There are exceptions, but focusing on what to do and not how to do it is a good rule of thumb.
Pro Tip: A good RFP document can replace about half of the scope of work document your development team will write, which translates to even more cost savings for you.