Tag Archive for BCP

The Business Continuity Planning Objective (Hint: It’s not to implement the BCP Methodology)

So, I was recently helping a colleague prepare a management presentation to discuss her plans for advancing the business continuity program in her company.  Maybe it’s just a matter of semantics, but we had a lengthy discussion over “objectives”, “goals” and “tasks”.

If you have read any of my recent blogs you might recognize a pattern in which I think business continuity planners have become victims of our own methodology.  This discussion helped me to emphasize that point.  When I suggested to my colleague that she should first succinctly define her objective, she merely listed the steps of the methodology.  I strongly disagree.

A business continuity planner’s objective is not to complete the BCP methodology.  The methodology is simply a recipe towards achieving an end.  What is that “end” you hope to achieve?  That “end” is your ultimate objective.

So, we started with: “To provide the company a means in which they can recover from (or continue operations through) any business interruption event that impacts their operations, facilities, employees or workflow.”  I am sure you can improve on this sentence, but, it is a good start – and, it helps set the right mind frame.  Regardless of what any auditor thinks or what any other professional has led you to believe (especially those with a vested interest in having you follow a given methodology), the business continuity planner’s job is not to execute the BCP methodology; your job is to prepare your organization to successfully respond to, continue critical operations through, and recover from a business interruption event.

Now, it just so happens that one of the best ways to achieve that objective is to follow the standard methodology, but, with this understanding of our ultimate objective we can better assess what components of the methodology are needed for our situation and determine what, if any, adjustments to the methodology we need to make to achieve this objective for our particular company.  We simply need to ask ourselves – about each component in the methodology – is this needed and how is it best used to achieve our objective?

With this thought in mind, I like to reorganize the standard methodology a bit and divide the components of the methodology into the Strategic Planning Components and the Tactical Planning Components.  Strategic Planning Components of the methodology help us define “what” our program should accomplish and the Tactical Planning Components help us describe “how” we accomplish these strategic goals.  The diagram here depicts this re-organization of the methodology.  (Click on the diagram for a better view.)

Methodology

If you think about the BCP methodology as a recipe for baking a cake, the Strategic Planning Components are needed to decide what kind of cake we should bake, how big it should be, what ingredients are needed to bake it and how long it should take to bake it.  The Tactical Planning Components are needed to ensure we have access to everything we need when the time comes to bake the cake, and, have the instructions for actually baking the cake when it is required.  The methodology also suggests we practice baking this cake a time or two before having to serve it for real – a good idea if you have never baked a cake before – and, making whatever adjustments are needed to constantly improve the cake and the baking process.

Now we get to a question that is becoming a topic of conversation for many business continuity planners: if the Strategic Planning Components of the methodology help us define what kind and how much cake we should bake, are they necessary if this is told to us by our management team?

This is where I think we often fall victim to our methodology.  I think we must ask ourselves – who is our customer?  Who are we designing business continuity programs for?  The methodology is not our customer.  The auditors are not our customers.  The CEO and/or Board of Directors are our customers.  In my mind, the key phrase in every BCP/Disaster Recovery/Emergency Response regulatory requirement is the one that states these plans/programs must be consistent with management expectations and approved by the Board of Directors.

I think that if Senior Management dictates the strategy to the business continuity planner and then approves the solutions put in place to achieve those strategic objectives, it is less important that you can tick off having performed every task within the BCP Methodology – even if not being able to do so upsets the auditors.  Furthermore, the business continuity planner who follows every step of the methodology to the letter and implements a solution that is not consistent with management’s expectations – has not done their job.

At the end of the day, the business continuity planner must ensure that their organization is in position to effectively and efficiently respond to and recover from any business interruption that impacts their organization.  I say, if you can achieve that – you have done your job, with or without having completed the entire BCP methodology.  Now, some will challenge and say that short of actually experiencing a disaster, the only real way to ensure that you have achieved this objective is to complete every step of the methodology.  I believe that the real proof is in the design and execution of the exercises and tests you perform.  That, to me, is the real challenge – good, complete and verifiable exercises.

But, my real objective for writing this blog is not to convince anyone that they shouldn’t follow the BCP methodology.  I think, in almost every case, even following my theory here, you will eventually determine that the standard BCP methodology is the best means for getting your job done.  I just wish to get business continuity planners to understand what their ultimate objective is and not to simply follow the methodology because they think they have to but to understand why they are following the methodology and help ensure that everything they do – every step they follow in the methodology – can be tied back to achieving this ultimate objective.  In this way, I believe, you can design your implementation of the methodology in a way that does not waste anyone’s time and effort in gathering information or conducting analyses that do not contribute to the final objective.

I think my colleague got the point and her management presentation was well received.  So, I think, I can count at least one practitioner that now sees my point.

Business Objectives vs Business Continuity Objectives – The Missing Step

This blog article talks about a step in the Business Continuity Planning (BCP) Methodology that I think is missing – and, I happen to think it is a pretty important step.

