Decentralizing the Plan Approval Process
- Published on June 22, 2009
- Written by FRANK LADY, CBCP, CISSP, PMP
Business continuity (BC) plan components continually change. We see this change as the rule, not the exception. As a result, BC plans require continuous maintenance to avoid becoming stale or even irrelevant.
Occasionally, significant modifications to the plan’s business functions make necessary a major transformation of the plan. These new realities may include organizational restructuring, facility realignment, merger or acquisition, process evolution or revolution, or other factors.
More frequently, smaller scale changes affect plan details. Adjustments to employee and stakeholder contact information and call trees, vendor relationships, desktop technology configurations, communication tools, critical applications or vital records, incorporation of exercise lessons learned, and a host of other aspects continuously erode ccuracy.
Another challenge swirls with these undercurrents of plan change dynamics. The general length of BC plans inevitably expands in proportion to the size and complexity of their supported organizations and recovery strategies.
BC professionals must reconcile the competing imperatives of keeping plans current with making appropriate time demands on the (senior) managers who approve the plans. Plans cannot atrophy. Equally important, we must not ask plan approvers to invest excessive time in frequent, lengthy plan reviews. They must see a plan summary which does not submerge the essential elements into an ocean of less significant pages.
Decentralizing the approval process solves this dilemma. This concept contains three crucial parts.
First, divide the plan into two sections: the core plan and supporting documentation. The core plan contains only those elements which the manager/plan owner must personally approve. It normally should require approval once per year.
Contents of the core plan may include: scope, assumptions, recovery strategy and objectives, overall time expectations, a general sequence of events, key responsibility assignments, and single points of failure. These factors drive the details addressed in the supporting documentation, and do not change frequently.
Every other component of the plan (perhaps 95 percent of the total) falls into the supporting documentation section. Different stakeholders (anyone besides the plan owner) approve each of these documents. These approvers are the application owners, process owners, subordinate managers, etc., who own the day-to-day operation of a particular relationship, function or resource. The BC team prepares the rest of the supporting documents. Some of these artifacts will require quarterly review. Others will need less frequent update.
Second, establish the frequency of review for each plan document based on its expected shelf life. Balance the need for “hot off the presses” information with the competing challenge of distributing plans on a frequency that will not confuse plan recipients or overwhelm distribution channels.
Most organizations should adopt a quarterly update process. In three quarters recipients receive a supporting documentation revision, which may include either the documents which changed, or the whole section. In the remaining quarter they receive the entire updated plan.
Third, formalize the plan approval process in program-level documentation. This delegation of authority describes the general assignment of responsibilities and requires creation of a detailed list of plan documents to be maintained.
The BC program reaps numerous advantages from decentralized plan approval. It focuses the senior managers’/plan approvers’ attention on the core plan, which contains the most critical aspects. It relieves them from the burden of meandering through a maze of detail which doesn’t require their oversight. It reinforces the concept that “day-to-day” process owners also own the operation of their functions during recovery from disasters or outages. It recognizes the reality of frequently changing plan supporting details without giving recipients the misperception “the (core) plan” has changed. It levels the workload over the course of the year and helps sustain the legitimate visibility of the BC function across the organization on a meaningful basis.
Successful adoption of this technique requires considered application of all three elements. It will not reduce plan complexity or length. However, it will help mitigate the mayhem and enhance organizational readiness.
Frank Lady, CBCP, CISSP, PMP, has more than 15 years of experience in business continuity and contingency planning roles. Lady joined the Editorial Advisory Board in 2008. He welcomes feedback at email@example.com.