Though many may balk at this, the response ‘I don’t know’ is acceptable when building plans.
Recently, a discussion was held at a client’s site to begin developing Technology Recovery Plan and building out activity lists. One of the first questions asked by the facilitator was, “What is your first step? Regardless of the situation, you’ve been told to rebuild the infrastructure at the off site recovery location so what do you do?” (They have a contract with a service provider) and the response that kept coming back was questions about the situation and wanting to know details.
Every disaster situation, either man-mad or natural in design will provide its own set of circumstances yet still there will be similarities that must be addressed regardless of the situations’ ‘trigger.’ What was really odd, is that still participants were told on numerous occasions that they should assume communications and other protocols have been activated; that their first thought should be what to do after receiving the message to go to the off site location. (Note: I found later from the facilitator that the team didn’t actually know and had no documentation and were too afraid to say it out loud.)
It took some time but a few participants spoke up and finally said they’d need to pull their documentation and follow the steps outlined within it. When asked ‘What documentation?’ it became apparent there was none.
Once that was out in the open, the participants began to make plans to hold meetings to go over what were the basic actions required at the outset of a disaster (technology focused only) and what kind of documentation they would need. Many didn’t like that idea and wanted to be told what they would do. These were the individuals who were the Subject Matter Experts in their areas of responsibility, so it was interesting to find that even though someone can know allot about a service, system, corporation, applications etc, they may still not know what to do when a disaster strikes.
This is the responsibility of the BCM Practitioner to make sure that steps are taken to bring awareness to these individuals and walk them through how to build their technology recovery plans. Business Continuity may be the steward of the program and coordinate activities but the content and the knowledge on the systems should, nay must, come from the SME’s – it’s why they are the SME’s isn’t it? They know what needs to be done and in what order.
Many individuals in BCM can – at a high-level – state what needs to be done but the details must come from the SME’s within the various IT teams. The BCM professional should help coordinate this and facilitate any meetings so that not only are the technology recovery plans being build but they are being build, understood and bought-into by the people who would need to use them.
Upon the first draft of these plans, a walkthrough can be done to flush out more details until its decided that a larger more complex test/exercise will be performed to validate what’s been developed up to that point. Then, from that test/exercise more details and clarity can be incorporated into the plan(s) until an organization gets to the point where any technical person can follow along and perform actions because the documents are detailed enough for them to follow.
Starting along this road though is hard and tough and can be full of obstacles. The biggest obstacle to get people to understand and realize is that “I don’t know” is the first step in developing a proper Technology Recovery Plan (TRP). The aftermath of stating such a fact results in the flow of ideas that eventually are moulded into workable Technology Recovery Plans (TRP). If I was asked how to rebuild an infrastructure, I’d probably respond with “I don’t know”….so I guess I’m on my way to learning quite a bit. J