BCM & DR: Internet Radio Show Coming Soon!!

STONEROAD ANNOUNCEMENT: Internet Radio Show Coming Soon!!

Today, we’d like to announce that StoneRoad founder, Alex Fullick, has signed a contract with World Talk Radio LLC to establish a 13 week talk radio show about all things related to Business Continuity Management (BCM) on the Variety Channel.  Continue reading

Reporting DR & BCM Program Status as Red

 

I’ve noticed recently that many individuals working on various projects and programs, including Disaster Planning and Business Continuity, seem afraid to actually communicate some of the difficulties they’re encountering.  Continue reading

BCM & DR: Mergers & Acquisitions (Part 2)

As noted in Part 1, if you’re going to be merging all areas of the two companies and the acquired will be engulfed or swallowed up by the acquiring company, then BCM/DR has a very large workload ahead of itself.  In some regards, it’ll be like starting over but you’ll know half the BCM need already.  Continue reading

The 4 R’s of Disaster

When the director of technology states that the IT infrastructure is up and available after a disaster, many believe it means that an organization can now begin to operate as normal. This is not completely correct; it’s only part of the solution. It’s like a car salesman pointing out a car on the lot; just because it’s sitting there doesn’t mean it’s ready for use – you need gas, a key and other bits before it’s ready for use. So, just because the technology infrastructure is ready, doesn’t mean it’s ready for use.

What’s happened is that the infrastructure has only been restored; the organization still needs other components in play before it can safely say it is back to operations – not necessarily ‘normal’ operations (Is it ever ‘normal’ to operate in disaster mode??). Yet when technology is restored there is the misconception that all must be well.

I like to keep 4 R’s in mind when an organization is getting back up on its feet after a major situation. Below describe four key stages that an organization must go through before it can state – confidently – that it’s back open for business – albeit, no doubt at reduced capacity and capability.

1. Response: Basically, this relates to the initial responsive activities an organization takes when a disaster occurs. It would include such things as evacuation & assembly procedures, communications (internal, external), crisis management, DR team activation, 1st aid/CPR assistance and other basic activities.

2. Restoration: This focuses on the restoration of technology/IT equipment and services. It does not automatically mean that once a server or application is restored that all is ‘well’ once again in the world. That’s not it al all. What it does mean that the organization has been able to get all the pretty green lights on and systems are restored. All the systems can ‘see’ each other, cables are connected and power is running to everything. The technology infrastructure is now ready for the next step.

3. Recovery: Recovery focuses on data. What data do you have? Have you lost any? Is it corrupted? What was lost when systems failed (regardless of the trigger)? Can you access it? It means obtaining the data (from whatever source) and validating that is usable (i.e. not corrupted) and available for users. It’s also to ensure that systems are actually speaking to each other; that files will pass from one system application to another, as expected. If they can’t, then there is an issue with the technology set or potentially with the data itself. In some instances, an IT and business user will validate that data has not been corrupted and if it is OK, it’s time to move to the next phase. If not, IT must go back and obtain the last set of data files that are OK and not corrupted but if not, users are now brought in for resumption.

4. Resumption: Resumption relates to the end user; the person using the recovered data that moves between the restored systems. This is the final step in the 4 R’s. Once systems are available and data has been validated and available for use, the user now can begin to perform their business operations in the order and frequency dictated by the departments Business Continuity Plan.

Some might say you can incorporate a 5th “R” to the mix; review. However, ‘review’ would actually fall into the maintenance category and the continued review of existing plans and procedures that aren’t just attributed to a disaster occurring. Review would occur after testing and validation for lessons learned and ensuring that disaster team members are kept up to date on expectations and reviewing various other BCM/DR program components (plans, processes etc) to ensure they are current and maintained on a regular basis. The 4 R’s strictly relates to a disaster situation.

The other part with review is that you can do this after a disaster has occurred or some other organizational incident, as a lessons learned. Review how you did and what needs to change.

Sometimes using quick little items like “the 4 R’s” can help illuminate the minds of executives that don’t fully understand – or pay attention to – BCM/DR.

