Archive for BIA

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?

The BIA Insult

So, I came across this quote the other day that someone was using in a presentation about the importance of conducting a Business Impact Analysis (BIA):

“A business continuity plan that is not predicated on or guided by the results of a business impact analysis (BIA) is, at best, guesswork, is incomplete, and may not function as it should during an actual recovery.”


I understand what they mean and I appreciate this message given to business continuity planners, but, I would hesitate saying this in a board room.  It may not be wise suggesting to the CEO and other senior executives that they do not know their business well enough to tell you what is important to them and what business processes are necessary to keep their organization solvent.

I have long since been of the opinion that business continuity planners have become victims of our own methodology.  I think many of us have lost sight of the why’s and wherefores of what we do and have become too caught up in the whats and how we do things.  And, I think, the BIA is a prime example of this.

Ultimately, why do we conduct a BIA?

I suggest that we perform a BIA to establish the objectives for our Business Continuity program.  We gather and analyze the impacts of a business interruption in terms of financial impacts, reputational impacts, operational impacts, legal and regulatory impacts and other impacts unique to our company or industry.  Armed with this measurable and intangible information, we can make an educated and informed decision about what business processes we need to continue – and, in what timeframe – to minimize our losses and keep the organization solvent following some sort of devastating business interruption event.

I like to break down the standard Business Continuity Methodology into the Strategic Planning Phases and the Tactical Planning Phases.  The Strategic Planning Phases consists of the Risk Analysis, Business Impact Analysis, Recovery Requirements Analysis and Cost Benefits Analysis of viable solutions.  The Strategic Planning part of the methodology helps us define “what” our business continuity plan should achieve.  The Tactical Planning Phases of the methodology define “how” we achieve our objectives.  This includes, implementing the chosen solutions and documenting the policies, plans and procedures.

But, I don’t believe the Business Continuity Planner is always needed to define the Strategy.  I think, in some instances, the “strategy” can be given to us by the CEO, board or other executive management team members.

What if the CEO told you what business processes they want to continue, in what time frames?  Are you going to tell him/her that that would be creating a BCP based, at best, on guesswork?

I know that the methodologies say we MUST CONDUCT a BIA.  But, I think that that requirement is a little bit tangled up.  I think it is absolutely correct to say, before you can  successfully implement a viable and effective business continuity plan you must establish your recovery time and recovery point objectives; you must identify and categorize your business processes in terms of criticality and importance to the sustainability of the organization and the ability to satisfy the corporate mission; you must know the dependencies and requirements that support those critical processes to ensure a complete and holistic recovery solution – but, I am not sure a BIA is always what is needed to get these “strategic” parameters.

Yes, I have been in many a situation where the leadership team was not comfortable in establishing these objectives without the support of information gathered and analyzed through an in-depth BIA.  I have also seen many a business continuity planning team chastised for spending months on gathering and analyzing information simply to conclude in telling management teams what they already knew.  And, I have seen business continuity programs fail at time of an event because they were predicated on the findings from a BIA that were never verified and matched against management’s expectations, which were significantly different from what the information gathered suggested.

Now, I am not against BIAs.  I have made a nice living by conducting many a BIA over the past 20 years, and I do believe they are valuable and necessary tools – just not in every case.    I caution business continuity planners not to become so married to the methodology that you lose sight of what the objectives are for each methodology component.  If the objective of a BIA is to establish the continuity and recovery objectives of your business continuity program and the executive team in your company knows and are willing to sign off on recovery and continuity objectives that are given to you – do you really need to conduct the BIA?

In any case, I don’ think I would ever suggest that a business continuity plan not based on the findings from a BIA is guesswork, especially if the guesses are coming from the Executive Management Team.  I just know that if you came into my company and told me that a team of business continuity planning specialists are needed to identify what our critical processes are, I would be showing you to the front door.

Are RTO’s Stagnant? Should They Be?

In many business continuity programs, there are known and established Recovery Time Objectives (RTO) for business processes and for IT applications.  More times than not, these RTOs are static and the response and recovery programs are built around these numbers as they came out of a Business Impact Analyses (or were merely assigned based on an educated guess).

I just wonder if it is reasonable to assume that recovery priorities remain the same throughout time.  And I am not necessarily questioning whether they remain the same over time – but are they the same at different points in time throughout the business year or business cycle?

For example, is it reasonable to assume that our recovery priorities, or RTOs, might be different if the disaster occurred at month end or at year end as opposed to some other time in the year?  Might our recovery priorities be different if we are in the middle of launching a new campaign or product or service?

And, could the disaster itself influence our recovery priorities?  Could RTOs be different if we experience a data center only disaster versus a disaster that also impacted our workforce?  Could our recovery priorities be different for a single-site disaster versus a multiple site disaster?  Could we have different RTOs if we knew that the downtime was going to be hours or days versus weeks or months?

Now, I hate to over-complicate things in the planning process.  I am always warning folks to avoid paralysis by analysis in the planning process, but I think these are legitimate questions to pose to mature and solid programs that are looking to continue to improve and strengthen their recovery posture.

This is also why I think it is important for your recovery program to include a well thought out and implemented Crisis Management component that gets the right decision makers together and empowers and enables them to make changes to the recovery process as the situation, at that time, dictates.  So, maybe we maintain our single RTO, but we have the infrastructure in place that can accommodate changes in our recovery priority if and when needed.

Just something for the experienced planners to thing about and challenge their teams to consider in the maintenance and improvement process.

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.

The Recovery Requirements Analysis

I have been in more than a few BIAs or business continuity planning sessions when it is like pulling teeth trying to get business managers to identify the applications and/or other requirements and resources they need to minimally perform their mission critical business processes.

This is especially true when working with financial traders.  First, they under-estimate their need for tools and resources, believing that as long as they have a phone, they can conduct trades.  But then the list of requirements grows and grows.

A typical requirements analysis session with traders might go like this:

ME:  What do you minimally need in an alternate site to conduct your business?

TRADER:  I don’t need anything.  Just give me a phone and I can trade anywhere.

ME:  So, all you need is a phone?  You can trade with just a phone.

TRADER:  That’s right.  Just a phone.  Well, I also need my data feed.  But, just a phone and a data feed.

ME:  Nothing else?

TRADER:  Well, I need a phone, my data feed and the blotter system.  Just a phone, data feed … oh, and I need trade tickets.  Just a phone, my data feed, the blotter system and trade tickets.  That’s all I need.  Oh, and I need my directory of phone numbers… and a recorded phone line.

Does this sound familiar?

Here, check out this link to a secretly videotaped, recovery requirements session I conducted with one business manager:

Recovery Requirements Analysis Video.

Okay, so I am being funny.  But, if you have done this for as long as I have, I am sure you shared in the laugh.  I have used this routine in a few public speaking sessions I have done on business continuity planning.  It is always a good trick for getting my point across and keeping the audience awake.

And maybe, just maybe, I am being a Jerk!