BCM & DR: Managing Expectations

Have you ever gotten to the end of your journey to find you’re not in the place you thought you’d be – or wanted to get to?  It’s that way for many projects and programs, including BCM/DR initiatives.  Sometimes what you intended to achieve isn’t what you end up accomplishing – if at all.

Developing and the maintaining a Business Continuity Management (BCM) / Disaster Recovery (DR) program means managing – and sometimes juggling – multiple components.  You could be juggling Business Impact Analysis (BIA) reviews while starting to plan the next major Simulation Exercise.  This is common and in project management terminology, it’s a bit of an Agile approach; not your traditional ‘waterfall’ approach (e.g. end one task before starting another).   When this occurs, you do run the risk of overlapping initiatives and sometimes, overlapping approvals being required.   But don’t think that your approvals can be delayed or rebuffed; they are important.

You need to ensure that if you are planning a simulation exercise, that the scope is approved, the team membership is approved and the approach you taking is approved (among other aspects).  That doesn’t mean three different approvals but an approval by your program sponsor that what you intend to do – or what she has determined should be part of the next exercise – is approved.  If you’re planning an exercise without getting clear approval on the scope, you’ll end up with major scope creep; meaning, as you plan, more and more activities get added to the test, which without proper approval in place, can cause problems for those participating.  Here’s a small example I personally experienced a few years back when planning a test.

I want to say that we were still planning the test rather than testing the plan at this stage, as we were still building but did get to the ‘surprise’ test a year later, where we really did test the plan (and not plan the test).

We had the scope captured and approved (even a PDF file of the signed of document with signatures from the two program sponsors) available to all test participants.  We referenced that scope document quite a bit as we planned our activities and what we needed.  So when people asked questions about what was in scope and not, that document go pulled out quite a bit, especially by me as the test coordinator/project manager.  Well, with each of us having our own PCs and laptops, many people have completely different ‘shortcuts’ on the desktops or in a file.  An organization might have thousands and thousands of differing shortcuts spread over the various laptops and PCs residing in its facilities.  As you can imagine, trying to manage that within IT would be next to impossible, as the majority of shortcuts would be personalized by the user.  So when were asked to include personal shortcuts with regards to the test to ensure people’s personal shortcuts came up on test machines, it was quickly squashed by the Project team (me included), IT and by the Program sponsor.   If we had included that without getting appropriate approvals, we could have spent my cycles – and money – on creating a process that didn’t exist at the corporate level to start with – all for a test.    And then not known what value it would have provided but if we’d encountered a problem with it then we’d have run into the possibility of having test issues that weren’t related to the actual scope of activities.  A complete misalignment of goals and direction.

Yeah, yeah I hear you saying; what does this have to do with BCM/DR?  It’s the same point made; if you don’t get approval on findings such as BIA results (including RTO’s, RPO’s etc.), then as you move forward those key things are left behind or interpreted differently.  When that happens, the next component that comes along – let’s say, BCP development strategies after BIA results – you end up with strategies developed (and then eventually tested) that don’t align with what the actual findings were because the findings were never approved or agreed-to in the first place.

Get your approvals as you move from one component to the other because there is a ripple effect as you move forward; the mistakes made – or not confirmed or identified at the start – will reverberate into the future BMC/DR work.  It’s also good to have approvals on file for audit purposes ‘cause you know someone will ask at some point (I would).  And if you can’t get approval because there’s too many questions or outstanding items to be addressed, then don’t seek approval.  It’s that simple.  If you haven’t received what you needed and work is still in progress, executives (or others) aren’t going to provide approval on something that has yet to complete.  Do your due diligence and ensure when you are asking for approval you’re asking when the work is done and that the work that needed doing, is clearly defined – providing you with the information you need to move to the next step.

© StoneRoad 2017

A.Alex Fullick has over 19 years’ experience working in Business Continuity and is the author of numerous books, including “Watch Your Step”, “BIA: Building the Foundation for a Strong Business Continuity Program” and Testing Disaster Recovery and Business Continuity Plans.”


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s