System Transformation Portal

Home    Site Map
About Tactical Strategy Group

Business Architecture Transformation    IT Architecture Transformation  
Book Reviews
   Transformation Solutions    Events

 


Introduction Organization Preparations Risk Analysis Contingency Plans Crisis Planning Team Appendix A Appendix B Appendix C Appendix D Appendix E

Contingency Planning Methodology

IV.    Contingency Planning Process

A. Assess existing contingency plans for applicability towards risks.

Many business units have existing contingency plans due to other potential hazards such as a loss of power, environmental threats, etc. Earlier in the Preparation section of this workbook you were asked to determine if your business unit had such contingency plans. Now is the time to review those plans to see if the business unit requiring contingency plans can adopt them.

As you review each existing contingency plan, make a note of which business processes the plan covers. Also, note which business function, upstream and downstream, it could affect. This cross-referencing is simply an intermediate step and requires no formal documentation. A quick means for cross-referencing is:

  • print a list of business processes from the forms or database
  • attach a duplicate of this list to each contingency plan
  • indicate on each attachment which business processes relate to the contingency plan

Deliverables:
If there are existing contingency plans, a cross-referenced of existing contingency plans to business processes.

B. Develop an outline for every contingency plan and action item within each contingency plan.

Building, implementing and managing a contingency plan requires resources just as any other project. Therefore, like other projects, it is best to develop a quick outline (proposal) for each contingency plan describing the risks the plan addresses, how it addresses the risks, etc., then seek approval to build each plan.

The term "contingency action" is mentioned in the task title to remind analysts that taking action to minimize risks is just as much a part of contingency planning as developing a plan to react to circumstances. For instance, many manufacturing companies that use Just In Time inventory practices are stocking up on vital supplies to prevent disruption of their supply chain dependent business. This requires them to secure warehouse space, transportation to and from the new inventory locations, etc. All these actions are proactive rather than waiting until a critical supplier informs them of a problem.

Here are some considerations when defining contingency plans:

1. Have further discussion with team members to determine confidence in corrective measures already taken and what could practically be added.

2. Further contact with vendor/customer to determine contingency measures they may be taking.

3. Consider what engineering or other actions may be practical to reduce or eliminate risk.

4. Consider and include measures to reduce, eliminate, or compensate for damage, such as:

  • insurance
  • standby personnel
  • standby or retained outside resources
  • hedges
  • temporary operational changes

5. Review all planned actions with respect to cost, practicality, time to complete, secondary benefits, undesirable side effects, or other factors.

A suggested template for a contingency plan outline is shown in Appendix C of this workbook. The following list describes each field on the template:

  • A unique identification number assigned to each contingency plan. Note that the database tool does not allow duplicates, so each contingency plan requires a unique number.
  • A name for each contingency plan.
  • The business function ID and name that the plan applies.
  • The business function ID and name that the business function is part of.
  • A brief description of the risks or problems that the plan addresses.
  • Indicate the probability of the failure occurring as recorded in the prior section on risk analysis.
  • Indicate the criticality of each risk type based on rating factors assigned in the prior section on risk analysis.
  • A brief description of how the business function is to operate while the plan is in effect. Note that this is not a description of how to fix the problem. The purpose of this plan is to describe how to continue business in light of the problems. Fixing the problem that caused the contingency plan to go into effect is a separate (but related) plan that can be included in the plans for each system, interface and 3rd party.
  • A clear definition of the failure scenario that will cause this plan to be implemented. This is referred to as a trigger. Most triggers are either a date or condition. For instance, you might contract with a new/backup supplier if your primary supplier cannot guarantee that they can meet your demands by a certain date or that you will immediately shut down an operation if a monitoring system indicates dangerous levels.
  • A clear definition of the condition that will allow you to retract a contingency plan. Same as above except the trigger is focused on eliminating the contingency plan. For instance, the operation that was shut down is to be brought back up after manual review and remediation of the problem causing the shut down.
  • Estimates of the costs to build, implement, manage, and retire the plan.
  • A high level summary of the plan itself. Be sure to include the tasks, responsible parties for each task and estimated start dates or conditions for each task in this summary.
  • Optional: It is common to include a summary plan describing how the problem will be fixed while the contingency plan is in effect. For instance, your plan describes that an operation is to be shut down due to a malfunctioning system. This optional technical plan describes how the system will be fixed while your operations are down.

