Most of us have gotten used to our rapidly-changing world. OK, perhaps ‘gotten used to’ is the wrong term; maybe “learned to live with’ would be more appropriate for non-Millennials. It wasn’t that long ago that PC’s had memories measured in Mb’s; today’s Smart phone has more memory than the Apollo 11 capsule that first took man to the moon. At the turn of the millennium wireless phones were the size of small bricks and they were just that: phones.
But recently I’ve encountered organizations which have neglected to update their Business Continuity documentation. I can understand if a Plan will suffice for more than a year without updating. But what happens when that plan is based on a BIA that’s more than a few years old? How about four – or eight? It is likely that things have changed in those intervening years (vendors, applications, locations, people, customers, regulations, phone numbers…). Did all of those changes get captured in Plan updates? How would anyone except the author know that for sure?
For years I’ve told the story of a teleconference I once had with the BCM team from a government organization which was looking to update their BIA. After much discussion, I asked when their BIA was conducted. Much mumbling and rattling of papers ensued, but they never put me on mute. I clearly heard someone respond with a date 5 years earlier.
I understand why some organization struggle – or even neglect – to update their BIA data. Many have created a BIA process (often based on a complex ‘survey’) that is so cumbersome it takes months, if not years, to complete across the enterprise. The scale of the effort, and lack of dedicated staff, make if very difficult to repeat that process. It becomes easier to ignore it than to make the effort to repeat it.
Unfortunately, unlike Cabernet Sauvignon or fine cheese, a BIA does not get better with age. What once was if probably no longer. And a plan based on guesswork would be just as viable as one based on a 4-year-old BIA survey result. Even more dangerous is the designation of Critical Processes based on an aging BIA: the priorities for recovery may no longer resemble the needs of the organization. That gap renders the entire Planning process suspect.
If a BCM program relies on Business Impact Analyses – for whatever purpose – and that data is not updated regularly, there is a great likelihood the program itself is planning to recover yesterday’s business, not today’s.
Of course there could be extenuating circumstances (like C-Suite directives or regulatory requirements) that make use of BIA data less relevant, and thus less necessary to update. But an antiquated BIA is most likely a sign of a BCM program that may be failing to keep up with fundamental changes in its organization.
A simple BIA is better than an ancient BIA. If you’re guilty of neglecting your BIA process, there’s still hope. Narrow the objectives. Ask fewer – but more direct – questions. If you do nothing else, determine which Business Processes are most important to your business. With that information, focus on understanding the assets on which those critical processes rely. It’s those dependencies – or loss of them – that form the core of every viable Business Continuity Plan.
There’s an even more insidious problem lurking in some BCM programs. It’s the subject of my next blog.
