How to Build an RFP For Selecting and Evaluating IT Tools

In this article, we share some tips on how to construct an Request for Proposal (RFP) document. It will list the major things to consider when compiling your RFP (many of which often get overlooked) and provide guidelines on a typical RFP lifecycle.

As with our prior article, let’s be mindful about costs so we’ll outline some financial considerations you should think about when you decide to embark on creating an RFP and the downstream process costs.

Given the complexity of modern IT infrastructures, an IT monitoring tool will be a complex solution. In order to fully define the requirements a network monitoring tool will require, you will need the input of a diverse group of stakeholders within your organization. By default this will include IT operations personnel, IT manager(s), Service Delivery Manager(s) but other departments may have input such as Legal, Finance (Procurement), and the Information Security team. The IT solution and what it provides affects everyone so never underestimate the cost of building your RFP. It will normally require several iterations to finalize the documentation including internal reviews and changes along the way.

Building your RFP is only one cost element. You have to decide how many vendors you want to engage in the RFP response phase. Consider this carefully as the greater the number of vendors the greater your costs of evaluating all the responses when they are completed. And don’t forget that vendors will often have a number of clarification questions that they need you to answer before the final submission date. Important to note is that more vendors equals more questions, which equals more time consumed handling queries, which ultimately equals more cost and less effort spent by your teams on other business tasks.

So here’s how an RFP is typically structured. We’ll not delve into deep detail on the various sections but this gives a flavor of what you may want to include.

RFP Section 1 - Introduction and Purpose

Describe what the RFP is designed to achieve. For example:

"Our company wants to select an IT monitoring solution to be implemented across all of our business operations. We have 3 offices, all based in the same country and the network monitoring tool will need to monitor network equipment and devices in all 3 offices, with our headquarters office being designated as the primary site.

The RFP will be issued to a total of 4 vendors."

RFP Section 2 - Timelines

The following are the expected timings for our RFP process.

• Week 0 – Issue the RFP to all vendors.
• Weeks 0-2  – Vendors can submit any queries/clarifications on the RFP document. Please email any clarification requests to RFP_ITmonitoring@company.com.
• End of Week 4 - Vendors must submit RFP response documents via email on this date by 5.00pm. RFP response to be sent to RFP_ITmonitoring@company.com.
• Weeks 4-6 - Company will review RFP responses and seek any clarifications needed from each vendor.
• End of Week 7 – Company will notify preferred vendor that they are the prime for our 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 supplier has been identified, and unless there are any late blocking items identified no further engagement will take place. 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.

RFP Section 3 - Requirements

This section will form the bulk of the RFP documentation. It will contain a wide range of specifics that the vendor solution needs to meet and possibly detailed questions on the vendor organisation itself. The typical sections that an RFP document would contain for any IT tool are listed below – but in this example we have themed it towards an IT Monitoring tool.

1. Vendor Information

• Name of Vendor
• Vendor main office address
• Vendor Contact for this RFP response (Name, email, phone number, address)
• 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 SysAdmin & operations teams. A key recommendation is to ensure that the questions are phrased in such a way to get Quantitative responses from the bidders as much as possible.

2a. FR_1

The IT monitoring solution must have a browser based User Interface for both IT Administration personnel and IT operations personnel.

3. Non-Functional Requirements (NFR)

This is an often forgotten about category of questions and many organizations struggle with what to include here. For an IT monitoring solution some questions that would be included here are:

3a. NFR_1

The IT monitoring solution must be able to poll all 250 devices in our network every 5 minutes and display the information on the Admin system console within 3 seconds of network data capture.

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 leading product security standards you require to be met and also ask the vendor what security processes and procedures they used to produce their product. Some example questions are:

5a. SR_1

What tools and software coding/testing techniques are used to ensure your software product adheres to the highest industry security standards? Please list any security standards of relevance (e.g. ISO 27001 certification).

5b. SR_2

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 Support, Integration & Interoperability. For example, questions that could be included here:

6a. OR_1

The vendor must offer support between the following hours (9am EST to 5.30pm EST) Mon to Friday. What are your support hours? Please list any exclusions.

6b. OR_2

The vendor solution must allow integration with 3rd party systems via an API. What API mechanisms are provided?

6c. OR_3

How do we get notified of patches/defect 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 product in your company’s infrastructure. Be as specific as possible.

7a. DR_1

What database is required and which release version?

7b. DR_2

What is the specification of the hardware needed to install the vendor product?

8. Product Roadmap and Releases (PRR)

This section is often useful to include to ask questions related to how frequently the vendor develops new product releases and makes them available. Example questions to consider:

8a. PRR_1

What is the frequency of issue of Major & Minor product releases?

8b. PRR_2

What is your End of Life policy for product versions?

9. Commercial Requirements (CR)

This section will usually be prepared with input from the finance (procurement team). It will often 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 a certain currency, pricing must be valid for 90 days after the date of submission of the RFP, and pricing must be inclusive of all taxes and charges.

RFP Tips and Tricks

Here are some tips for success from previous experience of building RFPs and advising organizations on RFP processes:

• Appoint an RFP owner with authority to keep the process moving to the agreed timescales.
• Have an RFP build team – this should be cross-functional from different parts of your organization.
• 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 timeframes 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).
• 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.