Here, we'll provide an outline of the Request for Proposal (RFP) process, and set out the steps needed to prepare an RFP based on the information captured in your CMS Requirements Template.
Before we go into detail on how to run an RFP process, let’s first look to answer two high-level questions:
A Request for Proposal is a document used to help formalise and standardise the process whereby an organisation procures a new service or asset.
The term RFP is often used interchangeably with RFQ (Request for Quote). It's also related to RFI (Request for Information), which is generally a shorter process to shortlist a set of suppliers, prior to a more detailed RFP. Then there's RFx which is considered a catch-all for the above.
Although the strict meaning of these terms is slightly different, they’re all considered parts of the same processes.
In principle, an RFP should ensure a transparent, consistent and fair buying process and help the buying party secure the best solution for their needs.
In some instances, such as with public bodies, RFPs can be mandatory so that there is a defensible audit trail for procurement processes above a certain value.
In other organisations this may not be mandatory but rather simply desirable as it will help ensure a thorough and repeatable process is applied to appropriate purchases.
Conceptually, the RFP process is straightforward:
Note: Various legal jurisdictions apply a regulatory framework to RFPs that can add complexity to the process. Care is needed in these jurisdictions because breach of the regulations may invalidate the outcome of an RFP.
Solid planning is critical to the outcome of an RFP and should normally commence after finalisation of the CMS Requirements Template.
The plan needs to be comprehensive and should allow for contingencies. Compliance with the plan by all involved must be closely monitored, with rapid remediation of any non-compliance.
Any plan must consider a number of elements:
The estimation of time or overall effort is a notoriously difficult business, especially in the presence of an unknown number of unknowns that can only be addressed by a best guess.
On this basis, ambitious and overly optimistic RFP timelines are all too common.
It can be an embarrassing and humbling experience to have chastised suppliers for failing to meet RFP timelines that you have imposed on them, then failing to do so yourself with self-imposed timelines.
Experience is the best guide, assisted by mentoring from the already experienced and feedback from suppliers invited to participate in RFPs.
Previous RFP experience may not be much help if the subject matter for a new RFP hasn’t been dealt with before, or if no records were kept about how effective the timelines were in other similar RFPs. Even if an RFP is similar in many respects to others, the scale of their requirements may be too dissimilar to this RFP for their timelines to be useful as a guide.
An aggressive timeline, possibly to meet a convenient or symbolic date that takes no real account of the work involved, can result in a poorly prepared, evaluated or negotiated proposal and/or contract.
Either on receipt of the RFP or while it is running, invited suppliers may advise that the timelines are unrealistic or unachievable, and decline to participate in the RFP or request time extensions during the process.
An overly generous timeline can lead to loss of focus by suppliers initially, with potential for a rushed proposal preparation as they face an aggressive timeline of their own making.
For the proposal evaluation team, the risk is that other activities will take precedence while attention is off the RFP, resulting in an inadequate, rushed evaluation effort despite the evaluation team’s efforts.
When establishing timelines for the RFP, remember to allow sufficient time to deal with the implications of the following situations:
This is because, once read, each proposal component or contract clause has to undergo an evaluation process that can slow down the reading rate to somewhere between 10 and 15 pages per hour.
Each component or clause needs to be considered and understood, checked for correctness, precision and any conflict with other parts of the proposal or contract, and so on.
The quality of the outcomes of an RFP can be seriously affected when such activities require the attention of people who are critical or important for the running or concluding of the RFP, leaving little or no capacity to participate in the RFP.
Since development of the CMS requirements specification has typically been achieved over steps 1 - 3 of the detailed RFP process described above, transforming those requirements into an RFP is considered as the first part of step 4 - Develop the RFP documentation.
We have developed three templates to assist you in this work:
The template also provides a guide to suppliers on how to respond to the RFP and how their proposals will be evaluated.
The RFP that will be issued to invited suppliers will contain all three templates.
If your organisation has its own contract that it prefers to use for the acquisition of software and related services, an editable copy of that contract should accompany the RFP templates for the suppliers to review.
This document provides self-contained guidance about the nature of each piece of information that needs to be added to it.
There are three distinct types of change required:
1. Placeholders are used to indicate text that needs to be replaced by the appropriate values. These placeholders are:
2. Red text is used to highlight any guidance for completing a section of the template. The new text should be black, and the red text should be deleted on completion of entry of the new text
3. Green text is used to indicate which details from a specific tab in the CMS Requirements Template should be copied into the CMS RFP Template. The green text should be deleted on completion of the copy/paste operation.
This spreadsheet provides self-contained guidance about how its various tabs should be populated with data from the CMS Requirements Template spreadsheet.
Following completion of these changes, the spreadsheet should be saved with a meaningful name not containing the word ‘Template’.
Assemble the proposal evaluation team
The final activity in the preparation of the RFP for a CMS is to arrange a kick-off meeting with the designated proposal evaluation team. This can be conducted face-to-face as the situation permits or by using the preferred meetings technology when people are widely dispersed.
However it’s conducted, the purpose of the kick-off meeting is to:
At the conclusion of the RFP development step of the RFP process:
You should now have completed all the necessary documentation to run a smooth RFP process for procuring your new Contract Management System.
If you are considering running an RFP for a CMS and would like to hear more about Gatekeeper, then please contact us today.
Rod is a seasoned Contracts Management and Procurement professional with a senior IT Management background, specialising in ICT contracts