One of the greatest challenges in the BCP methodology is in establishing the program’s recovery objectives.  Whether you label them as Maximum Acceptable Downtime (MAD); Recovery Time and Recovery Point Objectives (RTO & RPO); or some other creative anagram unique to your process, these program benchmarks are usually arrived at through a Business Impact Analysis (BIA) process or, at least, through some survey/interview with business managers and subject matter experts to establish what the critical business processes are; what timeframes they must be recovered; and what resources must be available in certain timeframes to enable our continuity or recovery of those processes.  Does this sound familiar?  I’m I right, so far?

But – you knew there was going to be a but – to achieve what end?  I mean, we do a great job defining business continuity objectives, but do we do so against established business objectives?

I always thought that the savvy business manager, when asked to complete a BIA questionnaire would ask the question, “What is Senior Management expecting me to achieve during the business interruption period?”  Sometimes, I think, we get close.  Many times I hear business continuity planning professionals say that the objective is to “survive” the disaster or “keep the company solvent”.  But do we ever define what that means – in business objective terms?

So, forget about operating in disaster situations for a second.  Just think about business as usual objectives.  Most every company and most every department within each company has established business or performance objectives.  There are defined revenue targets, income objectives, margin targets, production objectives, etc.  There are expected number of widgets to produce per week; sales targets; number of calls handled per hour; items sold; and so on and so on.

What I would want to know, if I were the business manager being asked what my critical processes are and how long can we go without performing those processes, is:  What adjustments are being made to my performance objectives during this incident you are asking me to plan for?  Am I expected to still achieve my revenue target, sales target, income target, margin targets?  Am I still being measured against growth?  How many widgets per day am I expected to still crank out?  If you can tell me what my management is expecting me to produce during this contingency period, I can then tell you what I need to do, when I need to do it and what I need to get it done.

Seems to me, we miss that step.  We make middle management guess at what our business targets are.  And, furthermore, we never ensure that their guesses are consistent with one another.  Each individual manager who completes the BIA makes their own assumptions about what the overall business objectives are during a business interruption event.  Seems a bit risky to me.

I understand why and how this happens.  It is primarily because middle management is more accessible in our planning process.  It is much easier to include middle management in the planning process, feed them the BIA questions and get them to assign MADs, RTOs and RPOs than it is to include Senior Management in the process.  But – there’s that damn word again – how can we really define viable business continuity objectives if we don’t first know our business objectives during time of an event?

I wonder what would happen if we tried?  I wonder … what if you posed that question to upper management?  What if we added that step in our BCP Methodology:  Define adjusted business objectives that must be achieved during a serious business interruption event.  IN BUSINESS TERMS – not in BCP terms.  Interesting.

Anyway, just a thought.  What do you think?

Having Plans vs Being Prepared – Avoid the Oops

I have recently posted a couple of blogs discussing the difference between Planning and having Plans.  In this blog, I want to explore the difference between Having a Plan and Being Prepared.

I have been in a number of environments where I thought the organization had great business continuity or disaster recovery plans – but, I did not believe that they were prepared to recover from a business interruption event.

Most plans rely on a number of “enablers” that have to be in place in order for the plan to be successfully executed.

First and foremost, the physical environment that the plan relies on has to be in place.  I have gone into a number of situations where the Executive Teams were convinced that their planning team had put great plans in place and I had to be the one to tell them that the plans were based on infrastructure not yet put into place.  “Yes, your plan is to recover applications in an alternate recovery site, which is a terrific plan … but you have not invested in or built out that site yet.”  Oops.

Secondly, the plan must be socialized and known by those who must manage to the plan.  I have seen some great plans sitting on shelves, known by only those few who wrote the plan – but all the people that would have to oversee and manage the execution of the plan had never read or been educated on the plan.  Oops.

And, third, in order to really be prepared, you must test, exercise and drill the plan.  It is through tests that you validate the correctness of the plan; through exercises that you discover ways to improve the plan; and through drills that you condition people on how to respond when executing the plan.  I have been in many environments where the plan may be understood by everyone, but never physically put into action to see if it will actually achieve the intended results.  Oops.

So there is much more to being prepared than to simply having a good plan.

Having just passed the anniversary of the D-Day invasion, perhaps that will serve as an example of what I am talking about.  There were relatively few people that actually “planned” the invasion.  And only a few more that were educated on the plan.  But, 10’s of thousands of others that had to “prepare” for it, in order for the plan to work.

It only takes a few people to create a good plan … but, it takes an entire organization to be prepared.

Don’t let your good plans fail because of an oops.

The Adjusted Recovery Confidence Factor – Repeat Blog

Over the past few weeks I have actually had a few people ask me to send them the link to an earlier blog I posted about an Adjusted Recovery Confidence Factor.  Since there actually seems to be some interest in this idea – and, since I am really busy working on client deliverables – I have decided to take a blog short cut today and simply redirect you to an article we posted a few months back.

The Adjusted Recovery Confidence Factor

We had much less blog site traffic when this was originally posted so maybe its not a bad idea to put it out there again.  Any thoughts?  We would love to receive more comments on our postings.

Thanks.  And now, back to work.