A generally accepted (and obvious) enterprise “best practice” is to procure services via a robust competitive methodology. In general, this is achieved by issuing a comprehensive request for proposal (RFP) to each of the potential vendors for that service. The practice has now become so common that many organizations have developed a standardized template (or templates) and are able to rapidly churn out RFPs to meet the demands of its business unit customers. This semi-automated approach accelerates the overall procurement timeframe and enables the organization to rapidly achieve superior results for the procurement of commodity products and services.
Unfortunately, as with any automated process, this approach has also led to a reduction in the critical thinking that is applied to each RFP. For large and complex deals (such as technology outsourcing), “filling in the blanks” on a template isn’t sufficient. Simply releasing an RFP isn’t best practice on its own; the RFP needs to be carefully composed in order to maximize the return that the enterprise obtains from the proposal process. Too often we have observed large technology transactions in which a sub-standard initial RFP leads directly to significant problems in the rest of the procurement process.
In this article we review how an RFP should facilitate the competitive procurement process, identify areas in which many RFPs fall short, and suggest ways in which the typical RFP could be improved in order to mitigate these issues. We will use the following principle goals of a competitive procurement as a framework for the review:
- To effectively create the competitive environment
- To clearly define the service being procured
- To enable the objective evaluation of vendor responses
- To harness the competitive environment to achieve the optimal terms, conditions, and pricing for the enterprise.
Effectively Create a Competitive Environment
A competitive environment requires multiple, motivated bidders. The most carefully planned procurement process can be thrown into turmoil by key vendors providing a weak response or electing “no bid.” This is particularly the case in specialized disciplines with a limited number of potential vendor options. While the enterprise can assume that vendors will bid for commodity products or services, this isn’t equally axiomatic for large-scale technology outsourcing transactions.
There are two primary reasons that a vendor might elect to provide a half-hearted response or not to bid. Either a vendor can’t see sufficient benefit in providing the service (for example, the deal provides an unacceptable risk/reward ratio) or the vendor doesn’t feel that the investment of resources in the selection process is warranted (perhaps the vendor feels it has insufficient likelihood of winning the business). In those cases where outsourced services are being re-procured, non-incumbents are particularly sensitive to their inherent disadvantages with respect to the incumbent. With this in mind, the RFP should do five things.
Accentuate the Positive Aspects of the Deal
In complex outsourcing transactions, the potential benefits of the deal need to be made clear to the vendors. While this might appear to contradict other goals of the RFP (such as using the competition to achieve the optimal contract terms), a balance does need to be struck. The enterprise should be judicious when including speculative requirements that are clearly unreasonable or make the enterprise seem less appealing to work with. The tone of the RFP should also be adjusted to allow for the slightly different vendor dynamics. Another consideration is that the bulk of service provider margin is made by providing additional or “discretionary” services, or by having an inside track on additional projects through incumbency. If the enterprise anticipates using discretionary hours or if there are related projects in the pipeline, the RFP should accentuate these items.
Tell the Vendors What You Hope to Achieve
The overarching goals of the procurement should be clearly defined and prioritized to enable each vendor to create a compelling solution tailored for the enterprise’s particular goals. In addition to the standard dimensions such as “improve quality” or “reduce cost”, other typical objectives might include making costs more predictable or to obtain access to best practices and innovative technology. The RFP should state clearly any particular aspects of the services that the enterprise wants to improve or operate at a higher level of performance. This strategic information levels the playing field with the incumbent vendor and helps all vendors address the key goals of the initiative within their RFP response.
Enable the Vendors to Differentiate Themselves
The RFP must provide sufficient business information to enable each vendor to understand the context of the outsourced service. This should include information along multiple dimensions, including business (strategic objectives of the enterprise, how the services support the enterprise’s business processes, the criticality of the services to the enterprise’s business, anticipated business changes that may impact the services and so on), operational (volume of transactions, calendar/time of process execution and extent of manual intervention required), and technology strategy (technology roadmap, frequency of projects, existing projects and anticipated projects). The contextual information allows each vendor to better understand the business environment and therefore to differentiate their responses by demonstrating how they can address the specific issues facing the enterprise.
Ensure the Vendors Understand Your Overall Environment
The details of the environment that is being outsourced should be communicated in as much detail as possible within the RFP. Vendors need to understand the complexity of the environment to be able to develop a realistic proposal. How many system interfaces are there? What technology is each interface based on? Are the interfaces outbound, inbound or two-way? How stable is each system and interface? How large are the principle data tables? We frequently encounter the lament that “Vendor X just didn’t understand how complex our environment was” – with the blame being assigned to Vendor X rather than a weakness in the enterprise’s RFP and procurement process. Even if the enterprise believes that it has provided an exhaustive level of detail within the RFP, the procurement process service ought to include opportunities for each vendor to ask further questions. Depending upon the circumstance, written questions, conference calls or in-person workshops may be the most appropriate way to do this. In each case, a mechanism is required to ensure that any additional information shared by the enterprise with one vendor is shared equally with that vendor’s competitors.
Demonstrate the Importance of the Transition Period
Where vendors are competing against the incumbent, the RFP needs to address the transition period in detail. This emphasis is warranted in any case due to the criticality of the migration, which often sets the stage for the entire future relationship. Equally importantly, the emphasis on transition in the RFP sends a message to the non-incumbents (and to the incumbent) that the enterprise is seriously considering a scenario where the incumbent will be displaced. The RFP should address the projected transition timeline, roles and responsibilities during that period (for the enterprise, vendor and incumbent), the obligations on the incumbent, the level of enterprise support to be provided during the transition period, risk mitigation strategies and the performance requirements of the vendor during the transition period.
Clearly Define the Service Being Procured
When purchasing anything, let along a complex IT service, it’s important for the parties to understand what’s being purchased and what the expectations are from the vendor. Any lack of clarity or room for interpretation in the RFP will introduce a degree of uncertainty into the subsequent comparison of each vendor’s proposal and becomes a potential sticking point when negotiating the final deal. Worst case, the ambiguity will continue into the contract and only be addressed (and rarely in the enterprise’s favor) when the parties are required to interpret the term. The belief that “we can sort this out in negotiations with the selected vendor” has rarely proven to be true without significant incremental pain and effort.
Know What You Are Looking For
As a general practice, an RFP shouldn’t be used to gather information to help the enterprise decide on what it would like to procure or what the eventual service should look like. The RFP can certainly be used to gather additional information on aspects of the solution (such as what the vendor recommends to mitigate transition risk and what is current best practice in disaster recovery); but if the enterprise finds that it is asking questions that could have a significant impact on the type or scope of services being procured, the enterprise may consider gathering the additional data prior to issuing the RFP. This could be achieved by conducting a request for information (RFI) or inviting vendors in for working sessions to discuss potential solutions. Once clarity on the services to be procured has been attained, a definitive RFP for specific services can be issued.
Focus on Defining the Boundaries of the Service
While there are core service areas for which the vendor’s responsibility is obvious (such as database and application monitoring), the boundaries of the vendor’s responsibilities where ownership and accountability is potentially more ambiguous need to be very clearly defined. The majority of serious disputes in outsourcing contracts arise from a lack of clarity regarding scope. For this reason we generally recommend that the RFP be as explicit as possible. The procurement process can be thrown off-track if a vendor selection or down-selection is made without having the boundaries of service absolutely locked down. In most cases, the vendors will have significantly more experience with the potential pitfalls, loopholes and contractual gray areas than the enterprise and may use the ambiguity in the RFP to the detriment of the enterprise in contract negotiations. Examples of the boundary areas that require particular focus include:
- The definition of “updates” and “upgrades” (that are usually covered within the terms of the agreement) vs. “modifications” and “enhancements” (usually regarded as an additional discretionary activity that incurs additional cost).
- Roles and responsibilities in monitoring, procuring, applying and testing patches.
- The application of fixes for specific issues.
- The definition of discretionary activities.
Define the Performance Measurement Criteria
Closely tied to the performance of a service are the specifications that measure how the service is being performed. These performance specifications are generally captured via defined key performance indicators (KPIs) that form a service level agreement (SLA) or series of SLAs. A detailed description of how SLAs should be written is beyond the scope of this synopsis, but the general principles include these.
SLAs should address the most critical dimensions of the vendor’s service as defined by the enterprise. Rather than just the obvious specifications such as application availability, the enterprise may have specific concerns about other aspects of the service such as timely detection and notification of issues (for example, disk space limits), the successful completion of critical business transactions or even accurate service invoicing. The RFP should include the KPIs that are of interest to the enterprise and the associated performance that is required from the vendor.
While the SLA framework ought to address all key dimensions of service, it should also be manageable. The goal of the eventual agreement is to have the vendor perform the service contracted, rather than to focus on churning out reports. It should also be borne in mind that the proposed SLAs within the RFP provide guidance to the vendors regarding the aspects of service that are specifically important to the enterprise. As the number of SLAs increases, this message is diluted and the risk of inappropriate vendor focus increases.
The overall SLA framework should be constructed to reflect the enterprise’s underlying business needs. SLA priority is typically indicated by the severity of the financial penalty for contravention or a more rapid escalation towards further remedies (up to and including termination for cause). An SLA for availability should be emphasized over, for example, an SLA for the timely release of a new feature. If there is a particularly important period during which it is imperative that the SLAs are met (for example, month-end closing for financial systems), the SLAs should reflect that emphasis.
SLAs are designed to drive vendor behavior rather than as a money-making opportunity for the enterprise. With this in mind, the enterprise may consider non-monetary recourse rather than just punitive financial damages. Examples might include requiring the vendor to provide root cause analysis reports or the development and implementation of mitigation plans. It’s also recommended that the enterprise take advantage of the dynamics within the vendor organization, requiring progressively more senior vendor management to become involved in the root cause analysis and mitigation process for severe or sustained performance failure.
Taken to an extreme, the prospect of the CEO having to get on a plane to visit a particular client and explain the sustained failure of his or her company to meet its obligations will undoubtedly cause the account team to strive to rectify any non-performance. We have found that vendors are often more willing to agree to these non-monetary penalties than to escalating monetary damages that might threaten the vendor’s anticipated margin on the transaction.
Put Yourself in the Vendor’s Shoes
At some point in the process of developing the RFP document, the enterprise should read the RFP from the point of view of a vendor digesting the RFP for the first time. From this revised standpoint, it’s frequently surprising how many requirements require clarification (due to the use of undefined enterprise-specific terms, assumed vendor knowledge of internal processes or an incomplete description of technical requirements). An effective way to discover such issues is by providing the RFP to a technically competent, yet uninvolved third-party to review, such as an employee from another department.
Enable the Objective Evaluation of Vendor Responses
The result of the evaluation of vendor responses is typically a down-selection or selection. With this in mind, the RFP needs to be structured in a way that enables the vendors’ responses to be normalized, compared and ranked. Conversely, the enterprise must also be careful not to lock the vendors into an overly rigid response format that limits the ability of the vendors to differentiate themselves or limits their flexibility to propose a solution that provides the maximal benefit to the enterprise. The extent to which the structure of the vendors’ responses is controlled will vary from procurement to procurement, but we typically find that enterprises err towards providing vendors too much flexibility (“Describe your process for application patching”, rather than “This is our process – will you comply? If not, please explain why”). The results of an RFP that doesn’t sufficiently enable an “apples-to-apples” response comparison are generally either a down-selection made on incomplete data (with the attendant risks of a poor or subjective decision), or the need to send out subsequent RFP addendums, follow-ups and clarification sessions to attain the required normalization.
Establish Discrete Requirements
While there’s always room to ask vendors to describe their capabilities, the RFP should be built around a discrete series of requirements to which the vendor can provide a “yes/no/partial” response. A common approach is to provide very discrete requirements (for instance, “The vendor shall compile a monthly performance report that includes the following…”), and then provide the vendor a two-stage response format, where the first is a “Yes/No” response to whether it will meet the requirement in full, and the second is a field that allows the vendor to provide further description. The vendor is required to complete the description field for all requirements to which it doesn’t fully comply (in order to provide an alternative solution or explanation), but the vendor can also use the field to provide further relevant information regarding the way in which it would meet the requirement (or even to suggest a better way in which the goals of the requirement might be met). This RFP response format enables a quantitative analysis, while also allowing the vendors a degree of flexibility in their response.
Understand the Relative Importance of the Requirements
The most objective means of evaluating vendor responses is to perform quantitative analysis on the vendor responses. This requires that the relative importance of each requirement be established so that the score given by the enterprise to each vendor’s requirement response can be multiplied by an appropriate factor. The weighting of requirements is another topic that can’t be fully dealt with in an article of this length. A suggested approach to requirement weighting is summarized below, but many alternative approaches exist and may be more appropriate in different situations.
“Must-have” requirements are often addressed prior to the RFP in the vendor qualification phase of the procurement (such as does the vendor have previous experience with the application?); but if must-have requirements remain in the RFP, the enterprise should consider and, if necessary, address them separately from the general requirement scoring.
In order to simplify the process of weighting a single block of, for example, 200 requirements, the enterprise should use a two-tier approach, weighting each requirement area (business terms, pricing, service levels and operational processes) and then subsequently weighting each requirement within each area.
Large procurement decisions are often contentious. By ensuring that all stakeholder groups and project sponsors agree with the weighting, the enterprise will be in a position to deal objectively with any subsequent disagreements. The enterprise should ensure that requirement weighting is finalized prior to the receipt of RFP responses to maintain the objectivity of the proposal evaluation. Allowing requirement weights to change once vendor responses have been received can affect the objectivity of the process and could allow manipulation of the evaluation to achieve a pre-determined outcome.
Define the Proposal Pricing Format
A key dimension of almost any procurement is the pricing, which is generally evaluated against an anticipated demand-set for the services and incorporated into a total cost of ownership (TCO) model. For complex IT services that tend to be customized for each transaction, pricing is far from straightforward. The vendors will use diverse cost elements, bundle different services within sundry line items, and use differing definitions and assumptions. In a similar way to the delineation of other requirement areas in the RFP, the enterprise must develop its desired pricing format and key line items while trying to avoid curtailing the vendor’s ability to price its offer. With this in mind, the enterprise should allow some flexibility in each of its pricing tables for the vendor to insert additional charges and provide clarification. This flexibility should be coupled with a strong “totality of charges” provision (in other words, a statement that the vendor can’t invoice for charges not delineated in the vendor’s proposal) to ensure that the vendors disclose all rates and charges. Additional considerations when requesting pricing include these items:
The enterprise should be careful to define (either in the pricing table or by reference to specific sections of the RFP) exactly what is included within each of its proposed line items (for example, the word “Support” isn’t adequate to enable the vendor to price the support component of its service offering; the enterprise needs to include coverage times, response expectations, scope of the support provided, etc.)
The enterprise should request pricing at as granular a level as is reasonable. The granular pricing enables the enterprise to compare specific cost elements between vendors and therefore increases its leverage in negotiation. An additional benefit is that it allows the source of cost element outliers to be addressed and understood, such as whether the vendor is overpriced or is simply using erroneous assumptions.
For IT outsourcing contracts, the enterprise should put effort into understanding its projected requirement for discretionary hours (such as additional value-add services not contemplated in the core outsourcing agreement) from the vendor. This makes the TCO model more robust and, as importantly, these hours may be used as a further incentive to the vendor to drive improved pricing for the core services.
Achieve the Optimal Terms, Conditions, and Pricing in the Competitive Environment
The principle goal of a competitive procurement (and thus, of an RFP) is to use the competition to capture superior pricing, terms and conditions for the enterprise. As such, the RFP needs to be planned with the transition from RFP response to a draft contract in mind. This is another weakness encountered with insufficiently prescriptive RFPs; it takes a considerable amount of effort to take a vendor’s response to a “describe your approach toÉ”-type requirement and convert that response into an initial draft of the contractual term or condition. In many cases we have observed vendors retreat from their commitments as the contract is drafted and language is tightened; a good RFP should restrict the vendor’s ability to do so.
Make It Clear that RFP Responses Will Become Contractually Binding
The enterprise should clearly communicate in the RFP that the vendor’s responses will be used as the basis for any subsequent agreement for the services requested. Some enterprises simply include the RFP responses as an exhibit to the contract as a standard practice, while others state that by submitting a proposal, the vendor accepts that any or all terms from the RFP may be included in a future contract with the enterprise. At a minimum, the RFP should require that each vendor’s response include a declaration from an authorized representative that all claims made in its response are truthful.
Where Appropriate, Use Contract-ready Requirements in the RFP
The transition to a draft contract can be streamlined if the requirements are “contract-ready,” meaning that if a vendor indicates compliance with a particular requirement, then that is the language that will appear in the contract. In conjunction with the previous point, this approach can considerably accelerate the time required to move from RFP response to contract draft and reduces the opportunity for a vendor to renege or “clarify” its proposal commitments as the contract is drafted.
Consider Including the Master Services Agreement as Part of the RFP
The enterprise should consider including the proposed master services agreement (MSA) as part of the RFP (with a requirement that a red-lined MSA be returned as part of the vendor’s response). The RFP should make clear that any material change from the proposed MSA will be evaluated negatively when selecting a vendor or vendors with whom to enter further negotiations. A disadvantage is the additional time that the vendors will require in order to mobilize their legal resources and provide a considered response. However, we have found that any delay in the RFP response is more than offset by time gained in the ultimate sole-source negotiations due to the closure of many potentially contentious terms in the competitive phase. Further, we have found that vendors are more inclined to meet the enterprise’s initial terms when business is at stake, whereas they can be intractable when they know that they have effectively won the business. One further consideration is that in some circumstances (generally for smaller deals where the enterprise has commensurately less “leverage”) the vendor may even refuse to engage their legal team while the process is competitive. If such a response is anticipated, an intermediate approach is to abstract key terms from the draft MSA and include them as discrete requirements within a terms and conditions section of the RFP.
Avoid Putting Things Off Until Later
Procrastination is rarely a good thing, but in the procurement process it can seriously affect the resultant agreement. The enterprise should strive to ensure that the requirements in the RFP address all key considerations. As noted previously, the enterprise is unlikely to receive as favorable terms regarding any items that are addressed in a non-competitive environment.
Develop a Robust RFP
When used correctly, RFPs are an extremely powerful tool in the sourcing professional’s arsenal. However, RFPs that don’t adequately consider the goals and requirements of the sourcing process are a common cause of serious procurement issues. While RFP amendments, clarification rounds, vendor interviews and extensive negotiations can mitigate a weak initial RFP and put the procurement back on track, the overall procurement process will inevitably be more time consuming and the overall results less satisfactory than if the initial RFP had been sufficiently robust. We recommend that for complex sourcing events the RFP should be carefully drafted with particular consideration applied to the dynamics of the procurement and the RFP’s context in the overall sourcing activity. By so doing, your enterprise will maximize its chances of success through the overall process.
Useful Links
Pace Harmon
http://www.paceharmon.com
