Once, long ago, I was on a date with an attractive young woman and so enamored with her that I began to plan out when we could see each other again … while still on the date. That day we planned several more dates, and within months, we were married.
Has anyone ever felt this way about your business continuity program? Have your executives felt the pitter-patter in their chest whenever your program is mentioned? Have they casually ever walked by your office hoping to bump into you? Or planned the next meeting with you within a few days after your last one?
No? Me either.
It’s You, Not Them
It’s almost repetitive. The first year they loved you (or tolerated you) and then slowly, they started to pull away. Soon, you don’t even talk anymore. Ok, I’m being dramatic. But has this happened to you before? Maybe it really isn’t them. Maybe it is … us?
There are currently many articles out there which have been critical of the traditional BIA to BC plan model. Articles such as David Lindstedt’s “BCP is Broken” (https://www.linkedin.com/pulse/bcp-broken-3-reasons-paths-david-lindstedt/) outline some key reasons why this approach should be revised.
Highlights suggest for the most part that BC hasn’t evolved much over the years and that we’re not able to prove our worth very easily. Rather than being the object of an executive’s affections, we haven’t engaged them in the program and created brand value.
I think there might be a way to change the way organizational leaders look at BC. But first, let’s examine the traditional “BIA to plan” cycle so we can figure out where things can go wrong.
Same Thing Different Day
Immediately upon getting the keys to my new business continuity program, I set upon the traditional path of developing a program. Plan. Do. Check. Act.
In the traditional sense, this means you identify the organization’s critical processes and dependencies, then create the proposed recovery strategies you’d most likely implement if that process fails. And then you test to see if there are any gaps.
Of course everyone’s program and culture are going to be slightly different. But tell me if the following steps sound familiar:
- Interview key leaders to determine their priorities. Do it whenever they will meet with you, which will be at 1 a.m. on a Saturday.
- Create a BC steering committee filled with people that show up only after you beg them or after you wait by their car each evening after work.
- Create a program policy and general risk assessment in a vacuum. Constantly remind people we have a policy.
- Convince your executive a BC software tool will be helpful. Go through a rigorous process to find just the right one.
- Implement selected BC tool and become the only primary user. Prepare to hold laptops up to users’ faces and tell them what to type when they finally log in.
- Make every work unit in the entire company complete a business impact analysis (BIA). Explain what BIA means 4,000 times. Review this information for weeks and then try to get anyone who will listen to look at it with you. (Spoiler alert: No one really will.)
- Create recovery strategies for each of the 10 risk scenarios you’ve identified ... by yourself.
- Reset everyone’s password to the BC software tool 37 times a piece.
- Write plans and checklists and arrange exercises to test the people who haven’t read the plan or checklists.
- Realize it’s been a year and think about why you’re doing this work and where it all went wrong.
Where Did It All Go Wrong?
At the end of this traditional model you end up with a few very positive things. You will have process mapping data. You will have recovery time objectives (RTO). You will also begin to create BC plans for a specific scenario. And you possibly can make the case, that there is some understanding of BC practices amongst a large segment of your organization. But you also end up being about six to 12 months down the road.
And unless your business has a super emergency after this point, and every single plan is activated all together, it will be very difficult to convince people that this is all worth it.
I think there are three main factors why this cycle can be a bust and unsustainable.
Too time consuming.
This process can easily consume a year of your time, especially if you’re a one- or two-person operation. By the time you set up everything, conduct a BIA, develop recovery strategies, and get a physical printed plan to show off, it can be close to a year. What are you going to do if you have a business disruption in the first two months after you start? And how long can you expect anyone to wait before you can demonstrate that you made the business more resilient?
No undeniable value.
It’s already very difficult to demonstrate value around a support function like business continuity. So, if you’re spending all your time sucking up money (time and tools for BC) and you haven’t made anyone really aware of the benefits of BC, you will end up with the classic question: “What does BC do again?” The truly “all-in” organization should be able to speak to one or two reasons why you’re there. And in my experience, plans aren’t the thing that makes people love your program.
Lack of clear wins.
Just because you have a documented plan, how does that translate into reduced risk? The traditional BIA may help you understand key information like critical processes and your RTO. And maybe during the effort, you find some areas of concern. But did you fix them during the cycle? This model doesn’t tend to yield very specific results or give you the ability to eliminate a single point of failure right away. You will need to dive deeper to accomplish that.
In my next article, I’m going to explain how thinking about a BC program in the same way you approach a new romantic relationship can bring completely different results. By making changes at the front end of the BC cycle, when you first meet and begin establishing your relationship, you can really change the way you generate interest and set yourself up for a relationship no one could resist.
Shane Mathew, vice president of professional services at Virtual Corporation, oversees the consulting and software implementation. Prior to joining Virtual Corporation, Mathew served in various leadership roles within business continuity and emergency management in both healthcare and governmental organizations. Mathew has led the creation and implementation of business resiliency and risk identification programs for several organizations, including governmental, medical centers, and a multi-site, national pharmaceutical division of a global healthcare organization.