How to turn your Contract Management System requirements specification into an RFP

Previously in the Gatekeeper blog, we’ve provided a number of articles to help outline the process for implementing a Contract Management System (CMS) in your organisation. These have included:

• How to prepare a clear set of requirements for your CMS using a CMS Requirements Template
• What to consider in terms of people, process and technology
• How to prepare your business for contract lifecycle management

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:

1. What is an RFP?
2. Why is it used?

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.

The RFP Process in Detail

Conceptually, the RFP process is straightforward:

1. Prepare the requirements specification, covering the situation that needs addressing including current issues and problems, the key stakeholders and details of high-level and low-level requirements representing the desired situation
2. Select candidate suppliers who may be able to satisfy the requirements, execute a confidentiality agreement with them, and determine their level of interest in solving your issues (this can often be the RFI stage, prior to an RFP)
3. Review the requirements specification, obtain stakeholder input, refine and optimise requirements
4. Develop the RFP documentation, establish the RFP timeline, assemble the proposal evaluation team
5. Devise a proposal evaluation method, assign weightings to each individual requirement and groups of related requirements, build the proposal scoresheet
6. Issue the RFP to interested suppliers, respond to any supplier questions, issue any necessary updates to the RFP
7. Review all received proposals, raise and resolve any issues, attend supplier presentations
8. Evaluate and score each proposal, normalise scores to allow supplier comparisons on a like-for-like basis, summarise and compare scores
9. Identify proposals of interest, advise relevant suppliers of issues and concerns, ask suppliers for best and final offer
10. Evaluate final supplier proposals, negotiate the final deals, identify the best proposal and commence contract negotiations with the applicable supplier. On successful execution of a contract, notify the unsuccessful suppliers and advise them why if requested.

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.

Planning your 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:

1. The simple RFP process outlined above consists of a number of individual activities. Planners should consider the extent to which such activities may need to be designed from scratch or adapted from other RFPs to suit this particular RFP
2. Internal people, or sometimes independent third parties, need to be selected to help design and/or perform the RFP activities, and their time booked so they can be available when needed. Obtaining approval from the managers of the internal people as early in the RFP process as possible is recommended
3. Timelines need to be estimated after considering a number of internal and external influencing factors, including dependency on the completion of previous stages of the RFP process.

A cautionary note about RFP timelines

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.

Considerations in estimating RFP timelines

When establishing timelines for the RFP, remember to allow sufficient time to deal with the implications of the following situations:

1. The number of suppliers invited to respond to the RFP. The more proposals received, the more reading, assessment and scoring that the proposal evaluation team has to perform
   
   
2. The scale and complexity of the RFP in terms of number of elements and requirements, and their internal dependencies and relationships. This is important from several aspects:
• For the supplier, the larger the number of requirements, dependencies and relationships to consider and respond to, the longer it is likely to take to prepare a proposal
• For the proposal evaluation team, the larger the number of requirement responses to consider and score, the longer it will take to evaluate the requirements component of a supplier’s proposal
• The more requirements there are in the RFP, the greater the likelihood that some elements of each proposal will need to be negotiated.
3. The number of preferred supplier proposals. Since the number of proposals that might be considered as viable contenders can’t be known in advance, it is best practice to allow for a maximum shortlist of two or three proposals from up to six invited suppliers. 
   
   This number is important for estimating the time needed for review of the contract component of a supplier’s proposal. This applies to evaluation of:
• The supplier’s concerns with your standard contract if it exists and if they are willing to use it, and
• The terms and conditions of the supplier’s standard contract and related legal terms such as Data Protection Agreements (DPAs)
4. Reading rate. A book or an article can typically be read at a rate between 25 and 35 pages per hour by people not trained in speed reading. It’s a different matter when reading proposals and contracts as part of the RFP process or other review processes.
   
   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.
   
   
5. The time of year. All organisations, and often many individuals, have times when they need, or choose, to focus on certain activities.
   
   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.
   
   Times for an RFP to be avoided if at all possible, or at least worked around, might include:
• Your financial year-end and also perhaps financial half-year and quarter-year ends
• Any of your invited suppliers’ financial year-ends and quarter-ends. These are popular times for organisations to request proposals from suppliers because of the chance of receiving good deals. The increased amount of proposals requested at these times can place supplier staff under strong pressure to deliver, which may result in proposal shortcomings due to the excessive workload
• The Christmas / New Year holiday period and other major holiday times when your organisation and/or the invited suppliers might normally close down for the break
• Any other busy work periods for, or holidays already reserved by, key members of your RFP team
6. Ongoing workload. All the internal people assigned to participate in the RFP in any way already have a day job with its own outcomes, obligations and deadlines. Discussions with the managers of these participants should be held to advise about the need for the participants and the time commitment required for the RFP effort, and to obtain approval for that time commitment or a lesser amount as is deemed feasible.

RFP documents

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:

1. The CMS RFP Template (MS Word). Populated with some details from the CMS Requirements Template plus other information, this template is used to provide invited suppliers with sufficient detail to understand your organisation’s CMS needs, issues and wants, and the RFP timetable.
   
   The template also provides a guide to suppliers on how to respond to the RFP and how their proposals will be evaluated.
   
   
2. The CMS RFP Response Template (MS Excel). Populated with details from the CMS Requirements Template, this template is used to collect a compliance response for each requirement from the supplier. This should be returned by the supplier for evaluation
   
   
3. The CMS RFP Pricing Template (MS Excel). This template used to collect details of all pricing associated with the provision and implementation of the CMS, plus any initial and ongoing support, maintenance and training. To be returned by the supplier for evaluation.

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.

Preparation of the CMS RFP Template

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:

1. <Due By Date> - the due date for completion of each individual activity listed in section 1.4 RFP Activity Timetable
2. <Go Live Date> - the preferred start date for production use of the CMS listed in section 1.2 Purpose
3. <TZ> - the time zone used for the 'Due by Dates' listed in section 1.4 RFP Activity Timetable

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.

Preparation of the CMS RFP Response Template

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:

1. Introduce the evaluation team members to each other and to the team who will be running the RFP
2. Discuss the general activities that make up the evaluation effort
3. Present the approach to be followed when an evaluation team member is facing difficulties in completing assigned activities as planned
4. Outline the normalisation approach that is commonly used to allow like-for-like comparisons of individual proposals
5. Describe the grading analysis that typically follows consolidation of individual scoresheets in order to rank the overall acceptability of each proposal
6. Highlight the steps involved in seeking senior management approval of the preferred proposal

Wrap-up

At the conclusion of the RFP development step of the RFP process:

1. The RFP documents will have been prepared and checked for correctness, consistency and clarity
2. Instructions for invited suppliers will be clear and unambiguous
3. The RFP timelines will have been established
4. The plan showing who is required to do what and when will have been finalised and approved by the managers of all internal participants in the RFP
5. The core CLM team will be ready to start on the next RFP stage, including the development of the proposal evaluation method and the scoring approach.

In Summary

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.