No one can predict when a disruption will happen, nor what the impact will be, what resources will be available, or who might be available to execute the restoration plans. Yet that is the reality of Incident Management planning. So how do you plan for what you don’t know?
Scenarios are often used as planning tools to create structure. Yet real world experience has shown again and again that scenario-based plans are almost always useless in a real disaster; the disruption seldom matches the plan’s assumptions or follows the scenario script. So what’s a poor planner to do? Is there a better method in the madness?
Try reverse engineering. Just turn the problem around and define it differently. Armed with only what is known ATOD (At Time or Disaster, or Disruption, whichever you’d prefer), an Incident Response can be crafted – if the organization’s plans are crafted with a proper understanding of Incident Management requirements.
Impacted Assets: Rather than focus on the cause of the disruption, look at the effect. Any disruption will impact one or more asset – people are injured or unable to travel, a building is inaccessible, IT Services are unavailable or Suppliers are unable to deliver. Begin with the understanding that Business Continuity and Disaster Recovery Planning’s PRIMARY focus should be on restoring assets. Based on an impact assessment ATOD, identifying what assets are impacted allows Incident (or Crisis) Managers to activate the plans associated with those impacted assets. Multiple asset impacts may require activation of multiple plans. But focusing on impacted assets will make those choices clear.
Time Management: If the primary focus of Incident Management is restore impacted assets, the SECONDARY objective must be the restoration of those assets within a pre-defined Recovery Time Objective (RTO). From an Incident Management perspective, the Incident Managers’ responsibility is to ensure that the restoration tasks are on track and there are no show stoppers. To create that timetable, plans must include estimated durations for restoration tasks (which can be refined by exercising the plans).
Dependencies: The plan development process should include predecessor dependencies: what needs to be completed prior to initiating a specific task. This information, gathered from the subject matter experts during the planning process and subsequent testing, will enable Incident Managers to understand and manage the sequencing of restoration activities.
Finite Resources: The Plan development process should catalogue the skills required to complete each of the recovery tasks. By assigning skills required (rather than just individuals), Incident Managers will have the ability to identify available resources (and their associated skill-sets) and dynamically assign them where most needed. When multiple plans are activated, certain skills might be in high demand but short supply. Assigning or reassigning tasks by skill groups ensures that the Incident Managers use available resources in the most efficient manner – focusing on completion of the most critical tasks – to the greatest effect.
Information: ATOD, Incident Managers require information to make decisions: what is the causality chain, what are the upstream & downstream dependencies of impacted assets, what are the current operational capabilities, can processes be transferred, can systems be ‘failed’ over, what are the SLAs & regulatory compliance obligations and other current state information? The planning process must supply that information. If information is hidden inside individual plans – and not readily available to Incident Managers – it is of little use. Much of the information is already gathered in the planning process (the fact-gathering prior to creating plans). The data collected in the BIA can supply much of this information – if it is properly organized, maintained and supplemented with enterprise-wide dependency data.
Communication: When an incident occurs, there’s a sudden thirst for information from all sides: what is happening, what is the extent of the impact, what is being done, who is doing what, when will it be over? The need for information may come from many stakeholders: senior management, the board, operating managers, employees, emergency responders, regulators, customers, neighbors or the media. The plan development process should incorporate a communication, collaboration and reporting framework – because two-way communication is vital to successful Incident Management. Lack of communication (either because you can’t or you don’t) will always lead to failure.
Knowing what has happened, understanding the implications of those impacts, knowing what needs to get done, understanding how quickly operations have to be restored and knowing what resources are available are all core Incident Management requirements. The Business Continuity Planning & Plan development processes should work toward assuring those requirements are met.
Down in the trenches, Incident Management is a juggling act of time-management, resource management, critical-path optimization and project management – having the right resources available at the right time, in the right place, to meet the right needs. Gearing Business Continuity Planning to meet those requirements will ensure that any disruption can be successfully overcome.
See, there can be method in the madness.
Related blog:
Incident Management 103: Communications
