Articles
Yeah, That Makes Sense
Thu, 09/23/2010 - 8:00pm
Clear communication is a joy to behold. A good jazz soloist can turn the whole band on a dime with a single, well-articulated note. An air traffic controller can choreograph large numbers of aircraft in minutes with just a few words.
It’s a beautiful thing when your management understands immediately where your continuity risks are and what needs to be done about them. Getting to that point requires a little science and a lot of art. Metrics and reporting are the communication instruments of a sound BCP program. Often regarded as a simple technical exercise in gathering data, they can make or break your program’s effectiveness in leading the firm to sound continuity capabilities. Here are some common symptoms of communication breakdowns and some ideas for reporting that can help.
Symptom #1 - I can’t get enough time with my senior management to finish explaining everything thoroughly.
Senior management doesn’t need every little detail. Where appropriate, trim the message down to one page, delivered in fifteen minutes. Book a 30-minute meeting leaving half of the time for questions. Focus completely on the areas at greatest risk and draw clear conclusions that can make senior management your agent of change. Be prepared to provide more detail if they ask.
One way to stay focused on risk is to tie all reporting metrics to the critical business functions. Poor test results don’t carry the same urgency when they are from ancillary, “nice-to-have” functions compared to core business processes. Classify both the severity of the risk and the sensitivity of the part of the business that’s affected.
Another way to focus on risk is to separate simple policy compliance issues from material risk issues. An example of material risk is the number of applications that failed to test their recovery instance. An example of policy compliance (but not material risk) is the number of applications that tested but failed to file documentation of their test results. Mixing the two in a single metric weakens your communication. What does the total mean? What actions do you expect in response?
Always provide a sense of scale when reporting risk metrics. For instance, it’s never enough to simply report that there are 200 recovery seats available. Is it 200 recovery seats on a scale of 400 production staff – or 12,000 production staff? Is the message that 50% of your staff have a recovery seat, or that 1.6% have a seat? Is the glass half empty, half full, or half full of poison?
Symptom #2 - I generate lots of reports, but the organization doesn’t support the program like they should.
Clear communication requires that the message is matched to the audience. Think of an airline pilot trying to follow instructions from a jazz musician. Our focus so far has been on senior management, so consider altering the content and level of detail according to your other stakeholders:
Senior Management
• Focus on risk
• Report a small number of summarized metrics for their immediate action
• Integrate with other operational risk reporting
• Motivate for decision-making and approvals
• Demonstrate completeness (all resources are accounted for, checked against official systems of record)
Line Management
• Focus on risk
• Clarify deliverables
• Summarize information within each manager’s span of control
• Motivate for delivery
Individual Contributors
• Focus on risk
• Clarify deliverables
• Clarify process
• Report in detailed lists
• Motivate for delivery
Communication is effective when it motivates correct behavior. Recipients need regular and easily accessible updates that clearly tie their actions to results.
For line management and individual contributors, the topic of communication shifts to their specific deliverables. Where management behavior involves strategic decisions and approvals, line management and individual contributors’ behavior involves delivery of program milestones. Their reports need to illustrate target dates, workload levels and completion rates. Even at this detailed level, risk is still critical to illustrate so that if resources become constrained, priority is given to the most critical areas of the business and the business continuity program.
Finally, all reports must be clearly crafted. Use the most basic language possible and avoid unnecessary jargon and acronyms. For global programs consider that English is a second language for many of your stakeholders. Some of the best advice that we’ve seen on how to represent data graphically has been published by Edward Tufte.
Symptom #3 - My business groups don’t close problem issues in a timely way; they just keep showing up on the next report.
One very common and extremely poor way of communicating risk and motivating behavior is a continuous stream of periodic reports showing dozens or hundreds of “Red” or “High” risk items that barely change. To help differentiate the levels of various risks and motivate action, ask yourself:
- What areas are affected? Do these differ in risk impact?
- Are all “high” risks really high risk? Are their impacts business-specific or firm-wide?
- Were levels of both risk impact and risk probability considered in the ranking?
- How old is each item? Does the risk change over time?
- Are many items related to the same issue?
- What recommendation are you providing to solve the problem?
- Have you established a due date?
The better you segregate issues by their real risk, the more effectively you can address them. For example, create different issue closure requirements by risk level. Require that the most critical issues are closed (or addressed in a viable project plan) within 30 or 60 days. Less critical issues may be allowed 90 or 120 days to close.
Escalate your reporting according to the risks. If issues of real risk go unresolved over time, higher levels of management need to know. Tie risk-based exception reporting clearly to the business’ goals, company policy and regulatory requirements.
Reporting Systems
Successful reporting is easily accessible, frequently updated and delivers clear messages. Transparent business continuity reporting can be done with online systems that are updated at least weekly. Business continuity management is not technically complex, and it does not demand complex tools. The cost of reporting systems can be kept to a minimum with web-based collaboration tools, fed by spreadsheets and simple database products, software that’s readily available from household names in the market. While staff must be dedicated to maintaining data and reports, the skill set does not demand application programmers. Consider the steps in the chart below to create a simple and effective reporting system.
Maturity Process
Metrics and reporting coexist with all other parts of a business continuity program, and must develop in sync with them. The keystone is a clear business continuity policy. The relevance of your metrics draws its strength from the policy. Clear processes are next. All stakeholders should be aware of what work needs to be done, how and when to accomplish their work, and what constitutes good quality.
Expect to develop your reporting in stages as the other areas of your program mature, and as your reporting capability matures. One benchmark of success is moving your constituents (particularly management) beyond focusing on “the numbers” to instead focus on the risk communicated by the numbers. Count the relevant things, not the easy things.
Create a twelve to twenty-four month strategic plan that maps improvements in processes to improvements in metrics and reporting, and identify metrics that can trend the success of the entire program over time. Such long-term metrics can include the number and severity of policy compliance issues, the number of events that impacted continuity and the time-to-closure of material risk issues. In trending reports, be careful not to select metrics that can change over time independently of risk. For example, if in year two of the program you change the threshold for overdue compliance tasks from 30 days to 2 weeks, your trend will show an increase in issues when the underlying risk may actually be improving.
Reporting Examples
Business continuity planning, like Audit, has a horizontal perspective of the firm. Although in many firms the business continuity program is part of the technology organization, their reporting must be equally accessible to all business functions and locations outside of technology. Below is an example of a risk-focused report that uses the model of a financial statement and is perfect for that 30-minute meeting with senior management. Typically, your portfolio standing is broken into distribution of assets, trending progress since last statement, cyclical changes, and editorial summary and analyst recommendations.
The flow is from top to bottom, from the more generalized context to the specific high-risk issues that require management attention. The “Business Presence” section is simply demographic information that shows where the business is located. This could also carry revenue information along with or instead of headcount.
Next, the “Work Area Capability” section illustrates the recovery resources available in each region, in absolute numbers and as a percentage of headcount. Without the percentages, the case of Asia lacking resources would be lost.
The “Program Assessment” graphics show the quality of business recovery plans, and the number of compliance issues over a four-year trend. The current year is broken out to show the risk ranking of issues (nearly half are high risk). A further breakdown shows that most come from two causes, testing and plan maintenance. “Business Recovery Prioritization” is a representation of BIA results, showing at a glance the RTO distributions.
What are we trying to bring to the attention of our senior managers? Clearly two things, under Management Focus and Action, Asia requires additional recovery resources, and testing and plan maintenance require more management attention in both Europe and Asia. That clear case can be made in 15 minutes, with 15 minutes for questions.
Below is a “heat map” graphic that’s useful for showing comparisons of risk levels. The top graph shows a distribution of RTOs by aggregate groupings. It paints a very clear picture for management of how risk is distributed across all of the firm’s business processes. Note that both percentages and absolute numbers are given. 
The second graphic is useful in discussions with both executives and line managers in validating RTOs. Average RTOs are calculated for each Department and all Departments are heat-mapped. It’s usually very obvious when a department has over- or under-estimated their RTOs when compared to all others.
Demographic data can be highly valuable to a continuity planner. One of the first references we check when a crisis event is reported is a simple list of headcount by building and department. RTO information can also accompany the headcounts. This gives us an instant picture of the potential threat and our priority areas for response.
Again using readily available software, demographic data can easily be plotted on maps and the results used to guide crisis management in real time.
Conclusion
There is growing momentum toward continuous improvement and self-correcting business continuity programs. These suggestions will help an organization meet the objectives set forth in British Standard BS 25999-2, including continuous improvement of business continuity systems management. Metrics and reporting can be the mainstays of business continuity systems management.
The health of an organization’s planning can be communicated by organizing information around policy requirements and the governance structure, so gather data that reflects these structures. For example, if your policy requires a BIA, plan updates, testing, and maintenance – and defines specific roles such as planner, business approver, executive approver, then metrics and reporting must map to these areas.
Collect data concerning when deliverables are met. Where possible, extract data from your plan repository system that shows when BIAs are complete and when plans have been updated/approved. Pull data from your testing programs that show when applications and work areas were tested, and the results. If data are not available, you can create an attestation process that allows authorized individuals to enter this data themselves.
In order to check that required actions were complete, con-
sider developing formal risk review processes. Risk reviews can be thought of as rudimentary audits:
- Identifying missing or incomplete tasks
- Checking completed work for accuracy
- Is the plan rational?
- Do all metrics support the recovery strategy chosen?
- Is the explanation for any risk acceptance clear?
- Is the plan viable?
- Can the recovery strategy truly support all business expectations?
- Do physical resources exist to support the speed, capacity, duration and proximity required by the business?
Some risk review data may be readily available in existing systems. For example, logs from automated notification systems may be used to validate call tree testing (by date and success rate). Also, the RTO values of your business processes can be checked against the RTOs of supporting applications and interdependencies.
Other risk review data must be acquired manually such as having a qualified business continuity practitioner review the completeness and accuracy of test documentation for scope, objectives and results or examining the continuity plans and recovery capability of critical vendors for support of your business’ required recovery service levels.
When it all comes together – understanding your audience, tailoring your communication, identifying risk and escalating appropriately – your organization’s flight plan will be tuned to pitch-perfect quality. CI
