BCM & DR Program: Using and Dismantling Assumptions

In all planning, whether it is for projects or programs and regardless of the industry and nature of business, one of the key areas that often gets overlooked is the use and belief in assumptions. Not just overlooked but they tend to become part of the fibre of every project and every BCM/DR program. We assume ‘so-and-so’ knows this ‘action’ and will do that ‘activity,’ when in fact, so-and-so has no idea what they’re responsible for or even that others believe they’re responsible for it.

We don’t communicate assumptions often and if we do, it’s once or twice in the initial stages of a BCM/DR project or we make them up within the confines of our own segregated meetings, which aren’t attended by those that the assumptions are based on. We capture the minutes of the meetings and action items but never reach out to those we assigned an assumption to; they’re forgotten and actually become part of the BCM/DR framework – the plans and procedures we expect others to implement at the time of disaster.

Assumptions are used to fill a void – an unknown. When we don’t know an answer we plug in what we hope will be proven to be the answer but fail to follow up on it. When it doesn’t occur the way we want, it’s because we put faith in an assumption, as though it was always correct rather than trying to disprove or valid it. By failing to disprove it, we are in the false believe that we’re taking a step forward because we embraced and accepting the assumption and in this way, provide ourselves with a level of comfort and a reason to point the finger of blame when something goes wrong.

Assumptions aren’t just found during planning and development but during the implementation stages – or phases – of various program components. Even when an actual disaster occurs assumptions abound, as Crisis Management Teams (CMT) and individuals assume that others are performing the activities required. Even the assumption that people – and everything else – is and will be available when needed. If everything was available when and where it was desired and expected, then we wouldn’t have such diverse plans and processes in place to deal with such disaster situations.

Assumptions aren’t always a bad thing. At the beginning of the BCM/DR program development, assumptions help move things forward. You plan up to a specific milestone based on a set of assumptions and then validate them through exercises and tests and conversations, as minute details slowly emerge the more and more planning develops. The results of which (exercises, conversations etc) help fill in the gaps identified that were – originally – assumptions. This way the assumption becomes a positive because it helps move the program forward by challenging those involved and initiating conversations between groups; communicating the expectations various groups and individuals have about plans, processes and procedures. Not revisiting them and validating them will only cause problems.

As the organization, changes – plans, processes, resources, locations, lines of business etc – so to must the assumptions. An assumption developed at the outset of the program development can’t be considered valid years later when all the players and everything else associated with it, has changed. That ‘s simply ludicrous and naive. They must be revisited over and over because they may be true under some circumstances but invalid under other circumstances. Since no one ever knows, when or where a disaster occurs or under what circumstances, assumptions must be challenged, communicated and validated on a regular basis…and quite possibly, new ones developed over time.

© Stone Road inc, May 2012


“Heads in the Sand: What Stops Corporations from Seeing Business Continuity as a Social Responsibility”

“Made Again Volume 1 – Practical Advice for Business Continuity Programs”

“Made Again Volume 2 – Practical Advice for Business Continuity Programs”

by StoneRoad founder, A.Alex Fullick, MBCI, CBCP, CBRA, ITILv3

One comment

Leave a Reply

Your email address will not be published. Required fields are marked *