Building an RFP for Business Continuity Services

We outline what needs to go into an RFP when assessing potential providers of BC and disaster recovery services.

We outline a framework for developing RFPs for BC services, which are becoming increasingly complex.

Mission and scope: The RFP is used to detail the solution an enterprise wants to implement, and to evaluate vendor proposals in a systematic and consistent manner (see Figure 1). The RFP is not used to gain education on potential solutions or vendors; this is achieved through an RFI. The RFP is used to help qualify the ESP and the ESP’s proposal. RFPs should be detailed, and therefore are long. While the RFP is part of the legal document trail, nothing is final until a contract is negotiated and signed.

Control and distribution: There should be extensive internal reviews and approvals of RFPs (see Note 1). Copies of all RFPs should be maintained in a central location for reference. Version control is important as a formal means of document tracking, and ensures that users and vendors are working from the same document. Distribution should be selective and based on market research and an RFI process. Only vendors that can provide a quality solution should be included. The number of vendors should be limited to three.

Position in the acquisition process: The RFP should be sent out only after the BC plan contains sufficient detail to enable the detailed specification of requirements (see Note 2), or, at the very least, when there is a clear idea about what needs recovering and when. Vendor-proposal evaluation and additional investigation (e.g., calling references and performing financial due diligence) will determine which ESP’s solution will be selected. This information is then put into the recommendation. Below is a basic RFP checklist:

• Executive summary (one-page maximum)
• Introduction: 1) Background on the corporation and/or business division. 2) Scope of services being requested, e.g., consulting, hot-site services. 3) Background on the BC process including current status, existing roles and teams. 4) Statement on the confidentiality of information.
• Overview: 1) Statement of mission/vision. 2) Statement of business objectives. 3) Statement of scope in terms of which business processes, business units, applications, packages, geographies and technology platforms are being covered. 4) Role of the BC vendor.
• Project schedule: 1) Vendor RFP question deadline. 2) Vendor analysis meeting (optional). 3) Proposal due date. Vendors need four weeks to respond well to anything other than simple configurations. Less time results in poorer, less-innovative and probably more-costly solutions. 4) Vendor demonstration day or recovery site visit (if appropriate). 5) Contract negotiation. 6) Final decision. 7) Proposed implementation start.
• Business requirements: 1) Detailed business requirements including RTOs and RPOs for each business process (see Note 3). 2) Detailed technical requirements, describing the applications, platforms and communications requirements for each business process in terms of the normal operational configuration. A description of dependencies. 3) A recovery time line outlining how resource requirements change during at least the first 14 days (see Note 4). 4) Invite the vendor to propose a validation program, but include a best guess at test-scheduling requirements (see Note 5). 5) Implementation, training, start-up and maintenance requirements. 6) Project management and service-level-reporting requirements. 7) Performance criteria for success of solution. 8) Indication of performance penalties.

• Proposal requirements: 1) Contents of proposal, including contractual terms and conditions, references and names of key ESP personnel (recommended where consulting work will be included). 2) Proposal format and number of copies (insist that the vendor follows format). 3) Length of contract (see Note 6). 4) Guidelines on how to present costs; this should include a requirement that pricing is broken down (see Note 7). 5) Requirements for "proof of concept." 6) Documents to establish vendor financial stability. 7) Who to contact with questions and where to send proposals. 8) Selection criteria (see Note 8).

• Technical appendices: 1) Overview schematics of the current technical environment. Include planned changes. 2) Lists of existing hardware needing coverage by the proposal.

A well-planned and crafted RFP will result in a much more efficient and competitive procurement process, which in turn will result in saving time and money. Cutting corners upfront results in time wasted downstream.

This research is part of a set of related research pieces. See AV-14-5338 for an overview.