People ask us all the time what to put into an outsourcing RFP. Top dollar consulting companies such as TPI, EquaTerra, and Everest Group all have different templates and processes. We believe that the RFP is the principle point in time where the company establishes their negotiation leverage while enforcing enough structure to permit an apples to apples comparison of vendors. Here’s what we think are the important contents of the RFP:

RFP Ground Rules

The rules pertaining to the RPF process itself, including submission timelines, communication guidelines, and response guidelines. If you haven’t read a book on 3-D Negotiation, read one – this is where we establish our negotiation leverage and prevent vendors from using sidebar conversations that create an un-balanced playing field and subjective evaluations. Vendors who break the rules are eliminated from the evaluation process. Yes, we’ve done it, and we find this to be incredibly important to the integrity of the decision-making process – plus, its important to consider the vendors who intentionally break the relatively simple RFP rules as enormous liabilities when you’re in the vendor governance stage and managing the vendor. It’s tough love, but other vendors learn from this lesson and take us seriously. Plus, when we include the vendor in another evaluation they follow the rules better the next time.

Statement of Work (SOW)

We’ll go into the specifics in a separate article because its so important, but the SOW essentially contains the high level business requirements, technical requirements, transaction volumes, and clearly identified responsibilities of the vendor and the company.

Service Level Agreements (SLAs)

Much has been written the subject at a high level, and we’ll elaborate more on this in a future article, but SLAs are the defined performance requirements of the program, including turnaround or cycle time, quality expectations, backlog expectations, and technology up-time requirements. You should also include definitions of vendor excused misses, so that the vendors understand how to evaluate the risk of the program, as well as provide specific numbers behind the relative cost of missing SLAs. Finally, the SLAs should indicate when they become effective, so the vendor can include learning curves in their pricing estimates. Above all, everything should be obtainable – unless you want vendors to walk away.

Pricing Model

Provide a template for the vendors to propose their pricing. If you don’t use a template, you’ll get back pricing that cannot be compared to other vendors’ pricing. Also, require the vendor to price based on your requirements, not based on their requirements or feedback. We’ve gleaned a tremendous amount from our experience in this area, and we’ll share more with you in the future.

Contract

Outsourcing contract negotiations are lengthy, and you might as well start on the right foot by providing the vendor something to price against. We use a very detailed contract.

Qualitative Questions

Here’s the area where you ask qualitative questions, including requests for company financials, proposed implementation plans, proposed vendor management organizational models, the bios of the key vendor employees that will be proposed to manage and control the operation, and IT details. Provide a specific area for responses and ask vendors to provide attachments separately. Nothing disrupts an evaluation more than having vendors sculpt their own graphic heavy, lengthy proposal formats leaving the evaluation team to search for the answers to their questions.

Vendor End-to-End Proposal

Here’s where you let the vendors’ creative juices flow as they describe where and exactly how they will meet your requirements. They should include pictures, flowcharts, and graphics in an attempt to explain how they will provide a seamless solution that will meet your requirements.

Exceptions to the Requirements

Here’s the dirty little secret to the RFP process that will shorten your timelines and give you leverage in the negotiations. Prohibit the vendor from making any assumptions in their solution that differ or extend the ones you’ve given, and ask the vendors to 1) indicate where their solution will fail to meet the requirements in any of the above documents (including the contract) and 2) ask the vendor to provide alternative language. Here’s your opportunity to create apple-to-apple comparisons of vendor solutions, while preventing the vendors from stating in contract negotiations, “Our proposal didn’t include that, but we can surely do it for more money or at a later time.” It’s also the best chance you have of clearly identifying which requirements the vendors cannot make, making it easy for you to eliminate vendors early for failing to provide solutions. We have terminated contract negotiations and declared proposals non-responsive (which means we wont evaluate the proposal) when vendors fail to follow the directions here. Usually, the vendors drop all exceptions immediately, and negotiations resume. Sometimes, we’ll give the vendor 36 hours to remedy their error. You’re in the driver seat here…

Do you have comments? Do you structure your written RFPs differently? Do you have suggestions on better RFP content? Add a comment and start a discussion!