The first and often unanswered question I have when reviewing an RFP is…what is this thing?
I know that putting together an RFP is a ton of work and a task that few are pleased to take on or have assigned. But if you’re going to do it, if you have to do it, please do it right. There are so many unintended consequences that follow from poorly drafted RFPs, many of them resulting in nightmare scenarios for respondents and reviewers alike. Here’s my suggestion for how an RFP for technical services should be constructed.
- I. Project Background: Start with a SUCCINCT (e.g. no more than 2 paragraph) description of the context / background for the project.
- II. Purpose of Project/RFP: This should lead to a brief and well-defined description of II – 1) the purpose / objectives of the project, II-2) the deliverables that the organization expects at the completion of the project II-3) a description of where the organization hopes to be by the end of it and how this compares to current status.
- III. Resources Available and Sought: identify the resources/expertise that the organization intends to make available to the project and identify the resources, type of expertise, and specific services the organization seeks from a consultant (best if these are presented in a numbered list, because then respondents can methodically speak to their capabilities in each identified area and your review committee can just check through and score the strength of the response for each category of service/expertise.
- IV. Technical Environment, Standards, and Requirements: Characterize the environment within which the consultant will be implementing the solution and provide information about any core software standards or IT requirements that must guide the designed and delivered solution. No need to go into exhausting/ive detail, but there should be enough here to answer questions about operating systems, business systems they may need to integrate with, browsers they will support, different operating platforms they will need to target and support. It’s good to include things that are not necessarily part of the scope of this project if they will be taken up with anticipated future work (e.g. if you are going to go mobile in Phase 2, then include information about any standard devices/tools that should be anticipated in Phase I solution design).
- V-I. Cover Letter: Can they write? When given a page to express themselves, do they speak to you and indicate careful consideration of what this is all about? Some think of this as fluff, but it can be a good filter about whether you’re about to get a bunch of regurge or if a respondent is serious about giving you what your asking for.
- V-II. Consultant Expertise: Ask respondents to provide a) brief firm background (not a bad idea to define brief) and to b) detailed company experience relevant to the RFP expertise requirements. For section b above, you should ask for specific project examples that demonstrate the firm’s experience and capabilities providing services relevant to the specified RFP requirements. Ask for references for each of these projects. Advice: you may want to specify a cap # of project examples (3-5) or a page limit on this section and the total response (possibly excluding parts, e.g. resumes?) so you get shorter sweeter responses and don’t have as much marketing sludge to wade through.
- V – III. Proposed project team: Request resumes from key players. You may want to specify certain roles you expect to be filled if you have very specific expectations about what roles will be necessary to match your preferred methods of work (e.g. project manager, technical lead, key developers, account manager, etc).
- V – IV. Proposed Approach (Option I): IF your organization has a standardized approach for how you prefer or are comfortable proceeding through the type of work described, define that approach in general terms (e.g. tasks, phases) and ask respondents to briefly address how they will conform to and satisfy your approach based on their standard practices and experience. This will save lots of time on the respondents’ side that would be wasted describing an approach that likely differs from what you want, and it will make life easier for the reviewers who will otherwise have to try to cross-interpret how closely the proposed method could be adapted to what they really want and didn’t ask for explicitly.
- V-V. Proposed Approach (Option 2): IF your organization doesn’t feel it necessary to closely prescribe the approach and/or you think that defining a good approach is part of the expert consulting you seek, then leave the requirements for this more open-ended to learn more about how the consultant envisions work with your team to help you in attaining your objectives. This can potentially be one of the more illuminating and meaningful parts of the response, and may illustrate how much creativity, consideration, or reuse of tired boilerplate a respondent applied to your defined needs and goals. But again, don’t waste your time and theirs if you already know how you want to run the project and defining the approach to work is not a valued part of the help you are seeking.
- V-VI. Calendar: Ask for a high level calendar that lines out proposed major work/tasks/phases. This is always easier to deal with if it assumes an abstract timeline (month 1, week 1, week 2…verses February 12, March 13th…), and we recommend asking for it that way unless you are truly serious about a specific start and finish date (...really?).
- V-VII. Cost Proposal: Couple options here. If you know enough about what you are after and what it “should” cost in the marketplace (rare), you may be best served by specifying that the total budget allocation is $xx. For respondents, this can be extremely helpful to: -> allow them to determine if they think you are sane and whether they are interested in responding —> allow them to refine their conception of and approach to task work in a manner that is conscious of the available resources. Think of your RFP as a tool to get what you need. If you know you’ve got a fairly absolute budget, then specifying what it is is going to help you and the respondents cut to the chase. They will still understand that they are competing for your work and will not necessarily max you out — and you will be able to determine “how much can we eat” for $xx. On the other hand, if you don’t know what this should cost, are not totally restricted to absolute figures, or need to see what you get back in the way of responses before attaching a more specific financial figure to the project, then use the RFP as a way of helping to gather information about what you can get for what you may spend. However, keep in mind that the more specific you are, the more meaningful responses you are likely to get. If you can at least say this is envisioned as a 6-9 month project with a max budget not to exceed $xxx, then you will do everyone a big favor. It’s not uncommon for responses to range from 10’s of k’s to $100’s of k’s (or worse) when the RFP issuer is not sufficiently clear and directive. That’s inevitably a huge waste of time for all parties. In addition to proposed costs by phases, you may also do well to ask for current hourly rates by role. It’s not unusual to go hourly here and there, and it will be useful to know and have established in advance what that will mean to your organization in terms of costs.
- V-VIII. Subcontractors and Encouragement of Disadvantaged Business. Minority, Women-Owned, or Emerging Small Business. IF diversity or encouragement of disadvantaged businesses is part of your organization’s requirements or goals, then ask respondents to identify themselves or any of their subs who help satisfy these requirements. Also, make sure you require that they identify and subcontractors who are part of the proposal team and briefly indicate whether they have worked together on a past project.
- V-VII. Detail stuff. Make sure you ask respondents to identify things like: who is authorized to negotiate any contract that may result from response, period of validity for proposal/rates/etc, the fact that you will need to approve alternate “key players” who the selected consultant may switch due to staff changes or allocation at the time of the project. You should also specify up front what insurance will be required and what limits, and provide a sample contract assuming you plan to use your own paper for the job.
- VI. Delivery format and rules. This should come up above section V, but make sure you specify how you want submissions provided. These can kill many trees and drain lots of oil wells if consultants are left to dress them all up. Unless there is a strong need to get hardcopy, ask for digital submissions in pdf format that your review team can print off if and as needed. If you ask for hardcopy make sure you ask that it be all recyclable material.