Why Your Plan Won’t Work (and How to Fix that)

Recently, Andy Osborne, one of the Business Continuity Management industry’s most prolific writers, published a blog lamenting the common practice of writing BC Plans to please auditors – rather than to function as guides for Recovery.

Many Business Continuity Plans (BCP’s) are written to comply with Regulatory requirements (FFIEC, NERC, ISO22301, NFPA, etc.).  Plans are often crammed full of information to meet audit requirements and fail to address the steps needed by Recovery Teams to take action.

I wholeheartedly agree with his premise.  In fact, I’d go one step further:

Not only do many plans lack directions for action, many other Plans contain ‘procedures’ that are neither useful nor effective.  The reasons behind those failures are often a function of who has written the Plan.

Time and time again I’ve worked with (generally large) organizations in which the BCM staff writes all the BCP’s – presumably with the assistance of the business process or function “owner” who will someday be charged with executing that BCP.  Such arrangements are justified by the theory that “owners” don’t have the time or expertise to write them themselves.

That business model enables the conduct of large numbers of BIA’s, Plans and Exercises efficiently.  But there are three ingredients in that model that lead toward the type of ‘compliant’ Plans Andy’s article complains about.

First, such plans must be based on a highly structured ‘template’.  How else can an individual meet the goal of conducting annual BIA’s, Plan updates and exercises for 5, 10, 20 business units every year?  That template should have two goals:  meeting regulatory compliance or adherence to a standard (or even multiple standards), and providing the business unit with well-conceived actions to take in the event of an actual disruption.

Second, those BCM staff ‘planners’ often don’t have intimate experience necessary to fully understand how the underlying processes function on a day-to-day basis – making it difficult to understand what may be necessary to recovery those processes.  They rely on the assistance of the process “owners”.

And that is the third flawed ingredient.  Those ‘owners’ are required to cooperate, but have limited ‘skin in the game’, since it’s the writer, not the ‘owner’ who is responsible for the content of the Plan.

Even when such plans are passed by a higher-ranking functional manager for approval, that manager may also lack the intimate knowledge of the underlying process’ day-to-day functionality.  Their ‘approval’ then constitutes little more than a rubber stamp of a plan they may not understand (and the more Plans they are required to approve, the greater that possibility).

So each of the players in this scenario operates in their comfort zone:  the Planner relying on their knowledge of regulatory compliance, the owner relying on the guidance of the Planner (while spending as few hours of effort as possible), and the approver relying on their trust of the Planner and owner to have provided what is needed.

The result is a compliance-focused Plan, with little actionable instruction – the type of content needed to guide a Recovery Team through in Incident.

But, you may ask, shouldn’t the annual Exercise of the Plan highlight its shortcomings?  It should. But too often it doesn’t, simply because the Planner is also the Exercise monitor, with a limited understanding of what the business process really requires.

And the scenario can worsen when the Planner is replaced by someone with even less knowledge of the business process’ day-to-day operations.

What’s the cure?  First (as Andy Osborne suggests) separate the compliance “peripheral information” from the actionable part of the Plan.  Second, spend more time focusing on what to do, rather than what to include.  Third, assure planners who are not part of those everyday processes ask more probing questions to increase their understanding.  A short ‘internship’ in the department or function wouldn’t hurt either.

SHARE:
Jim Mitchell

Jim Mitchell

A frequent speaker at Business Continuity conferences, many of Jim Mitchell’s blogs can be found elsewhere on eBRP’s website and has published articles in DRJ, Continuity Insights and Continuity Central. Jim has more than 20 years of experience in Business Continuity; if you don’t agree with his opinions – he won’t be surprised.

Related Posts

Enterprise Resiliency: Navigating Through Disruptions

Enterprise Resiliency: Navigating T...

In today’s threat landscape, the ability of an organization to…
Orchestrating BC/DR Testing: Virtual – Emergency Operations Centers

Orchestrating BC/DR Testing: Virtua...

  Enhancing Planning and Logistics Management  Coordinating BC/DR tests involves…
Insights into creating a successful Disaster Recovery Test – Part 2: Preparation

Insights into creating a successful...

Insights into creating a successful Disaster Recovery exercise – Part 1: Objectives

Insights into creating a successful...

Aligning Cyber Incident Response Planning with Your BC/DR Program

Aligning Cyber Incident Response Pl...

Cyber disruptions – and their impact on both reputations and…
What Can You Do when your BCM software Relationship Falls Apart

What Can You Do when your BCM softw...

“This isn’t working.”  “I’ve changed.”  “I don’t see a future…
Aligning BC/DR to CSIRP Challenges

Aligning BC/DR to CSIRP Challenges

The immediate reaction to a cyber-security incident is the FUD…
Technology Modeling – the eBRP Way

Technology Modeling - the eBRP Way

Definition: Technology modeling is a point-in-time snapshot of an Enterprise’s…
eBIA – The eBRP Way

eBIA - The eBRP Way

Definition: A Business Impact Analysis (BIA) is the cornerstone of…
Threats, Impacts, BCPs

Threats, Impacts, BCPs

Within Business Continuity circles there is ongoing debate about the…