How to record:

Forms:
Obtain a copy of the Functional Problem Scenario - Contingency Planning form and record contingency plan information. There is a Functional Problem Scenario Contingency Planning form for a Business Function and a Technical / Tactical Problem Scenario Contingency Planning form for systems, interfaces and 3rd parties. The column labeled Contingency Type allows you to indicate if the contingency plan is for a system, interface or 3rd party.

Database:   
Open the Access database named Contplan.mdb, Click on the 'Contingency Plan Form' and record your contingency plan information. Be sure to relate the plan to the proper business function. The field labeled Contingency Type allows you to indicate what the contingency plan is for, continuing business function, system, interface or 3rd party.

Best Source:
Existing Contingency Plans, Facilitated session with key personnel and management, Business Leaders, Network with like business functions in other companies, User Group publications.

Other Possible Sources:
Appendix E provides some very general synopses to provoke your thoughts.

Deliverables:
A list of contingency plan outlines for the business functions that merit contingency plans.

C. Propose, prioritize and obtain approval for each new contingency plan and action.

Business unit management is ultimately responsible for the business unit including insuring that it is properly prepared. This means that they will be responsible for approving all contingency plans and the tasks involved in building your contingency plans. Meet with the Business Leader to review the contingency plan outlines. Document BOTH the contingency plans to be built as well as those that you will not pursue any farther. Clearly document the rational behind not pursuing a contingency plan.

Update your contingency planning project plan(s) to include a task to build and document each approved contingency plan. Be sure to assign who will be responsible for each task (contingency plan).

How to record:

Forms:   
No need to record rejected plans.

Database:   
Open the Access database named Contplan.mdb. Click on the 'Contingency Plan Form' and record the approval or rejection for each contingency plan. The database is for managing your contingency plans not documenting them. Therefore, you might consider deleting all the rejected contingency plans or placing the term 'Rejected' in the contingency plan name for each rejected plan.

Deliverables:
A list of accepted and rejected contingency plans for all business functions. An updated contingency planning project plan that includes the tasks required to build, document, and manage your approved contingency plans.

D. Build and document the new contingency plans and actions.

Building your actual contingency plans requires you to expand your contingency plan outlines to include the necessary information to implement, retract, and manage each contingency plan as well as managing the building process itself (project management).

When detailing a contingency plan starting from its outline, consider the following:

  • Expand the project plan that describes the tasks, responsibilities and scheduling information (dates) for the contingency plan itself. Review the business processes involved with the contingency plan to determine what actions (tasks) are required to continue each vital process.
  • Include a task to document how executives, management and staff will operate under this contingency plan.
  • Document how long the business function can operate under the contingency plan.
  • Validate that all tasks within the plan will and can be carried out by the parties responsible for each task.
  • Clearly define who has the authority to implement and retract the contingency plan.
  • Discuss the plans with the upstream and downstream business function Contingency Planning Team Leader. This is to insure that various contingency plans can coexist. Pay special attention to the resources (staff, instruments, facilities, and such) involved with their contingency plans. Make sure there are no resource conflicts created by each other's contingency plans.
  • Review the list of questions shown later in this workbook in the 'Crisis Management Planning' section for ideas on what needs to be covered by your contingency plan.

How to record:

Forms:
Used for reference purposes only.

Database:
Update where plans change or are expanded. Use reporting features to print comprehensive plans for each business unit, function, system, interface and third party.

Deliverables:
A fully documented set of contingency plans for each business function within your business unit.

E. Track, Implement and Retract contingency plans and actions.

Implementing and retracting a contingency plan requires that you monitor daily operations for the triggers (dates and conditions) for each contingency plan. Incorporate each contingency plan trigger into your daily scheduling and operation management procedures.

Deliverables: None.

 
Send mail to webmaster@systemtransformation.com with questions or comments about this web site. 
Trouble printing this page? Click here for printing instructions.
Copyright © 1999 - 2008 Tactical Strategy Group, Inc. Last modified: May 21, 2008