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.
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:
But other departments may have input such as:
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.
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.
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."
Make sure to include a projected timeline of milestones and key events in the selecting and evaluating process..
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
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".
Here are some of our tips for success from our previous experience of creating RFPs and advising organisations on the RFP process:
This article by John McArdle originally appeared on the Defrag This blog by Ipswitch.