In the third instalment of 3gBC, Charlie advises BC professionals how to make their plans slimmer, both immediately and radically.
I thought for this week's bulletin I would continue sharing my ideas on Third Generation BC (3gBC), by looking at how to make your plans slimmer and more agile. Apologies to the two Julie’s who asked for an article on the KFC incident, I will try and write about it next week, as it seems the situation is still on-going.
As part of my 3gBC ideas, I am a strong believer in ensuring that plans are slimmed down and easy to use, instead of 100 page monsters, which nobody would ever read, never mind use during an incident. Even before radically changing the philosophy behind our plans, I think there are several things we can do immediately which will make them more user-friendly and easier to use.
These are a few things which can be done immediately:
1. Strip out everything you do not need on the day of the incident. I see many plans which are a combination of policy, standards and plan information. How often you need to update the plan or run exercises does not need to be contained within a plan. By the time the incident comes along, it is a bit late to start thinking about exercises! How often to exercise your plans is important, but this should go into a separate document. I suggest a separate document I call an ‘Operations Manual’, which is where everything that is not a plan and not part of the BIA is written. So, the first thing you need to review is all your plans, to see what can be taken out to slim them down.
2. Write your plans in chronological order according to when you might need the information and put the reference material in the annexes. Many plans have scope, objectives and an introduction at the beginning of the plan. Fine, but if you have just evacuated your building, do you want to be wading through five pages of background before you find something you can use? So, on the first page or at least the second, put in details of the actions you have to carry out immediately after an incident. I always put the scope on the front cover, so you know you are using the correct document. If you have an introduction, assumptions or objectives, put them at the back of the document or put them in your Operations Manual.
3. Avoid duplication of information. Do you need to have a long list of telephone numbers in each plan, which some poor person has to keep up-to-date? If you need to have a paper list of telephone numbers, why not have one central document and make it available to all those who need it as an annex? You could have one person who updates and publishes it. Better still, have an electronic list as part of a notification system or as part of business continuity software, so once a number is changed it is updated in everyone’s plan.
4. Do you need lists of information in your plans? Yes, you may need business continuity information within it and therefore recovery numbers and recovery assets. Sometimes there are lists for the sake of lists. Check whether you really need the information or whether you can access it from another system which tops the need for keeping it up-to-date.
I heard a good presentation by Tim Armit this week at the Scottish Continuity Group Conference, where he talked about getting all the Post Offices plans down to two sides of A4. I think this is a bit on the radical side, but something we should aspire to. In order to radically slim down your plans, here are some ideas which you may wish to adopt:
1. Have an organisation wide SOPs (Standard Operating Procedures) document which sits alongside individual plans. It would detail how you respond generically and then the individual plans would only contain what is pertinent to that individual department. This would also cover ISO 22301 or regulatory requirements to demonstrate the detail within your plans.
2. Take out the "how to". Business units know how to carry out activities, so does the plan really need to tell them how to deliver them? For recovery, they can have one line in the plan that says they will work from home for the foreseeable future. Do they need any more detail than this?
3. Agendas, checklists, incident management hierarchies, individual and team responsibilities can all be in the SOP document, which can be referred to if needed, but it does not clog up individual plans.
4. BIA information pertinent to the recovery could also be included in the SOP document, with perhaps only the RTOs contained within the individual plans.
5. Telephone numbers and other reference material would also be held in a separate document or downloaded as lists onto mobile phones.
These are all the ideas I have at the moment and I need to do some more work at putting them into practice. Any other thoughts or ideas regarding slimming your plans would be gratefully received, so I can add them to this list to share with the readers of this bulletin.