I was reading a few articles recently – and receiving notices through some of the membership groups I’m part of – regarding the creation of Business Impact Analyses (BIA), Crisis Communication Plans and Technology Recovery Plan (or Disaster Plans). I noticed a common threat amongst all the authors, which struck me as a bit odd. It seemed the only way a corporation can develop these plans was to purchase an application tool.
I’m not saying that all of the authors were stating a corporation should use software, but a vast majority of them were. Is there something wrong with doing it yourself – if you know how? Many don’t have the budgets for some of these applications, even though many state they’re affordable. Some are affordable but they don’t’ include specific aspects (i.e. support, training etc) which increases costs and then it becomes unaffordable; especially for the smaller corporations.
I recently read a couple of interesting articles with regards to all the various tools and applications that are out there designed to help corporations build their programs and/or recovery strategies. There were quite a few points made about what corporations should consider when purchasing BCM/BCP/DR software. Some are pretty good and others, well, maybe not so good. I thought I’d take some of the key ones I’ve come across over the last little while and simplify them a bit – with a bit of my own additions thrown in to compliment what the various authors have said.
- Executives Don’t Provide the Same Level of Support – Instead they put the support and confidence in a program, which is purchased, to provide all the answers. The application/program knows nothing of the corporation, yet it is sometimes seen as having all the answers.
- Heavy Reliance on the Application – Some organization will put more faith in the tool itself than the people who administer it or analyze the data. Instead the responses that are provided by the tool are assumed to be accurate and correct, with no follow-up occurring.
- Tool Only Spits Out Results Based On Input – This could be garbage, which means the ‘plans’ it provides will be exactly that.
- Different People Respond with Different Viewpoints – When people read questions, they interpret them differently. As a result, the responses provided sometimes are documented in a different context than with the question is intended but since there is no – or little – human intervention, the response is assumed to be correct. The reality is, the question has been responded to incorrectly.
- Can’t Access the Tool if the Site/IT is Unavailable – Unless the corporation has the money to house the tool offsite – either internally or with the software vendor – when a disaster occurs, the plans that are contained within the application can’t be accessed. So what good will they be? Of course, if hard copies are made then would be kept off site for use but if there is reliance on the tool, hard copies may not have been developed.
- Don’t Buy Operating Processes Off the Shelf, So Why Buy Recovery Strategies Off the Shelf? – This really says it all. It can take years for an organization to build its processes and procedures; its client and vendor base and many other aspects. None of these are bought simply by walking down the aisle at the local supermarket and picked off the shelf – and then sauntering over to the cash/checkout stand. If this is the case, how can a recovery application suddenly be able to address all the recovery strategies needed? You can’t walk down an aisle and pick what works; there’s allot of background work required before any strategy (or BCM program for that matter) is established.
- Administration – Let’s face it, administration can be nightmare for many corporations. I personally was in a situation where a product was purchased and we encountered all sorts of issues with the tool (it was touted as being one of the best you can get) but due to all the complicated administration involved, it never made it off the ground. Eventually it was abandoned. Oh, we could have got the vendor to do the administrating and other bits but at a cost – which wasn’t in the budget.
- User Training – Not everyone has time to take long training sessions to use the software ,which in their eyes will be utilized only once. They may have time allotted to other training and career development ideas. Still, training will end up being something that will be done on an annual basis (assuming the tool is only used once a year) because people will have forgotten how to use it. In a year’s time someone may have left the corporation that did take the user training and now the administrator (assuming its internal) will have to make sure they are trained appropriately. It could cause higher costs, which the organization may not be willing to incur.
- Reporting – Most software applications come with ‘canned’ reports, which in some cases are pretty good. But since each organization is different and each management team has its own culture, so to are the results they want to see from BIA’s and contingencies plans (and others). Again, developing these reports can be a nightmare once again, as everyone wants to see something in their own view.
- People Aspects & Nuances – Let’s face it, unless you’re a fan of Sci-Fi (and I mean quite heavily into it) people aren’t machines and machines aren’t people. Applications can’t take into account the differing aspects and meanings put into words by people. It can’t interpret or ask questions about responses provided. The one variable factor in any project, plan, process or program is people. We must remember that if we’re using software to build out BCM components and related findings/plans.
- Use Software As An Aid – If you are using software, it must be used as an aid, not as the primary device to develop plans. Nothing can take away from the knowledge and experience of a professional who has an understanding of BCM and related processes to develop a program. IN many cases an application can help capture data and help in other aspects but it won’t be able to interpret the data the same way a person can. It can’t read between the lines; it sees response as logical when we all know, sometimes people aren’t.
- Detailed Plan – Unless there’s a secret brain inside the application you purchase, it can’t document specific set-ups and configurations of how a network is architected. Of course, if you’re lucky maybe some of this material is added to the tool but again, some of the previously noted challenges may come into play.
- Software is Not Trained in BCM – Though BCM personnel may design it for use, the application itself isn’t trained in BCM. It won’t know the various nuances that need to be considered such as the people issues noted earlier. People aren’t automatons when a disaster occurs but the application will spit out plans and procedures as though they are
These were just some of the arguments the author had, along with quite a bit of additional input from me. What does this say about the BCM professional? Are we seeing too much reliance on technology to provide the answer? It does seem ironic that we build plans to respond to actions that take away our technology capabilities (as one example…) yet we use technology to help us determine how we respond when it a disaster happens – and in some cases, completely reply on technology to tell us what to do.
For the record, I’m not going to state one way or another whether a corporation can utilize a software pack or not, even though I’ve added some thoughts to the points above. Maybe in another post I’ll state something about the negative aspects of using people only and not leveraging application capabilities.
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 **