CHAPTER 4: DRAFT THE REQUEST FOR INFORMATION (RFI)
After agreeing the selection parameters and gathering the requirements, you will have most of the information you need to draft the Request for Information (RFI) document. It is worth looking at the purpose of this document in more detail, as well as the steps needed to produce the draft, before getting into the detail of what the document should contain.
As the responses to this document will be the primary means for shortlisting your options, it’s important to take the time to get it right.
This chapter contains:
- purpose of the RFI
- possible alternatives to an RFI
- how to compile the RFI
- example RFI template.
Purpose of the RFI
It is easy to gather information from company brochures and websites, or to ask them to send you details of their system or service, but this has several disadvantages:
- you’ll have a huge mass of information to wade through, much of which you probably aren’t that interested in
- every company will provide information in a different order, style and format
- it’s likely that a number of items of key interest to you aren’t mentioned.
All of which makes it very difficult to make a comparison and ensure that your favoured options really do meet all your requirements.
Using an RFI allows you to:
- provide each potential supplier with the same base information
- ask specific questions that are of interest to you
- ask suppliers to provide ideas on possible solutions to your situation (very useful if you’re not exactly sure what you want, or what is available to you)
- find out more easily whether, or how well, each supplier can meet your requirements.
Although the difference between response formats and level of detail can be amazing, there is still more consistency than if you don’t do an RFI; this makes it easier to compare options fairly. Moreover, if a potential supplier ignores your RFI and just sends you a collection of standard marketing material, they probably aren’t really interested in your organisation!
Possible alternatives to an RFI
An RFI is only one type of document that can be used when selecting a system or service. Others include:
- Request for Proposal (RFP) (or Request for Quote)
This is similar to an RFI, but usually contains more detail as the outcome is an actual proposal/quote, rather than just information. The supplier will need much more information in order to do this, and there will usually be one or more meetings with them before the RFP can be issued or responded to.
This type of document can be used during the second stage of a selection process, as described in this book. You would issue an RFI to the longlist to get enough information to shortlist, and then issue a more detailed RFP to the shortlist. This can be useful if you are using the RFI stage as a way of finding out what is possible. Once you’ve decided what you do want, then using an RFP can ensure that the shortlist all receive the same briefing to base their proposal on.
An RFP can be fairly similar in format to an RFI, but generally has more detail. You can also get a more specific response by asking them to rate each individual requirement. For example, for a package system selection you could use a scale something like this:- 1: fully compliant using the standard system
- 2: can only be partially compliant (specify any limitations)
- 3: could be fully compliant with a minor modification to the standard system
- 4: could be fully compliant with a major modification to the standard system
- 5: could be fully compliant using a third party product (provide full details)
- 6: cannot be compliant.
- Invitation to Tender (ITT)
An ITT is commonly used by larger and public sector organisations. It is a far more formal and extremely detailed document. It is usually based on a very detailed specification, which can often itself take weeks or months to write.
An ITT is normally drafted by a procurement specialist, with input from the legal team, as it tends to form the basis for the future contract.
So, why use an RFI format? It has a number of advantages:
- It’s not too lengthy or detailed, so doesn’t take a long time to draft (and is easier for suppliers to respond to).
- Detail is at a reasonably high level, so it is not too prescriptive or restrictive – it allows suppliers to offer options and choices that you may not have realised were available to you.
- It should elicit responses that are consistent enough to enable you to shortlist.
- As it’s not too lengthy, your longlist can be of a reasonable size without the comparison exercise becoming too unwieldy or time-consuming.
- You don’t need expensive specialist help to compile it.
How to compile the RFI
One element to bear in mind when writing is: what level of guidance should you give the supplier about your needs? You may have a very clear idea of what you need: if so, you should provide clear and detailed statements about what you want. However, if you have a general idea of what you need, but are undecided about exactly what the solution should (or could) be, then keep the RFI at a more general business-need level, rather than going into the detail of a particular solution. That way, the suppliers have the opportunity to give you lots of different possibilities for you to consider.
Whichever approach you decide to take, make sure that the detailed requirements are also at an appropriate level. For example, you may need to remove some detailed ones if you want the supplier to come back with options (or perhaps rewrite a detailed one to be a more high-level business need). This is also an opportunity to check that the requirements are not artificially limiting you in any way.
Once you start drafting the RFI, you should have most of the information you need to hand. The sections you still need to consider are those about your organisation and your ICT environment.
With these sections, you need to keep in mind that the supplier needs sufficient information from you to give you a useful and comprehensive response. On the other hand, you don’t want to load them down with unnecessary detail. How your organisation was founded and evolved to the present day may be a fascinating story, but unless it’s pertinent to the selection, try to restrain yourself!
Feel free to include diagrams when appropriate; these can be very helpful in conveying a mass of complex information more clearly. Even something simple, such as a chart of how your departments/locations are structured or how your current ICT is set up, can be helpful.
Once you’ve compiled a draft of the RFI, allow the core selection team adequate time to review it. Ask them: Have you missed anything out? Are all the details accurate? Does it convey your need at the right level of detail?
Example RFI template
This section includes a basic format for your RFI document; you will likely need to tailor it to meet the specific needs of each selection. Remember that you need to give your potential suppliers enough information, so that they can explain how their product or service will meet your needs. You may, therefore, need to add additional sections to give them that information.
Text in normal print can be included ‘as is’ (or tailored). Text in italics is guidance text and should be replaced with your content.
Example: Request for Information
1. Purpose of this document
This document is a Request for Information (RFI) on the [project name, product, etc.]. It is being sent to a longlist of potential suppliers in order to:
• confirm that the requirements can be met
• understand the ball-park costs, so that the business case can be approved
• produce a shortlist of potential suppliers for a more in-depth selection procedure.
Responses are NOT intended to be used for final selection of a product or supplier.
The document contains the following:
Include a normal table of contents here.
2. Background
Some information about why the selection is needed. You could include some detail from your ‘push’ and ‘pull’ reasons and your expected outcomes here, if you’re happy to share these.
3. Organisation details
Provide some information about your organisation, such as:
• an overview of what your organisation actually does, to give the supplier a feel for what you are about
• size and, if appropriate to the selection, location/s
• the functions that are affected by the selection
• any organisational specific aspects that could affect the system/service being selected (e.g. if your user base means that you are particularly focused on accessibility).
4. ICT environment
For a system you will need to provide some details about your current ICT setup, and what platforms you are willing to consider for your solution. This could include, for example:
• server operating systems in use (e.g. Windows Server 2008)
• database systems in use (e.g. SQL server 2008)
• desktop numbers and operating systems (e.g. 450 PCs, mix of Windows XP and Windows 7)
• laptop numbers and operating systems
• mobile devices (e.g. iPhones, BlackBerrys)
• details of connectivity (e.g. remote offices are connected via IPStream)
• the existing application used (this will be pertinent if data needs to be migrated)
• any applications the system will need to interface with (e.g. e-mail, accounts)
• any particular environmental factors (e.g. mobile devices must be robust and waterproof as they are used by field officers in rural locations).
You should also state if you are interested in having a hosted system (this is when the supplier manages the system on their own site and your staff access it remotely via the Internet).
5. High-level business requirements
It’s useful to give the supplier a short pen picture of your requirements. Although you will include the detailed list in the Appendix, in this section you can give them an overview of what you’re looking for.
An example, based on a real RFI, is:
Example: High-level requirements
The system will primarily be a CRM database, used to manage all dealings with the member and partner organisations. Standard CRM-type functionality, such as personal details, logging contact information and being able to maintain multiple relationships, is a central requirement.
The hierarchy of relationships between Headquarters, the regions, member organisations, associates and franchisees is complex. It is important that information can easily be accessed, searched and reported on from any perspective.
We will also use the system to organise, manage and analyse internal events, such as conferences and assemblies. This not only involves setting up the event, using multi-parameter searches to draw up attendee lists and managing invitations, but also managing travel arrangements for all attendees. As events require international travel by most attendees, this is a complex and important function.
Another aspect is management of subscriptions to the various publications, such as newsletters and mailings. The use of mail merge to send bulk mailings (using various media) is also required.
All the above activities involve workflows and the system should support these, providing alerts and storing responses.
Reporting is, as with any system, a key function. Most users will need specific reports as part of their daily work; however, the ability to provide high-level reports and alerts, possibly via a dashboard, is crucial to enabling us to gain full strategic benefit from the system.
The system will also need to interface with other internal systems, primarily XYZ Accounts (see ICT section above).
Detailed business requirements can be found in Appendix A.
6. Response information
This is where you advise the suppliers exactly what you expect to receive from them. You should amend the list below to meet your specific needs. This example is for a package system, but would be similar for other selections.
6.1 Response content
The response to this RFI should contain the following information:
Product’s fit to requirements:
• whether you can meet the requirements as understood from this document (or, if only partially, which requirements cannot be met)
• product information
• details of how you would approach data migration from our current applications
• details of what levels of support are available if we choose your product (i.e. Service Level Agreements)
• details of the technical environment needed, plus any potential options, such as hosting
• information about the product’s roadmap (i.e. plans for its future development) and its upgrade plan.
Cost and timescales:
• ball-park costs including:
• licences and options
• implementation
• ongoing support/maintenance
• any other likely costs
• an estimate of how long it will take to implement the product
• details of how you would manage the project.
Your company:
• company name, number, year of registration, registered address and headquarters address (if different)
• summary of financial situation (including turnover and profit from last year)
• information about organisations similar to ours that you currently work with (please note that references will not be taken up unless you are shortlisted)
• any company plans that we should be aware of.
Contact information:
• contact name, address, phone and e-mail details.
6.2 Receipt information
Responses should be electronic (you could specify a format or ask for paper copies if you prefer). It is more important that the information requested is clearly provided than that it is presented in a formal style.
Responses should be sent to [name] at [e-mail address and/or postal address if you’ve asked for paper copies].
All responses must be received by end [date and time].
Any responses received after this date will not be included in the selection (unless an extension is agreed beforehand).
6.3 Questions and queries
Any questions on the process or the requirements can be addressed to [name], preferably using the above e-mail address.
If necessary, you can also contact [name] on [phone number].
[Name] will involve relevant people within [organisation name] to answer queries, so please do not contact other people directly.
We reserve the right to copy questions and answers to all suppliers.
7 Confidentiality
Change this clause as necessary to meet your organisation’s policies. If you decide to use a non-disclosure agreement at the RFI stage (see Chapter 5) then you may not need this section, or you can reword it.
All information provided within this RFI, and in any additional information, should be treated as confidential.
8 Appendix A: Detailed business requirements
In this section you should copy the functional and non-functional requirements from your requirements specification.