(C) StoneRoad (A.Alex Fullick) 2013
Alex Fullick is the author of several books including his latest, “Business Impact Analysis: Building the Foundation for a Strong Business Continuity Program” (Available at http://www.amazon.com or http://www.stone-road.com/shop.)

Crisis Management: When Does a Crisis Start?

Many of us don’t hear about a crisis until it hits the newswires, either through social media, news websites or through a posting on a social site we might follow. In some cases, we might not know about a crisis until we see 1st responders racing down the road heading towards and emergency.
Some will automatically see a disaster as a large catastrophe and one of the BCM/DR industry definitions of a disaster is that it’s a sudden, unplanned event that prevents the organization from performing normal operations. Though both a crisis and/or disaster can start well before the public or media even get wind of the problem.
Sometimes a disaster doesn’t begin until after a period of time when a lesser level of operational hindrance has been experienced. Then when the disaster itself occur, the management of the situation will determine the level of crisis; meaning how well the crisis is handled from the perspective of the public, media, stakeholders (vendors, partners etc) and employees.
For an operational impact, it could be that a key application is offline but is that a disaster? Probably not. If the offline application has a major impact upon people causing major distress and problems such as something in health care or the financial industry, then yes, that application being offline – even for a short time – is a disaster. How the immediate response and post-disaster activities are managed is what will create the crisis for the company. If you get something up and running within a very short time (and in today’s world that’s usually no more than an hour) then it might not be a disaster and a quick response and communication to the community will suffice. If it’s longer, then the management level and involvement of the situation and the level of impact it has becomes a disaster.
Still, if an organization has an internal Crisis Management process in place, early identification and response measures may prevent the incident from escalating and becoming a crisis – or a disaster if nothing is done about it – in the media or public eye. It was just an incident that didn’t have any major impact. Oddly enough, it could have been a major interruption but the impact on Service Level Agreements (SLA), employees, customers, vendors and partners was limited in size and scope; it was just a major incident for the company involved because of the resources (financial, time, personnel) it took to get resolved.
So, when does a crisis start?
It starts the moment the organization believes that someone – anyone – will begin to ask questions. It could be a client, employee (who will access social media about it if they haven’t been educated about not communicating corporate activities), vendor, partner or in some cases a financial institution or legislative body. An organization may be able to manage the situation internally with little impacts being had on external – and internal parties – but as soon as questions are asked about the disruption, you have the start of a crisis. It’s how well you manage those initial questions – along with the incident response itself (I.e. getting the critical application up and running as soon as possible) – that will determine how big the crisis escalates. If you don’t manage it properly the crisis will grow and escalate, making it a ‘Public Relations’ disaster.
The start of a crisis is different for every organization. It all depends on the level of preparation, preparedness and response is developed and instilled within the corporate operations. If an organization doesn’t have anything developed or the level of development is sub-par and very ‘flimsy’, the crisis starts quickly and escalates quickly – reaching that “PR” disaster timeframe in record time.

**NOW AVAILABLE**
Books by StoneRoad founder, A.Alex Fullick, MBCI, CBCP, CBRA, ITILv3.
Available at http://www.stone-road.com, http://www.amazon.com, http://www.volumesdirect.com

12 Tips, Trips & Traps: The Business Impact Analysis (BIA)

Hello dear readers!! We’ve been a bit quiet lately over here at StoneRoad due to multiple vacations (Singapore, Australia, New Zealand and more) and now that we’re all back, it’s time to start posting once more. Enjoy…
The StoneRoad Team
**************************************

**The below section is an abbreviated bonus taken from the Appendix of the book, “Business Impact Analysis (BA): Building the Foundations for a Strong Business Continuity Program” by A.Alex Fullick. The full text can be found in the aforementioned book.**

Business Continuity Management (BCM), like most corporate programs, is often plagued by common mistakes; these common mistakes also apply to the Business Impact Analysis (BIA. The following are some common mistakes that need to be addressed to ensure that the BIA is effective:

1. Minimal Management Support – Senior management must buy in to the need for continued maintenance of the BCP program. The program requires on-going resources to ensure that the program is funded and there are dedicated resources assigned across the organization. The people who head up the BCP program must have the requisite training, as well as the skills to provide leadership, prioritize tasks, communicate with stakeholders, and manage the program.

2. No Timely Follow Up of Results – A BIA is conducted almost always in support of an enterprise-wide business continuity program. The real value of a BIA is the follow-up activities that lead to effective recovery strategies being implemented based on the BIA priorities of the business processes. Occasionally, so much effort and cost is put into the BIA that business continuity planners never get around to fully implementing the follow-up recovery strategies and plans. Without the implementation of these follow-ups, the value of the BIA becomes wasted.

3. No Agreement on Scope (Level of Detail) – This level of detail can span an entire spectrum. On one end, some BIAs will contain relatively little detail to provide a higher-level executive view of the analysis. On the other end, and far more prevalent, are BIAs that include for each business process its corresponding input dependencies, output dependencies, recovery point objectives, recovery time objectives, and financial impacts. The common mistake here does not involve selecting the right or wrong level of detail – what’s appropriate for one company may be totally inappropriate for another – but rather, failing to reach agreement among all relevant parties as to what level of detail best meets the requirements that are driving the BIA in the first place.

4. Minimal Executive Support – One of the factors that most influences the relative success of a BIA is the degree of executive support offered at the outset. The kickoff process usually consists of two parts: a widely distributed email and an initial presentation. The email should come from the highest level executive sponsoring the BIA and should be distributed to all parties who will be participating in the effort. The email should emphatically voice the executive’s support for the project and insist on the support of al participants, particularly during the interview process.

5. Poor Questionnaires – An important step of any BIA is the collection of data from business units. The manner in which this data is asked for often spells the difference between a full, timely and meaningful collection of data, and one that is delayed and incomplete. One of the best ways to avoid this situation is to develop survey forms that are thorough enough to capture all relevant information and simple enough for business users to complete quickly and easily.

6. Lack of Preparation for Interviews/Workshops – Interviews are the cornerstone of a successful BIA, yet few planners prepare adequately for them to ensure their effectiveness. Interviewers need to learn as much as they can about a given business unit prior to the meeting, including a thorough review of the respondent’s survey.

7. Lack of Critical Focus – Analysts frequently make the mistake of asking business users ‘what are the most important business processes within their department?’ The reason this is a mistake is because virtually all critical business processes have a large degree of importance and value – otherwise they would not be designated as critical – resulting in less likelihood of it being easy to prioritize processes according to value or importance. A much better question to ask is ‘how long can a business process be idle before major impact is felt?

8. Focusing on the Tools Instead of the Process – Some analysts who conduct BIAs become very focused on the tools they will be using in the collection, compiling and analyzing the data provided by the business users. The emphasis often shifts inappropriately from the process being used, to the automation that can be applied to the process. There is an inherent flaw in this approach. If a poorly designed manual process that is being used to collect and analyze the data suddenly becomes automated, what you typically end up with is a poorly designed automated process.

9. Ineffective Interviewing Technique – I have known more than a few BIA analysts who preferred to rely solely on surveys, questionnaires and emails to collect needed data. The example previously cited concerning the over-focus on tools shows how this can less than desirable results. Analysts often say that setting up interviews can be more hassle than it’s worth. They will mention how interviews often start late, or may be cut short, or have to be re-scheduled, or cancelled altogether. In my experience, the real reason some BIA analysts try to steer clear of face-to-face meetings is that they tend to use ineffective techniques when interviewing business process owners.

10. Insufficient Results Analysis – Analysts conducting a BIA collect a wealth of information during the course of their efforts. But the value of this information is sometimes diminished by poor or incomplete analysis of the data. Analysts need to look for trends, patterns, relationships and discrepancies among and within the data to ensure a thorough and meaningful analysis.

11. Unclear Presentations – Data that is thoroughly collected and well analyzed is sometimes de-valued by an unclear or confusing presentation of the information and results. Managers in general and sponsoring executives in particular, expect BIA analysts to summarize their results in high-level presentations that are succinct and effective. Unfortunately, this does not always happen. Analysts gather a huge amount of data in the process of conducting BIA. In compiling and analyzing this data, analyst sometime err on the side of presenting too much information rather than too little.

12. Undefined Scope – Often, the BCP focuses entirely on system restoration. Resumption of business needs to include the people and processes required to resume operations. Many BCP programs are headed up by IT departments. ‘Tunnel vision’ can often cause these departments to focus on system recovery and not take the people issues into account. During an event, the people issues are often the most difficult to resolve. The scope of a business impact analysis (BIA) pertains to the number of business units, such as Finance, Administration and IT, which will be participating in the effort.

Don’t let your BIA efforts fall to the wayside; make sure you have strong BIA approach and you’ll end up with a strong BCM / DR program.