Previously in the Gatekeeper blog, we’ve written guides on how to gather requirements and create an RFP specifically for a contract management system (CMS).
In those guides we focus on how these various principles can be applied to CMS software.
We now want to provide you with a more general understanding on the RFP process and demonstrate how you can run one successfully.
We’ll examine the different stages and considerations, using some examples from our own CMS templates, to help you gain full understanding of what’s required.
In this first guide, we'll outline the key concepts and activities involved in:
- Developing an evaluation method for proposals received in response to the RFP
- Issuing the RFP to interested suppliers
Devise a proposal evaluation method
A key purpose of the RFP is to obtain proposals from suppliers expected to be able to satisfy most, if not all, of the needs expressed in it.
Checking if and how well a proposal actually does meet those needs is a critical activity that in most cases needs to be a formal and structured operation.
Consistency of approach across multiple evaluators, the depth of the scoring approach and a documented record of scores are important for providing confidence in the fairness and justifiability of the evaluation.
This might be crucial if the RFP outcome is challenged by any participating suppliers or the regulators.
Evaluation of supplier proposals is usually accomplished by use of scoresheets. This approach allows independent reviewers to assess every scorable item in or related to a proposal. Scores can be assigned or the need for more information or clarity from the supplier can be recorded.
The completed scoresheets will form part of the audit trail of how any recommendation of a preferred proposal is reached.
The scoresheet approach allows direct comparison of scores assigned to participating suppliers at the level of:
- Individual requirements or other scorable items
- Groups of related requirements or other scorable items
- Clusters of related groups
In an ideal scenario, these comparisons can be made for:
- Each individual evaluator
- An individual evaluator against another evaluator
- An individual evaluator against the average of the sum of all evaluators' scores.
The evaluation method can be simple or complex, depending on the criticality of the purpose of the RFP. Several elements need to be considered in devising a suitable evaluation method:
1. Evaluation criteria.
The evaluation criteria used in the scoresheet should match those specified in the original RFP document. If you’re referencing our CMS Document, these are in section six.
They need to match because suppliers may have relied on those criteria to focus the pitch of their proposals. Any subsequent debrief offered to unsuccessful suppliers at the conclusion of the RFP process normally reveals the score those suppliers achieved.
If there’s any discrepancy in the criteria then they may have grounds to raise a challenge to the RFP outcome.
2. Scoring scales.
A numeric scoring scale is preferred as it allows scores from multiple reviewers to be summed and averaged.
The scale should span a linear range of numbers sufficient to cover the granularity required to express the closeness of fit between requirement and supplier capability.
For example, a range of 0 - 1 can be used where all the supplier responses can be categorised as 'No' or 'Yes', or 0 - 3 for something like 'No response', 'Low', 'Medium' and 'High'.
To allow for situations where the numeric granularity between ratings like 'Medium' (2) and 'High' (3) is too coarse to capture an in-between rating, the use of decimal fractions for finer granularity may be allowed, whereby a score of 2.5 indicates 'Medium- High'.
3. Scoring context.
The meaning of a particular numeric score may depend on the context of the requirement or item being evaluated. For this reason, every element in a scoresheet should indicate which scoring context applies.
For instance, the expected response may need to indicate a level of compliance, how well objectives are met, or assignment of a cost / risk pairing as shown below:
|0||Non-compliant or no response||No response||High Cost, High Risk|
|1||Inadequate Response||Inadequate Response||High Cost, Low Risk|
|2||Minimal Compliance||Objectives Not Met||Medium Cost, High Risk|
|3||Medium Partial Compliance||Objectives Partially Met||Medium Cost, Low Risk|
|4||High Partial Compliance||Objectives Met||Low Cost, High Risk|
|5||Full Compliance||Objectives Exceeded||Low Cost, Low Risk|
4. Importance of individual scorable items.
While simple to use, the linear scoring scale has a shortcoming in that it treats each scorable item as having the same importance, therefore contributing equally to the total score.
This is unlikely to ever be the case.
Some scorable items will always be more important than others, as will already be reflected in the requirements specification, so the scoring should be adjusted to numerically acknowledge the fact, as follows:
- Importance can be indicated by the application of a 'weight' to each scorable item, a multiplier that increases the assigned raw score so that it has more influence on the total score
- The default weight setting is one, producing no change to the assigned score. The maximum weight is typically set between three and five to minimise distortion of the overall score. See worked example below:
|Priority||Requirement||Weight||Allocated Score||Weighted Score|
5. Importance of groups of related scorable items.
Related scorable items are usually documented in the RFP in groups. For a Contract Management System this might include items like access controls, workflow and contract authoring.
For evaluation purposes, groups may be assigned to clusters, like functional requirements, non-functional requirements and pricing. Just as with individual scorable items, different groups may have different levels of importance.
A common method of assigning importance to a group of scorable items is to allocate it a percentage of the maximum total weighted scores possible across all individual requirements, where the larger the percentage, the higher the importance.
The allocation to each cluster is simply the sum of allocations to each group in the cluster. For a CMS this approach allows for cluster importance ranking such as:
- functional requirements category: 50%, made up for example from access controls at 10%, workflow at 25% and contract authoring at 15%
- non-functional requirements: 20%
- pricing: 30%
Since a group's actual percentage will rarely exactly match its assigned percentage, a simple scaling factor can be calculated to adjust the group's weighted scores up or down as necessary. The scaling factor will be calculated automatically in the scoresheet following input of the desired section percentage figures.
In the worked example below for a CMS:
- Column 2 shows the maximum weighted score possible in each RFP section
- Column 3 shows each RFP section's actual percentage of the total maximum weighted scores possible
- Column 4 shows the desired RFP section percentages as listed above
- Column 5 shows the scaling factor that needs to be applied to the total weighted score allocated to each RFP section to achieve the desired percentages shown in column 4
|RFP Section||Max Weighted Score Possible||Actual Section %||Desired Section %||Scaling Factor|
6. Scoresheet preparation.
Different scoresheets and accompanying issue logs should be developed for use by various members of the evaluation team to record their assessment of scorable items in supplier proposals and related information.
Guidelines for completing the scoresheets should be provided for reference, and a familiarisation session held for the evaluation team.
The scoresheets should cover the following areas:
- Functional and non-functional requirements, for scoring by stakeholders according to their backgrounds and expertise
- Pricing, for scoring by the core team* with assistance as required from members of the Finance team not otherwise involved in the RFP process, if possible
- The contract (whether the supplier's contract or the supplier's comments about the organisation's contract), for scoring by the core team with assistance as required from members of the Legal team not otherwise involved in the RFP process, if possible
- Supplier viability, proposal quality and compliance with prescribed response formats, for scoring by the core team
- Product presentation, for scoring by all team members who attend the presentation sessions.
*Here we refer to a “core team”, which would be the team that is running the RFP from an internal viewpoint and has the most relevant expertise. If this were an RFP for a CMS then that might be the Contract Management Team.
Issue the RFP to interested suppliers.
Issuing the RFP is simply a matter of emailing each invited supplier a copy of the RFP document, the RFP Response and RFP Pricing templates (see CMS examples here) that you prepared earlier, and optionally your organisation's standard contract covering acquisition of software and related services if there is one.
The email should advise suppliers about the RFP Activity Timetable, and include a copy of the timetable in the body of the email to reinforce its importance.
Once the RFP has been issued, the core team is likely to be involved in some or all of the following activities:
1. Deal with communications from the invited suppliers.
For both probity and efficiency reasons, all communications with invited suppliers are to be conducted via email directed to and handled by the Designated Contact specified in the RFP.
This approach allows a central log to be maintained of all such communications, showing dates and times when received and responded to, the nature of the communications and who dealt with the subject matter, and so on.
On receipt of an email from an invited supplier, the Designated Contact should log the details, then following any necessary discussions with the core team, forward the email to a core team member or an RFP stakeholder for consideration and response.
The email responder may call on anybody participating in the RFP for assistance in dealing with the email's subject matter or escalate the matter via the core team management as necessary. The response can be a straightforward answer to a query, or it can raise questions for the supplier in order to gather more information.
On receipt of an email responder's response to a supplier email, the Designated Contact should update the communications log with pertinent details then create and a send a reply to the relevant supplier email.
2. Respond to RFP questions.
There will inevitably be queries raised by suppliers about some aspect of the RFP.
Apart from questions, clarifications may be requested or corrections suggested, reasons may be provided for why the timetable is unrealistic and should be extended, there may be appeals for exclusion from some element or other of the RFP, there also may be proposals for a completely different way of responding to the RFP or satisfying its requirements.
To ensure all such queries are dealt with, details should be recorded in a log, along with the relevant responses.
A written response is required for every matter raised by a supplier, no matter how trivial. The responses must be professional, as accurate as possible and timely.
Except where a query and its answer are genuinely confidential to the questioner, every question received and its response should be sent to all participating suppliers without revealing the identity of the questioner.
3. Issue revisions to the RFP.
Circumstances can and do arise that can only be addressed by changing the RFP in some fashion. The substance of a change can range from trivial to substantial, and may result in amendments to various scoring templates. Changes may also be needed to the RFP timetable to allow participating suppliers to:
- Understand the nature and implications of the changes
- Consider a response to those changes
- Decide whether or not to participate in the revised RFP
- Revise and update, or replace completely, any work on a response done to date.
Where changes to the RFP timetable are deemed necessary, before notice is given to the participating suppliers, internal stakeholders need to be advised and availability of key people may have to be renegotiated to ensure that the revised dates remain internally acceptable.
Where the RFP timetable does get changed, to minimise the opportunity for complaints or challenges, it should apply to all participating suppliers even if only one requested such a change.
In extreme or unusual circumstances, it may be necessary to withdraw the RFP. An appropriate statement should be issued to the participating suppliers, stating any reasons that are allowed to be revealed, thanking the suppliers for their efforts to date, and apologising for the inconvenience caused.
4. Manage supplier compliance with timetables.
Suppliers are always busy chasing new or repeat business, particularly at end of quarter, half-year and full year. They can be affected by events outside their control, like the weather or political instability.
Their staff can leave, get sick, take holidays, attend sales conferences and the like. For these and many other reasons, suppliers can fail to meet a date specified in the RFP timetable.
The consequences to a supplier of missing a deadline depend on how the RFP specifies a response to such failures. Whether or not the supplier provided timely notice of an expected failure may also influence the consequences.
To help achieve compliance with timetables, each supplier should be formally advised about:
- The approach of any deadline, with a few days' notice. This advice may help to minimise the number of missed deadlines. It may also result in some requests for deadline extensions from suppliers
- The passing of any deadline, on the next business day following the deadline.
This advice should acknowledge, as appropriate, the supplier's:
- compliance with the deadline, with thanks, or
- failure to meet the deadline, with a request for explanation and intentions going forward. Details of the possible or actual consequences of non-reply or failure to provide an explanation should be provided, as well as a further deadline for a response.
Supplier compliance with timetables should be closely monitored to minimise any delays and requests for extensions.
A collection of modifiable templates containing instructions for use are available to assist with the activities specified in this article and others in the RFP Guide series. They are designed to facilitate an RFP for a Contract Management System but most of the principles and content can be applied more widely.
To recap, a scoring approach should:
- Make comparison of proposals and scorers straightforward
- Use scoring scales to give meaning to scores
- Include weightings so that scores are given the appropriate relative importance
When interacting with RFP participants, it’s important to:
- Release of the RFP and all associated documents to the invited suppliers
- Handle supplier questions about the RFP in a fair manner
- Reissue the RFP if changes are required in response to supplier questions
- Ensure suppliers comply with the RFP timetable.
You should now be able to plan and prepare for, and when ready, conduct the RFP stage activities outlined in this article.
Our next article in this RFP Guide series will outline the key concepts and activities involved in managing communications with suppliers, conducting the preliminary review of each proposal received, providing feedback to and obtaining responses from suppliers about their proposal issues, and deciding an agenda, delivery method and timing for each supplier's presentation.