Following on from his concept of ‘Third Generation Business Continuity’, Charlie provides us with his thoughts on how to reduce your BIA and the advantages of doing so.
In the words of Marjorie Dawes from Little Britain, “You is fat! You one big fatty thing!” For many, this is an apt description of their BIA. It is a series of interconnected spreadsheets, which capture a significant amount of information. Whilst it may be looked at each year, it isn’t touched, just in case the spreadsheets break. You aren’t sure what the information means, so you sign it off quickly and hope that nobody notices it hasn’t really changed, apart from the updated numbers in your department, because you have recruited ten more staff over the last year.
In last week’s bulletin I put forward the concept of third generation BC, now called 3gBC (thanks Steve Dance), which is an idea for trying to streamline the BC process. This week I want to share my thoughts on how to slim down your BIA. I had the chance to try out the concept at an NHS Regional Board this week and it seems to have survived contact with a real organisation! Lots of practitioners have come up with ideas for how to replace the BIA, none of which seem valid and very few look at how to slay the BIA monster and replace it with a workable solution. The solution, as per last week’s bulletin, needs to pass the PWC test of being able to pass an external audit and therefore must be compliant with the requirements of ISO 22301 and GPG 2018.
What I am suggesting is a way to radically reduce the amount of work in the BIA, both in developing and maintaining it. My concept is to split it in half. Half of the BIA will be a central BIA, consisting of the RTOs, MTPD, dependencies and charting the impacts over time. The second element of the BIA is done at the business unit level and contains the resources needed to recover that individual business unit. Conducting the BIA at a high level separates the part which rarely changes from the more dynamic section of the organisation, the resources required by the business unit, which is a lot less conceptual and easy for the business unit to understand and update.
The central BIA is done at organisational level or, if the organisation is a huge multinational doing a myriad of different activities, it can be done at a regional or country level. The central part of this BIA is rolled out across the whole organisation, to identify the different activities it carries out. This can be done with a small number of people who have a good knowledge of the organisation.
In very large organisations, the same activity is often done in lots of different places. The secret is not to conduct the BIA at a very granular level. The level you want to go to is Finance as an activity. There is no point in a 3gBC BIA which goes down to the next level and does BIA on all the different activities within finance – working on the principle that on the day of the incident finance will have an RTO and a level at which the activity can be recovered. It is up to them on the day to decide which part of finance to recover, they know their business and their priorities, and they don’t need a granular BIA to tell them which part they should recover, as well as having lots of different RTOs for different parts of finance. I would suggest keeping activities to a maximum of 50 at the central BIA level. When we did a BIA with the NHS this week, we identified 43 different activities across the whole organisation. Once you have your activities, you have to evaluate the impact over time and determine your MTPDs and RTOs. Alongside this, you need to do your return to normal and seasonal variation. Once this analysis is done, it is written up into a single BIA document, which can then be signed off by top management.
This central BIA is owned by the BC Manager and can easily be updated by them, either annually or when the organisation changes. Updating it is a simple process and this method also has the advantage of assessing all activities across the organisation, rather than just the most urgent ones. This process can be used across the organisation and the most urgent activities can be identified from the analysis and by looking at all the activities. This is the most difficult part of the BIA, but it is done by those with BC knowledge who are familiar with the BC concepts.
The second part of the BIA is the resources part and the level of recovery, the MBCO. This is best done at business unit level and at the same level as the department’s plan is being developed. Instead of having a separate BIA document, the MBCO and the resource requirements are written straight into the plan. This makes it is easy for the business to understand why the recovery numbers are there, and they can see how this fits within their recovery plan.
I think this part of the BIA should be done as part of developing the plan and simultaneously with developing the strategy for recovery (BC solution) and determining how the organisation will recover. The business unit gives its RTO that was developed centrally, which they then need to concentrate on how to recover to the time set for it.
I find in the very sterile environment of a BIA workshop you expect a business unit, who are only just discovering what BC is about, to set its RTO and MBCO conceptually without really understanding what they are doing. How much better is it for them to start looking at their plan and recovery options in a planning workshop, when they are dealing with real life, rather than the ivory tower of the BIA development workshop? By making them fill in the level at which they want their organisation to recover and the resources required to do this, I believe is much easier for them to understand. When they come to update the numbers and resources within their plan, and therefore a BIA update, they understand why the figures were there and how they influence their recovery. By putting the BIA information directly within the plan, you avoid updating the BIA and not updating the same information on the plan. You also cut out the “bumf” superfluous information found in many a BIA, which serves no real purpose. If information cannot be used in an incident and does not add value to the plan, cut it out. I believe by doing this second BIA at business unit level, we will increase the quality of information, because people understand the concepts better and we make it much easier for those responsible to update the information.
I am still thinking about how to conduct the risk assessment, so I will provide my thoughts as soon as I have thought about it more.
Conceptually, this idea seems to work for me and we successfully captured and identified the most time critical activities of the NHS in a morning, which gave us enough information to conduct a write up central BIA. I am interested in other people’s thoughts, to see whether they think it will work in their organisation or if they see any fundamental flaws in it!
Last word to Marjorie; “Oh, dear, it’s not easy, is it?” Or perhaps it is?
