Integrating BCP Into the IT Project Life Cycle

To maintain customer confidence and financial stability in the event of a disaster, BCP must be addressed at the beginning of an IT project. Here, Gartner describes how BCP can be integrated into the IT project life cycle.

Executives often balk at the expense of IT projects, and deferring investment in business continuity planning (BCP) may make them more palatable. Those enterprises that have scrambled to get e-business initiatives up and running to keep up with the competition and to meet customers’ expectations have viewed BCP as a delay, if it is considered at all. Often, on-site redundancy and day-to-day availability requirements are considered; rarely is a multicomponent outage or a full site outage addressed during the project. This level of planning is often done after a system has been designed or implemented. Bad publicity and loss of customer confidence can cost an enterprise far more in the long run than the extra time and resources spent on planning for BCP from the beginning of the IT project.

We recommend that enterprises integrate BCP into the eight phases of the IT project life cycle (PLC):

1.     Business requirements

2.     System architecture

3.     System design

4.     Construction

5.     Testing

6.     Implementation

7.     Post-implementation

8.     Retirement

The deliverables from each phase are used as input to each subsequent phase. The activities of each phase are executed by the members of the IT project team — depending on the goal of each phase, a subset or full contingent of participants are required. See Figure 1 for a description of each participant’s responsibilities.

Figure 1

BCP Roles and Responsibilities

Source: Gartner Research

This Research Note is written from an IT project perspective, and therefore does not address all BCP activities, such as the creation of a business continuity policy, business continuity organization, crisis management team or personnel evacuation/management plans. For a model that addresses all BCP activities, refer to the Business Continuity Planning Model by DRJ.com at www.drj.com. However, all such components should be reviewed and updated if required to meet the business continuity requirements of the systems being developed by the IT project.

Business Requirements: The goal of the first phase of the PLC is for business management to identify the high-level, business-related continuity requirements for the new IT system(s). Activities to be completed during this first PLC phase include:

• Business impact analysis (BIA)
• Risk analysis (RA) for the business as a result of using the new system(s)
• The recovery time objective (RTO)
• Recovery point objective (RPO)
• A review of the impact of the new system(s) on existing business processes and systems. This review will ensure that the business continuity requirements can be supported throughout the entire processing stream. Changes may be required in supporting or interdependent business processes and systems that will mean additional design, development, implementation and funding not anticipated when viewed only from the new system(s) perspective.

In an example of business continuity requirements, the system will be used by front-office personnel such as traders and trader assistants for trade entry, back-office operations for execution and risk management for credit and risk assessment. It must be available from Sunday evening 7 p.m. EST through Friday 9 p.m. EST, because the trading book is global. The system must be available within one hour for a single component outage and within four hours of an outage, with no loss of data, for a multicomponent or site outage; therefore, the system must be designed for no single point of failure.

In addition to business management, often referred to as the information owner, other participants in BCP for this first PLC phase include: the Infrastructure and Application Development (IAD) team, the business continuity/disaster recovery coordinator(s), the cyber-incident response team (CIRT) and the audit department.

System Architecture: The goal of the second phase of the PLC is to establish a system and business process architecture that supports the business continuity requirements for the new system(s), interdependent systems and associated business processes. In the second phase of the PLC, the following activities are completed:

• Scenario(s) under which the plan will be executed
• Business continuity strategy alternatives development
• Cost/benefit analysis of each alternative
• Selection of the best business continuity strategy

Participants in the second PLC phase include the information owner, the IAD team, IT operations, the business continuity/disaster recovery coordinator(s) and the CIRT.

System Design: The third phase of the PLC will draw upon all participants of the BCP process with the goal of developing a detailed design and set of specifications for the system(s) in support of the business continuity requirements for the new system(s), as well as supporting/interdependent business processes and systems. The recovery of the system(s) after the emergency event, as well as its restoration to the production site, must be considered. Activities to be completed in this third PLC phase include:

• Business continuity/disaster recovery team(s)/responsibilities identification, including the party responsible for maintaining the business continuity plan itself
• Technical components/architecture design
• Business processes design
• Escalation, notification and plan activation strategy
• Vital records/off-site storage program
• High-level test strategy

Construction: In this step, the enterprise builds the disaster recovery and business continuity plans and technical components in support of the business continuity requirements. Activities to be completed in this fourth PLC phase include:

• Emergency response procedures
• Personnel call trees
• Technical disaster recovery infrastructure, including systems and telecommunications
• Recovery and restoration procedures
• Vendor selection and contracts for purchased recovery services (e.g., outsourced recovery service providers or off-site storage)
• Detailed business continuity test plan

All business continuity participants should be involved in the activities of this fourth PLC phase.

Testing: The fifth PLC phase is one of the most important phases in the overall IT project — ensuring that what was designed and built meets the RTO/RPO as defined by the business in the first phase. Testing also ensures that the business continuity/disaster recovery team(s) is trained in the recovery of the system(s). Using the business continuity test plan, activities to be completed in this fifth PLC phase include:

• Recovery and restoration procedures walk-through, i.e., a tabletop test
• Emergency response procedures execution
• Personnel call tree execution
• Recovery and restoration procedures execution, where feasible. If the IT project and associated new systems are mission-critical, a complete execution of the business continuity plan may be warranted. If not feasible, then a date must be selected, no more than three months after the implementation date, when the business continuity plans will be tested — separately or as part of a larger business continuity test.
• Immediately after the test, a report must be issued to the information owner regarding all areas where the business continuity strategy does not meet the requirements. A plan must be developed that identifies who is responsible for closing the gap, and by when. It must be noted in this report the date when the gap resolution will be tested, if applicable.

It is important to consider the impact on customers during the test — you might include them as well as external interdependencies to ensure that the entire business process can be successfully recovered.

Implementation: During this sixth PLC phase, change management promotes application software to production, and IT infrastructure personnel implement hardware and telecommunications into the production environment. It is often prudent to perform a second test of the disaster recovery IT infrastructure after implementation, especially when using an outside service provider for IT operations.

Maintenance: All major changes to the system(s) must include a review of the business continuity strategy and plans to ensure that they still meet the requirements as defined by the information owner. Such changes must cycle through all BCP activities in each PLC phase through implementation to ensure that the system(s) will be recoverable.

Retirement:     When the system(s) is no longer required, the takedown of the disaster recovery and business continuity environment must be completed. Activities to be completed in this last PLC phase include:

• Disablement of the disaster recovery IT infrastructure
• Destruction of emergency response procedures, recovery and restoration procedures, and personnel call trees
• Cancellation of all vendor contracts
• Destruction of off-site storage, according to regulatory retention requirements. Not all off-site storage can be destroyed when no longer needed for current production business processing — those controlled by regulatory agencies such as revenue/tax agencies must be available for restoration purposes in the event of a regulatory or legal dispute. Confer with the legal department to determine the long-term retention requirements for your industry and enterprise.

Enterprises that simply add BCP to system(s) already designed or implemented expose themselves to unnecessary risks ranging from the minor customer annoyance to the loss of revenue from customers going to a competitor to outright stoppage of its business. Enterprises that incorporate BCP into system(s) from the beginning will enjoy a competitive advantage that will manifest itself in fewer disruptions to enterprise operations, and in greater confidence from customers, partners and suppliers.

This research is part of a broader article consisting of a number of contemporaneously produced pieces. See COM-13-6392 on www.gartner.com for an overview of the article.

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