“Report writing is fun!” ~ No one ever.
Part 3 in a series.
One of the difficulties that people have when doing a Business Impact Analysis is effectively reporting the information they’ve collected. It’s difficult because there is SO MUCH DATA! The tendency is to report statistical information such as the number of critical vs. non-critical business functions or RTO by tier. While reporting statistical information is (somewhat) valuable and does provide a high-level picture of the business, it fails to deliver insight. Here’s a look at the reporting method I’ve come to use:
Vetting and Approval: I mentioned in part one of this series that when I hold my BIA workshops, I project my spreadsheet on the screen so that everyone can see what I’m capturing. This helps to ensure that I heard them correctly and gives the participants a chance to correct me or add to what I’ve collected. This helps down the road, when I share the completed worksheets with the team for vetting and approval. I like to do two types of vetting – vertical and horizontal. By vertical vetting I mean that I take the information provided by each department and share it with the senior most person of the business unit. Sometimes that person will have participated in the BIA, and that makes the vetting and approval easier. Often, the senior member of the team doesn’t come to the workshop, so they are seeing the data for the first time. If this is the case, I walk them through the information that I collected and leave it with them to review and comment or approve. Horizontal vetting can be interesting. Here I share the data across all business units. This is where the SVP of Finance gets to see what the HR team’s system requirements are, or what they consider to be critical business functions. I don’t allow a leader from another business unit to override another team, but I do allow the discussion to take place in order to build an appropriate priority across the enterprise.
Reporting
I’m surprised at the number of people who tell me that they don’t report (or at least they don’t share) their BIA data. You have just collected a massive amount of data from across your enterprise that will become the backbone of your entire program. You must share what you’ve learned! The question is how? When I worked for a big, blue, service provider, they used to report statistically in a PowerPoint format. The report showed the number of workshops held, how many business functions were identified, how many critical functions there were, etc. We’d list out the most critical functions, shortest RTOs and make recommendations about next steps. Customers liked that aspect of the report because it showed a big picture view of what we did. But I don’t think it was enough. So now that I’m out on my own, in addition to the statistical information (which I’ve consolidated into a single slide infographic – with supporting backup slides), I go deeper.
Let’s start with the infographic. I have nine sections of a diagram showing statistical information about RTOs, RPOs, manual capability, critical business functions, the need for DR (based on the results of a DR Gap Analysis), recovery tiers vs. industry average, maximum tolerable downtime, impact and common vital resources. The infographic shows a glimpse of the entire data collection on one slide. I include detailed slides to add details to the story that the picture shows.
In addition to the graphical representation of the data, I provide more detailed reports in the following formats:
By Business Unit: I have developed a report that captures the key BIA data for each business unit. It lists all business functions in order of priority and details information captured in the BIA, such as function owner, maximum tolerable downtime, work location, manual processing capability, alternate work space, vital resources, staff, etc. Each business unit gets their own report. This report is valuable because it summarizes the business unit’s information and I end up using this same information in their departmental Business Continuity Plan.
Enterprise Functions: This report lists all critical business functions identified throughout the BIA. You can report all functions if you like, but I find that typically executives like to focus on the critical stuff. I’ll list the functions in order of priority as defined by maximum tolerable downtime. I include the business unit, function owner, alternate work space and impact as identified in the BIA. Note – I collect impact over time, but I report the impact just at the maximum tolerable downtime point. I also include the function’s ability to work manually (without network or systems). This becomes useful because it shows the organization’s most critical functions and the impact of a lost facility or lost systems.
Enterprise Systems: This is the report that IT is looking for to find out what crazy RTOs the business has identified. We understand that applications are often used by multiple business units. As such, it’s interesting to see how the RTOs and RPOs differ from department to department. We always used to assume that the final RTO would be determined by the department requiring it first. But IT has a say in this too. DR solutions can be expensive and depending on your platforms and configuration, there may be some appropriate discussions to be had about the final recovery objectives.
Other reports include cross function dependencies, external dependencies, vital resource requirements and a critical period calendar, all of which are enterprise wide reports. In addition to these formal reports, I also like to put the information in various spreadsheets, which can be sorted, filtered as needed It’s often the unformatted spreadsheet data that I use when developing various strategies and tools, which I’ll cover next time.
Next: Using the Data to Build Strategies.