Well, as promised, this is the 2nd part of the “What Constitutes a BCM Program” post. As with the 1st post, I’ve intentionally made some adjustments and left some bits of information out to spark conversation, thought and input – so I’m well aware there’s more to a program than just what I’m writing here. It’s a long one, be warned.
We can easily say that a BCM program is made of BIA’s, BCP’s, Crisis Teams, Hot/Warm/Cold sites and all the other technology restoration & recovery components – as well as many other BCM components – but a good program is made up of more than just that. Not only does a good program ‘fit’ with the corporations needs to keep operations going or to minimize any potential impacts when serious situations are encountered but it’s also how BCM is perceived and imbedded into the corporations culture. A company can have many BCM components developed and ready for use but if no one supports or contributes to them or participates (i.e. exercises/tests) is it still a good program? It’s kind of like ‘If a tree falls in the forest and there’s no one there to hear it, does it still make a sound?’”
A good program will address the corporate culture and the social aspects of BCM, not just the documented program components required by various schools of thought, methodologies or what someone says you should have as part of your program (if indeed you even need it to begin with). The ‘feeling’ for BCM and the support must be there within the corporation if the program is to be successful; from the senior executive right down to the newest person walking through the door and attending their orientation session(s). Everywhere they turn, employees need to know that there is a BCM program in place to protect – or rather have strong mitigation and contingency activities in place – their employer’s people, facilities, customers/partners/vendors/suppliers and the technology infrastructure. Like on a warship, when disaster strikes or some threatening situation is possible, everyone understands their role in it and what actions need to be implemented. It’s kind of like a doctor seeing someone hurt – they don’t wonder if they should help, they know immediately what they should do. Yes, that’s a bit of a simple example but I think you get the idea.
So how can this kind of mindset be instilled into the corporate culture? How can anyone tell if BCM is taken seriously or not or if it’s just a ‘tick box’ on someone’s annual report? A BCM program doesn’t have to have all the components in place for it to be considered ‘good. It could only just be starting out and in its infancy but still, the individuals working on it are getting the support from all areas (top to bottom) and have a good framework mapped out based on the corporations need. There are a few ways in which you can tell if a corporation takes BCM seriously, which in turn will provide a good idea on if the program is good or not.
1 – Awareness – Employees (of all levels) actually know about the program and related plans associated with it.
2 – Training Opportunities – Those that are responsible for the program (us worker ants) get the time and resources to improve and increase out skills, which ultimately will help the program.
3 – Easily Accessible to Employees – Not everyone understands technical documentation or all the details associated with the plans, so make sure that there is information available in more than one form (i.e. FAQ’s, Visio, PPT etc…).
4 – Visibly Supported by Senior Management – CIO’s or CFO’s or CEO’s actively promote the program and don’t place it on the backburner every time the subject is raised.
5 – Part of New Hire Orientations/On Boarding – New hires should be told what the program entails and what their role is, especially those that might be taking over a role that a key player in the ‘disaster team structure.’
6 – Employees Solicited for Input – It’s people that build the plan and there are all sorts of expectations on employees to follow the plan, and they’re more likely to follow it and believe in it if they’re part of the building process.
7 – Don’t Hide Exercise/Test Results – Be honest. If there are gaps then let people know about them and build the right plan(s) to address them. Don’t ever tell people they were failures and didn’t build a good plan based on results, there’s a chance you’ll be going backwards in your program development.
8 – Seize the Opportunity in Adversity – watch the news and see how real world events can help you program. If you have a crisis – LEARN from it and use the findings to enhance what you have. Don’t just point the finger of blame.
9 – Scenario Focused or Not – If you try to develop a plan for every single scenario (Scenario is defined as, “an imagined sequence of events”) so focus on some key areas; Employee availability, Facility availability, IT availability and as an extension, Vendor/Partner availability. If you can cover those areas – regardless of the trigger that activates those components (i.e. snowstorms, strikes, power outages, IT component failures…) then you can throw any scenario you want at the plans and you can adopt the right response. (NOTE: See a past blog entry about this subject). https://stoneroad.wordpress.com/page/3/
10 – A Seat at the “C” Table – Someone who sits at the boardroom table is directly responsible for BCM and updates the rest of the “C” level on a regular basis.
11 – Dedicated Resources – Someone actually works on the program, not just reassigned to do some BCM work for a short period. How else could the program stay alive and be maintained.
12 – Embedded and Incorporated Into Organizational Processes – If you look at an org chart you see someone(s) who is responsible for the BCM program – it stands out even on paper.
13 – Not Solely Owned by IT or “Business” – BCM needs to the bridge that brings both elements together, not bring one against the other.
There are more but this list gives you an idea how to recognize a good program.
So, if I’m driving a small little Datsun from the 70’s and you’re driving something that just rolled off the lot with a plethora of gadgets and widgets but both of us can still do what we need to do, does that mean that one car isn’t meeting the needs of the driver? Or is the smaller car just not meeting the needs of the OTHER driver? Either way, the needs of both drivers are being met, which is what BCM must do; meet the needs of the users, or rather the corporation for which it is built.
It means that no matter what you have in your program, if it meets your needs – from technical aspects to crisis communications to department contingency strategies to ‘tired and true’ maintenance processes etc… – then does it mean that one program is better than the other simply because they may vary from one organization to the other?
Remember, the most beautiful person in the room doesn’t always have the best personality to go with the looks….well, except for me of course (cough). What constitutes a good BCM program isn’t always the one with every single component/facet/document/process (etc etc) in place – it’s the one that works and meets the need…and as the corporation changes, so too will the program. That’s a good program!!