Business continuity management has evolved into a specialized discipline, but you don’t need a team of specialists to create and manage your BCM program. With a little help, and an understanding of these 14 fundamentals, you can build and manage your BCM program easier than you thought, and at a much lower cost.

1. BCM is risk management, not insurance: BCM ensures that business processes are appropriately resilient to disruptions, or are recoverable at an appropriate time. Insurance is a grudge purchase. You buy as little as you need and accept as many risks as tolerable. If nothing goes wrong, you feel like you wasted your money. Don’t “sell” your BCM program as insurance. Nobody wants to buy that. Sell the ancillary benefits of BCM, i.e., service delivery, compliance. Seek strategic partners and leverage their resources.

2. Government is a business that demands continuity: Every ministry, division or department is actually a collection of associated business processes. Think of services as products and citizens as clients. Service commitments made to citizens are taken very seriously. Just as in any business, your BCM program will receive support if it can ensure the continued delivery of products to clients.

3. Write business continuity plans at the process level: Write a plan for each business process. When a disruption occurs, you can quickly determine which processes are affected and you only need to implement those specific BC plans.

4. BC plans are not cause-specific: Unlike emergency response plans, which address the cause of business disruptions, business continuity plans address the effect of business disruptions. BCM identifies your business processes, their dependencies, and their time-criticality. BC plans can be used for all types of business disruptions, including staff loss, facility damage, logistics interruptions, or technology failures.

5. Specialized BCM tools are not necessary: Tools do not write plans – people write plans. Some of the most effective BC plans use MS Word or Excel. With some basic guidance, your current professional staff can create and manage your BC program with the tools you already have.

6. Quick recovery is not the goal: Quick recovery is typically more expensive than slow recovery. A recovery time objective (RTO) should be a balance between the diminishing cost of recovery and the escalating cost (impact) of the outage.

7. Don’t label processes as “critical” or “non-critical”: “Critical” doesn’t tell you how long you can tolerate a disruption, and nobody wants to be “non-critical.” You need to know what it costs for a process to be out over various periods. This “time-criticality” will drive the RTOs.

8. Don’t ask about RTO – conduct a Business Impact Analysis (BIA): Your doctor would never prescribe treatment without conducting an examination, and you should never write a business continuity plan until you have completed a BIA. The three main steps are:

  • Identify dependencies upon facilities, staffing, material, equipment and technology;
  • Collect and analyze the impact of disruptions in categories that are meaningful to your organization; and
  • Document objective impact data for each impact category in various time intervals and present it graphically in an impact matrix so senior management can make the RTO decisions.

9. Keep it simple: A BIA report should be a dashboard to support decision-making. A BC plan should only contain instructions for use at time of disruption; no verbiage about why the plan is important, or how it was developed.

10. BC planners should not write BC plans: The people closest to the business process must write the BC plans. BC planners should organize, manage and facilitate the process.

11. Don’t test your plans, exercise them: Exercises train people and focus on what can be improved. The only way to “fail” an exercise is to fail to find ways to improve.

12. Information technology and recovery: IT Disaster Recovery Planning (DRP) is a component of business continuity planning. Technology is just another type of business dependency and it only exists to support business processes. Plan to recover only the technology that is required to support the business processes, and time the recovery to support the processes’ RTOs.

13. BC plans need assumptions: People will ask if they are planning for a minor incident or a total loss. Provide realistic, management-approved planning assumptions for facilities, staffing, material, equipment and technology. Remember, BC planning is not cause-specific so don’t provide planning assumptions such as “fire” or “flood.” Assumptions should indicate the effect, not the cause.

14. Keep the plans alive: Decide how often you want to exercise and update your plans. Also, consider an update whenever a significant change occurs that would affect either an RTO or the availability of key dependencies.