What is an RFI?
A request for information (RFI) is a formal request made to a vendor (or service provider) who's aim is to ascertain whether a vendor's product would be suitable for addressing a company's need.
In a previous post, I mentioned that there were a few ways to get a solution:
- Leverage existing systems.
- Extend existing systems.
- Buy a vendor product.
- Build a solution.
An RFI is used as one of the earlier phases of determining which (if any) vendor products fit; thus if you should buy it. Prior to performing an RFI, a high-level understanding of a company's needs are required as well as a short analysis of vendors who may possess suitable product offerings.
Why do we use RFIs or RFPs (Request for proposal)?
We don't need to build everything do we? Just because we can do something doesn't necessarily mean we should do something. Basic economic theory has something known as comparative advantage. This theory is usually used to describe international trade but I feel that it can be applied to many other situations.
Suppose a company has limited people resources but these resources have the expertise to develop either spreadsheet or IVR applications. Also, suppose that the company needs both of these applications but can only do one or the other. Because we know that there are suitable products that support spreadsheets, is the company better off purchasing a spreadsheet application and building their IVR applications versus attempting to build everything themselves?
Unless something is a strategic differentiator, if suitable offerings exist, you should use them. This allows you to concentrate on the activities that are key to your company.
Parts of an RFI - The introduction
- Confidentiality agreement - You will be sharing information about your company that you do not want distributed to anyone else. Thus, before an RFI can be sent out, you must have a signed confidentiality agreement from prospective candidate vendors. Your company's legal team must approve both the RFI as well as provide the confidentiality agreement.
- Corporate overview - This information is provided to give vendors insights and context into what your company does.
- Project background - State what the project is trying to achieve as well as where you are in the process (what steps you have done or are in the process of doing.)
- IT overview - Give the vendor a basic idea of the types of systems their solution will have to interact with (e.g., we have mainframes, IVR systems, we use J2EE and Oracle.)
Parts of an RFI - Description of the process
- Timelines - Provide timeframes for RFI completion and evaluation.
- Post RFI participation needs - State what the process will be after receiving the RFI. Will there be a need for face-to-face conversation to go into more depth? What follow-up will you want to do (e.g., reference checks & demos)?
Parts of an RFI - The questionnaire
- RFI questionnaire - An elicitation of the basic requirements that need to be met. Obviously, a high-level understanding of your requirements is needed, but not a detailed one. Prematurely getting into too many details may bias your RFI and lead you towards a build mentality! Major non-functional requirements should also be stated (e.g., projected capacity, availability.)
This post is not meant to be a guide on writing an RFI but rather to give you a basic introduction to the purpose and components of one. RFI's are extremely important as they can lead to the purchase of expensive products and services. An inappropriate product choice can cause a company more harm than good.