If you’re like me, you’ve experienced all sorts of assumptions people make when building Business Continuity Management (BCM) programs or any BCM related component; be it Emergency Response, Technology Recovery, Crisis Management & Communications or or or… Assumptions show up in just about every plan or procedure and to be fair, when you’re just starting out to build your program (all the components) that’s fine – up to a point. At some point you must begin to challenge them.
Many are under the belief that an assumption is something you used to develop a plan – kind of correct but not quite. Dictionary.com defines an assumption as “Something taken for granted or accepted as true without proof.” Based on a definition like that, you can’t go too long without proving what you’ve said (documented) is true. If it’s not, there’s a chance a plan isn’t going to meet your organizations needs. Here’s just a quick couple of examples:
- People Availability – This one always makes me laugh because I see it so often. Even during pandemic planning initiatives (don’t get me started on that…) many plans stated that the people ‘in the know’ will be available to execute contingency activities or other leadership measures. Is there a magical bubble around management people or ‘single points of knowledge’ that protect them from colds, flues, disasters and other things? Do they take a magical pill or something? I know at the beginning it might be necessary to have these kinds of statements but after some time it can’t possibly be true. If it is after many years, then what awareness or cross-training has occurred? None; that’s how much. The single point of knowledge is still the only person who knows anything (maybe). The other aspect is when a real impactful and destructive disaster occurs (let’s say a Hurricane like Katrina), people will be able to help the corporation activate it’s contingency plans. Well, it’s well known that many of those ‘key people’ and their families were impacted by the disaster as well, so you can’t assume for too long that everyone needed will be available. Start some cross-training and shadowing during exercises to bring other people into the loop of what actions to take and how to manage the situation(s).
- Other Plans – Without checking or validating, many plans state that other BCM program components are in place. This is odd, considering in many instances the same person is coordinating the development of program components and they will know well enough that other program components don’t exist yet. Still, in many instances this assumption will be included even though the components don’t exist. They build plans based on other components that are invisible because they haven’t been developed yet. I don’t think this can be an assumption until the referred to program component has been developed; until then it’s still an item on a BCM professionals’ to-do list. It would be like looking at a map that has roads and bridges mapped out but when you’re driving along following the directions you get to a the shore of a river and find there’s no bridge at all. The map just assumed there would be one in place, without knowing/validating that it did indeed exist at all. Oh, and from what I hear, don’t pay the ferryman if there is one – you may not like where he takes you. 😉
- Awareness – This one gets proven incorrect over and over again, time after time. Just because you may have put up a flyer or sent an email about BCM doesn’t mean people read it. You can’t assume that because you did this people suddenly know their roles in BCM. If you want people to really understand then let them practice the roles during an exercise and gain experience; help find the gaps in the plans and processes. Even before that, don’t just document a set of roles and responsibilities and then assign a person to them. Bring them on board to help build the plans, roles, responsibilities and other related processes. When individuals become part of the programs development they are more inclined to participate in other ways and help spread the message about BCM; to their managers, executives or to their employees. Everyone in the corporation has a role to play in a disaster, regardless of level. Even if it is to go home and monitor a phone line for updates, status and direction; this is still a role that some people will have. But we as practitioners and professionals must make people aware of this, not just assume they read our flyer and know. That so rarely works…
- Disaster/Crisis Scope – This states that there are limits put on the plan, meaning a disaster is only so big or only has so much impact upon the corporation. This is understandable when you start out planning building program components. However, as the plan develops and builds, so too must its response scope. You can’t assume that a power outage will only occur at a single facility when in fact, it can’t occur at numerous facilities at the same time. Anyone remember the Canada/US power outage back in 2003? That situation proved that numerous locations can be affected by a disaster at the same time. Often, plans seem to address the corporate facility or the data centre – fair enough – however, they tend not to focus very well on the smaller satellite offices (regardless of size). In one instances I recall from a manager, they would figure out what to do exactly at a location when something actually occurs. Or, the assumption is that an earthquake will be of a specific grade and only inflict so much damage. Well, when an earthquake hits or a fire starts, who knows what damage it can cause. You can’t assume there is a contained fence around every situation because mother nature and human nature, can cause greater damage than you can imagine and you’ve got address that kind of scale at some point.
- Technology – This one is a bit tough because I’ve seen in many instances where the Technology Recovery Plan (TRP) is developed by IT staff – which is good – but there is not link or involvement by the BCM professional. So what happens is that the components developed by the BCM professional – or others – assume that IT knows what they need and the order in which services must be restored. In a plan I saw recently it stated that “Technology understands what is required by business units.” Yes, this is a direct quote (though I may have missed a word or two) taken from the plan. After I spoke to someone looking after the BCM plans they said they’d never attended or coordinated any meeting with IT about any TRP requirements. So, how does Technology know what is required? Sure, they understand that there are specific components that must be up and running prior to any services being restored (i.e. network, telecommunication etc) but what about the services offered by the corporation? You can’t assume they know what is important to the corporations (by way of client services) and what can be suspended for some time. Make sure there is a connection with the TRP and don’t assume that IT has – or knows – all the answers. (Note: This might be a topic for a later blog.)
- Statements – I’ve often seen where statements are assumed (Yup, I used the word) to be assumptions. Here’s one from a pandemic plan I was given to review a short while ago: “The (disaster team) in consultation with Managers, will redeploy resource to departments as needed to ensure the continuous delivery of services notwithstanding reduced staffing levels.” Now, is that an assumption or an action/strategy item? Sounds like it would fall into the action/strategy category rather than an assumption. And if you read it again, it assumes that managers are unaffected by any pandemic illness (They must be in that magical bubble again.). There are even some comments – made to be assumptions – that guess at the time of a disaster. Some state that this plan is only good for the daily operating hours and other plans will kick in if it occurs during weekends or evenings but these plans never get documented. So, if a company experienced a disaster at 7pm on a Friday it’s screwed cause what they’ve developed doesn’t address that timeframe. Of course, it might be able – and probably will – adapt what it has in place to the situation but still, you can’t say a disaster only occurs ruing the 9-5 time period. Life just ain’t like that.
A corporation may start out using assumption to help build its program but as it matures and develops its programs, the assumptions must be challenged to validate that they are indeed true. Sure, there may be some assumptions that are true even after you challenge them through exercises or other method but then at least you know they are true and not ‘imagined’ to be true. Exercises will help validate what is and isn’t true and they should be challenged during various styles and methods of exercising to make sure they are still true – or not. Organizations change and so too with the assumptions upon which its BCM program is built and for it to mean anything when a disaster strikes, you can’t build it all upon assumptions that may or may not be valid. If you can, don’t use any assumptions cause the only one that will be proven correct in the end is that all your assumptions are wrong! …and then it’s too late.
The new book by StoneRoad founder, A.Alex Fullick, MBCI, CBCP, CBRA, ITILv3, “Heads in the Sand: What Stops Corporations From Seeing Business Continuity as a Social Responsibility.” Available at www.stone-road.com **