In this blog, we share some tips on how to construct an RFP (Request for Proposal). It will list the major things to consider when compiling your RFP and provide guidelines on a typical RFP lifecycle.
For the purpose of having a subject, we will discuss the steps to create an RFP for a network monitoring solution, however the principles discussed in this blog can be applied to any IT solution procurement project.
Who to Involve?
Given the complexity of modern IT infrastructure, an IT monitoring solution will also inherently be a complex solution. In order to fully define the requirements a suitable network monitoring solution, you will need the input of a diverse group of stakeholders within your organisation. This will include:
- IT operations.
- IT managers.
- Service delivery managers.
But other departments may have input such as:
- Finance or procurement.
- The Information Security team.
The selected solution and the benefits it provides will affect everyone, so never underestimate the cost of building your RFP. It will normally require several revisions to finalise, including internal reviews and changes along the way.
How Many Vendors to Invite for Participation?
The time and effort spent building your RFP is only one cost element to consider.
You will have to decide how many vendors you want to involve in the RFP response phase. Consider this carefully as the greater the number of vendors, the greater the overall cost of evaluating all the responses when they are returned.
Don’t forget that vendors will often return a number of clarification questions that they need you to answer before the final submission date. It is important to note is that more vendors equals more questions, which in turn equals more time consumed handling those queries.
Below is how an RFP is typically structured. We’ll not delve into deep detail on the various sections but instead give you a flavor of what you might want to include.
Want to learn more about network monitoring solutions? Take a look at our definitive guide to network monitoring and incident response.
Introduction and Purpose
Describe what the RFP has been created to achieve. For example, in our network monitoring solution RFP:
"Our company wants to select an IT monitoring solution to be implemented across all of our business subsidiaries. We have 13 offices, based in 7 countries and the network monitoring solution will need to monitor network devices and servers in all 13 offices, with our headquarters office being designated as the primary site.
The RFP will be sent to a total of 4 vendors."
Indicative Timeline Expectations
Make sure to include a projected timeline of milestones and key events in the selecting and evaluating process..
- Week 0 – Issue the RFP to all selected vendors.
- Weeks 0-2 – Vendors can submit any queries or request any clarifications on the RFP.
- End of Week 4 - Vendors must submit their RFP response documents via email before a particular time and date.
- Weeks 4-6 - Company will review the RFP responses and seek any clarifications needed from each vendor individually.
- End of Week 7 – Company will notify preferred vendor that they are the selected solution vendor for the project.
- Week 8 – Company and preferred vendor will meet in company offices to discuss the project and confirm that both parties wish to move to next stage.
- Week 9 – Company will notify via email the other participating vendors that a preferred vendor has been identified. Company will be happy to meet with non-selected vendors and provide feedback on their RFP submission at a future date and time to be mutually agreed.
This section will form the bulk of the RFP documentation. It will contain a wide range of requirements which the vendor solution will need to meet, plus detailed questions on the vendor organisation itself. A sample structure is included below:
1. Vendor Information
- Name of Vendor.
- Vendor main office address.
- Vendor Contact for this RFP.
- Vendor company status: Privately held or Public quoted company?
- Number of years vendor company in existence.
- Vendor to attach copies of last 3 years audited accounts.
2. Functional Requirements (FR)
This will be a wide ranging list of questions around the features and capability the IT solution needs to offer. This will typically be written by the IT administration & operations teams. A key recommendation is to ensure that the questions are phrased in such a way to get quantitative responses, so that detailed are encouraged..
The IT monitoring solution must have a browser based user Interface for both IT administration and user access.
3. Non-Functional Requirements (NFR)
This is an often less thought of category of questions; and many organisations will struggle with what to include. For an IT monitoring solution a non-functional requirement question would be:
The IT monitoring solution must be able to poll all 350 devices in our network every 10 minutes and display the information on the administration system console within 10 seconds of network data capture.
Don't forget your cloud environment! Network monitoring tools can now be used to monitor cloud infrastructure to ensure high availability and to identify issues before they affect operations. Read more in out blog entitled "Extending Network Monitoring to AWS and Azure".
4. Reporting and Analytics Requirements (RAR)
This section requires a lot of thought and consideration as reporting and analytics are a major need for most businesses and different stakeholder groups that want diverse and differing reports and data views. It is recommended to specify a number of out-of-the-box reports. Also ask the vendor if a custom report builder is incorporated and include questions about its ease of use.
5. Security Requirements (SR)
It is recommended that questions are included in the RFP about industry security standards, such as OWASP. Also make sure to ask the vendor what security processes and procedures they used to produce their product. Some example of such questions are:
What tools and software testing techniques are used to ensure your software product adheres to the highest industry security standards? Please list any security standards of relevance, for example ISO 27001.
How does your product adhere to OWASP Top 10?
6. Operational Requirements (OR)
This section will be quite broad and cover a number of topics such as technical support, possible integrations & interoperability. For example:
The vendor must offer support during company operating hours. What are your support hours? and where is your support team based geographically?.
The vendor solution must allow integration with 3rd party systems via a REST API. What API features are provided?
How are we notified of new patches and security fixes? How will these releases be made available to us?
7. Deployment Requirements (DR)
This section will focus on what the requirements are for deploying the vendor’s solution in your company’s network. Try to be as specific as possible.
Is a database is required and which versions are supported?
Is virtualisation supported and what are the virtual hardware requirements?
8. Product Roadmap and Releases (PRR)
This section is often useful to include to ask questions related to how frequently the vendor creates new product releases and makes them available for install. Example questions to consider:
What is the frequency of major and minor product releases?
Please detail your end of Life policy for product versions.
9. Commercial Requirements (CR)
This section will usually be prepared by the finance (procurement team) or at least with their cooperation. It will specify certain criteria that will need to be met if the vendor is selected as the preferred bidder. For example, pricing must be quoted in GBP; pricing supplied must be valid for 180 days after the date of submission of the RFP; and pricing must be inclusive of all local taxes and charges.
Do you use a network monitoring solution? Take a look at our blog entitled "Ten Reasons why Network Monitoring Software is a Must Have".
Our RFP Tips and Tricks
Here are some of our tips for success from our previous experience of creating RFPs and advising organisations on the RFP process:
- Appoint an RFP owner with authority in the organisation, to keep the process moving to the agreed timescales.
- Have an RFP build team – this should consist of members from different parts of your organisation.
- Have an RFP review team - may also contain most of the members from item 2.
- Ensure that the RFP content is as specific as possible so that the respondents have to submit quantifiable information (but allow the vendor to backup responses with appropriate qualitative information).
- Set achievable time frames for each phase of your RFP process: Definition Phase, Review Phase, Time period respondents have to submit completed responses, RFP Evaluation phase, RFP notification of outcomes phase.
- Consider what format you want to use for your RFP. Some companies prefer documents such as Word, others prefer a spreadsheet questionnaire format and others like a hybrid format e.g. Word document with the more detailed Requirements section questions in an embedded spreadsheet.
- Make it explicitly clear what Requirements are MANDATORY for the vendor solution to meet out-of-the-box, what are OPTIONAL (i.e. they can be met with additional custom scripting) and what are NICE-to-HAVE
- For the Requirements section it is recommended you design a simple scoring mechanism to assist decision making during your RFP evaluation phase. For example, you can award 3 marks for answers that FULLY MEET, 1 mark for PARTIALLY MEET and 0 mark for DOES NOT MEET the requirement(s).
- Ensure that you have run your final RFP documentation by your legal team. Allow them to weed out any inaccuracies or anything that might land you in trouble.
- And finally, based on this author’s experience, it is a good idea to write as many of the requirements section entries in the form of “acceptance tests”. As we said at the outset, there is a significant cost to your business of bringing a cross-functional team together to build your RFP. Remember, the RFP only provides a guide to allow you to select a preferred vendor. The next stage after that is for your organization to evaluate and validate that the preferred vendor product actually works in your environment and satisfies your requirements. You will need to assemble a cross-functional team to “test” that the vendor product meets all the stated needs – so by defining your requirements like acceptance tests you will streamline this next stage in your process – saving you time and (people) cost.
This article by John McArdle originally appeared on the Defrag This blog by Ipswitch.