A request for proposal, or RFP, is a document that describes a project's needs and asks for proposed solutions from qualified vendors. A good RFP can help ensure you have good vendors and your project is completed as planned. This article will help you get started writing good RFPs.
It's a fact of life at most organizations that we often see a pressing need and simultaneously recognize that we don't have the expertise or resources to meet the need internally. In such cases, how do we decide which outside organization to hire or partner with? The dominant response to this question for the past several decades has been the Request for Proposal, or RFP. An RFP is a document that describes a project's needs in a particular area and asks for proposed solutions (along with pricing, timing, and other details) from qualified vendors. When they're well crafted, RFPs can introduce an organization to high-quality vendor-partners and consultants from outside their established networks and ensure that a project is completed as planned.
What's the Purpose of the RFP Process, and When Do You Need One?
Any one of the three reasons below would be sufficient to justify issuing an RFP, but taken together they're a powerful case for paying careful attention to the drafting of RFPs and the evaluation of responses.
- Finding the vendor best suited to the needs of your organization. Casting a wide net and letting the unknown companies compete against the familiar ones will increase the likelihood of finding just the right vendor for your current needs.
- Accountability and good governance. Due to its open nature, the standard RFP process encourages fairness and transparency while minimizing the likelihood of corruption or favoritism.
- Needs assessment. The process of writing an RFP gives you an opportunity to interview key stakeholders and bridge the gap between the vague aspirations that launch a project and the concrete, measurable requirements that guide it to successful conclusion.
First and foremost, you need an RFP when your policies, your funders' policies, or government regulations require one. If there are no policies or guidelines in place, balance the rationales listed above against the time it takes to write and distribute a good RFP. Also, be sure to use common sense — for example, issuing a procurement document for the purchase of pencils and other office supplies is unnecessary. RFPs are more frequently issued for complex, highly customized products and services. An example of such a project is a website redesign in which the project likely has numerous requirements and involves several types of expertise. For simpler products and services, organizations often circulate a Request for Quotations (RFQ). An RFQ is shorter and less labor-intensive than an RFP — for example, developing a small widget for your website that allows it to integrate with another system (such as a donor management system or CRM database) is a project with a fairly small, well-defined scope. You and your colleagues may be able to accurately estimate the number of hours required based on past experience.
What Are the Standard Steps in the RFP Process?
The steps of the RFP process can vary, but you should consider all of these even if you don't implement every single one.
- Establish the project's boundaries. Before you start writing your RFP, ask your organizational leadership and other key stakeholders about major project constraints. For example, what's the total approved budget for the project? Are there are any deadlines that can't be shifted or postponed? Are there certain project features or technical requirements that your colleagues and supervisors have declared non-negotiable?
- Identify key stakeholders and advisors. Writing an RFP and evaluating responses involves a lot of work, knowledge of your organization, and some understanding of vendors and consultants. For each project that requires an RFP, assign one person to lead the process and a small group of stakeholders that the project leader can interview while drafting the RFP and evaluating the responses.
- Talk to stakeholders and define your project needs.
- Write the RFP. (See the next section for details.)
- Create a draft of your scoring criteria. Since you've just finished taking the pulse of your colleagues regarding this project, it's also an ideal time to draft your scoring criteria. Often these criteria are weighted to reflect your priorities. For example, you might rank replies on a scale of 1 to 10 for each criteria, but experience working with nonprofits and charities will count for 30 percent of the total score, while proximity to your offices counts for 10 percent.
- Circulate the RFP. All your work will be for naught if prospective vendors don't see the RFP. Where you post or publish your RFP depends on the types of vendors you want to reach. If you prefer to work with local companies, find the business journals for your region and post a short notification in their classified section. If it's most important that you work with consultants who have prior experience with nonprofits and charities, post your RFP in nonprofit news outlets such as the Philanthropy News Digest, which offers RFP publication as a free service for nonprofits and foundations. NTEN's 501 Tech Club mailing lists are a good place to reach nonprofit tech consultants in your region. Finally, the RFP Database is a free online resource open to organizations of all types seeking to publicize their project needs.
- Review responses. Perform an initial read-through of the responses, paying particular attention to their proposed solution (often included in a section called the Statement of Work).
- Research novel technologies as necessary. When a vendor suggests a solution that you haven't encountered before, don't be too quick to dismiss it. Do your own research, as novel technology might be a better fit than the tools you're more familiar with. For example, if you distributed an RFP for a website redesign and a vendor's response recommended a content management system, their solution might suit your stated needs quite well and provide additional features you hadn't considered. Useful sources of information include our Community Forums the software comparison reports at Idealware, and NTEN's 501 Tech Club mailing lists.
- Research the vendors' track records. There are several ways to gather information about the vendors competing for your business. Local technology mailing lists are one place to start. Also, consider asking for references from RFP respondents themselves or ask to see examples of their work. As much as possible, these references and samples should relate to projects that match your own in terms of size, budget, and audience. Once you've narrowed down the list of respondents to a handful of the most promising, it's often helpful to arrange in-person meetings with the finalists.
- Score the responses and select a vendor.
- Negotiate and sign a contract. Selecting a vendor doesn't mean you have a binding agreement. The RFP response is a proposal, and you can accept it as-is or use it as a starting point and refine the details during follow-up conversations with the vendor. As you reach agreement on details concerning deadlines and project deliverables, be sure to document them and include them in the contract. Such details are often included in a contract addendum or Statement of Work.
What Information Should You Include in Your RFP?
RFP templates and examples written by other organizations are rough guides at best, but they're useful starting points when you're not sure how to get going. Entrepreneur's sample website RFP and Free Management Library's generic RFP template are two of many such templates. Nonprofit guides have some sample RFPs more specific to the nonprofit context. Even though each RFP is unique, most of them contain the following seven sections in one form or another.
- Organizational background
- Short project description
- Project requirements and project objectives: This is often the lengthiest section of the RFP, as it describes the characteristics that define a successful outcome in your estimation. Keep in mind that, in general, specific, closed questions are easier to evaluate and score than open-ended ones. The following are some suggestions that might help you when writing this section:
- Define your audience.
- List required and desired features.
- Note any system integration needs.
- Indicate any preferred tools or systems.
- Clarify whether you are seeking interface design, back-end development, or both (if applicable).
- Project budget
- Milestones and deadlines
- Questions and required information: Is there any other information you'll need in order to evaluate and score responses? You can ask for almost any information in an RFP – your questions will vary based on your past experiences with outside consultants and the nature of the current project. For example, if you give preference when hiring to minority-owned, diverse firms, you can make that clear in this section.
- Contact information and deadline for submissions
How Should You Score and Evaluate RFP Responses?
As mentioned above, creating scoring criteria while drafting your RFP will save you time in the long run. As you discuss project requirements, ask your colleagues which features and requirements should receive the highest priority and use this input to craft a list of scoring criteria. Then assign a 1 to 10 value to each vendor's response and adjust those scores according to the weight you've given. For example, if you rate a vendor's SQL Server expertise as a 7 on a scale of 1 to 10 and you've given that criteria a 30 percent weighting, you should assign this vendor 21 points. Ask more than one person to participate in scoring the responses. Average the scores of all team members for each vendor's response. Award the contract to the vendor with the highest average score.
Additional Resources
These articles contain useful ideas about the types of questions to ask vendors:
