Getty Images
How to write an RFP for a software purchase, with template
Software buying teams should understand how to create an effective RFP. Here's a look at what components to include, along with a free, customizable template.
Too many companies ask for complex information or create poorly written requests for proposal. That's why software buying teams need to understand best practices.
An RFP can improve the software purchase experience for both software buying teams and vendors. The important document tells vendors the key information they must provide to software buying teams. And it gives buying teams a common reference for making purchases and can also help reduce the cost of purchasing software.
A good RFP is not a given.
The buying team understands that vendors must put in time-consuming work to gather the necessary information for the submission. To that point, the buying team should provide a clear, straightforward RFP template that avoids repeating information in different sections or including unnecessary information about the specific software purchase. The buying team should also keep vendors informed of all required changes. For example, the buying team should relay to the IT vendor any adjustments affecting dates, requirements or addendums that clarify certain points within the RFP's previous version.
As an overview, the RFP should include key dates, contact information and any additional materials that help vendors determine right away whether they can meet the request. This step reduces the time spent acquiring critical information over months of discussions.
Representatives from all major stakeholder groups should review the RFP and any supporting documentation for accuracy before release.
Click here to download our
free RFP template for your
next software purchase.
Here are some ideas for what to include in an effective RFP for a software purchase, along with a downloadable RFP template with additional guidance. Organizations can use the free download as a starting point for a customized template.
Overview of common RFP sections
An RFP for a software purchase may contain the following sections to provide IT vendors with the required information:
- Title page. The first page of the RFP should include the company's legal name, project name, document version number, published date and anything else that may be helpful, such as a document number or the name of the person who published the document.
- Change log. Following the title page, a change log can highlight major revisions to the RFP. This step also simplifies the document review process as the file goes through various revisions.
- RFP overview. This section explains the RFP's purpose in a paragraph or two. Typical highlights include software type, such as an ERP system, and a high-level explanation of the organization's desired functionality.
- Company overview. Use this passage to provide a summary about the company, especially in areas that are important to the vendors. This category may include the number of employees, the industry and the locations where employees work. This last point is critical when employees work in multiple countries since different data retention and privacy laws may come into play. The overview can include information such as the company's mission, vision, values, strategic direction and a detailed breakdown of any relevant data to the RFP. Relevant data may include an analysis of employees by location, employment type and other employee data if the RFP is related to HR software.
- Project requirements. Describe the project in this section, including what's driving the need for new software, a high-level list or a detailed spreadsheet with the requirements, anticipated project phases, proposed schedule and other information to help vendors understand the project's scope.
- Proposal rules, requirements and templates. Here, the software buying team explains to IT vendors what they need to consider when putting together an RFP response. This portion should outline when and how to submit the proposal, what information to include, key dates, maximum number of pages, how vendors should raise questions and how the buying team responds. The RFP may specify mandatory information IT vendors must include in their proposal, such as a product roadmap, fees and how they meet the requirements.
The software buying team may specify the document format(s) vendors should use when submitting responses, such as PDF format or using a certain font size. For example, the vendor can fill in and submit a pre-formatted spreadsheet with a list of requirements. The buying team can provide a spreadsheet with a list of requirements and request that vendors return the completed spreadsheet in the format provided.
This is also the section that can include any legal information. For example, there may be a note indicating that the buying team can change the RFP at their discretion by a certain date. There could be rules related to vendors modifying submissions or withdrawing from the process if the buying team moves forward with those changes, including the date until that may happen, and rules related to how the vendor can modify their submission or withdraw from the process.
The IT vendor templates could be appendices rather than embedded in the RFP. This step enables the RFP to focus on the project content. For example, buying teams can offer a form that vendors must complete to confirm their interest in the bidding process. - Evaluation process. In this section, the RFP outlines the evaluation process for submissions, such as how each section awards points, who serves on the evaluation committee and the vendor selection process for moving to the next round, such as live demos.
A table with a breakdown of points by section can help guide vendors to put effort into sections with the most points. Evaluators can use the table to help standardize their reviews. - Contract negotiations. This outlines the general guidelines related to contract negotiations and what happens if there is no agreement. The wording here may reinforce that the vendor and company's agreement is not final until signing a contract, highlighting that winning the RFP process is not the final step.
