Business Impact Analysis (BIA): It’s Never Right the First Time!!

If you’ve been working in the Business Continuity Management (BCM) or Disaster Recovery Planning (DRP) industry for some time you’ve probably been through a Business Impact Analysis (BIA) project; either from the very first initiation or through a maintenance phase. And if you’re honest with yourself, it probably didn’t go as well as you would have liked. Continue reading

BCP/ IT DRP Plans: Never Consider Them Complete

All organizations with a Business Continuity Management (BCM) or Disaster Recovery (DR) program always strive to have their Business Continuity Plans (BCP) / Disaster Recovery Plans (DRP) in a state they can use: in a state they believe will cover them in any and all situations. They want their plans to at least cover the basic minimum so that they can be responsive to any situation. But if an organization takes its program – and related plans – seriously, then these plans are never fully complete.
For a plan to be truly viable and robust, it must be able to address as many possible situations as possible while at the same time must have the flexible enough to adapt to any potential unknown situations. If it’s ‘carved in stone’ it makes a bit tough to adapt the plan to the situation (the situation won’t adapt to your plan).
This flexibility – and it’s maintenance (which keeps the plan alive) – includes incorporating lessons learned captured from news headlines and then incorporating the potential new activities or considerations that may not be in the current BCM / DRP plan. These plans aren’t quick fixes or static responses to disasters; they are ‘living and breathing’ documents that need new information to grow and become robust. This is why they should never be considered as complete; as the organization grows and changes – and the circumstances surrounding the organization changes – so to must the BCM and DRP plans.
It’s like trying to pin a cloud to the sky; it can’t be done. A BCP / DRP plan can’t stand still; it must be flexible, adaptable and continue to grow.
Risk profiles and risk triggers will continue to change as the organization develops and implements its strategic and tactical goals and objectives – the BCM program and plans must be able to follow along to assist in ensuring the organization can respond to a situation that might take them off their strategic path. A good plan or program is not a destination, it’s really a desired state of being where plans and processes are nurtured to grow and expand – it’s not a plateau you reach and then stop.
So if you want the best BCP / DRP plans to address as many situations and scenarios as possible when your organization is hit by a disaster, understand that to ensure they do just that, don’t ever consider the plans complete. Think of them as an entity that needs to grow and needs attention, otherwise when you need your plans, they won’t be able to help you because they’d reflect contingencies and strategies that represent the company when the plan was first developed – which could be years earlier.

© StoneRoad 2014
A.Alex Fullick has over 17 years experience working in Business Continuity and is the author of numerous books, including “Heads in the Sand” and “BIA: Building the Foundation for a Strong Business Continuity Program.”

Regards,

A.Alex Fullick, MBCI, CBCP, CBRA, v3ITIL | Director, Stone Road Inc. | 1-416-830-4632 | alex@stone-road.com

“Failure isn’t about falling down, failure is staying down…” – Marillion

Business Continuity Management (BCM) / Disaster Recovery (DR) Document Templates Available for Small and Medium Businesses!!

Not every business can spend thousands and thousands of dollars on expensive software packages to get their BCM / DR programs off the ground – or has the time to get software configured and ready for use.

Having experienced these challenges first hand, StoneRoad developed a cheaper alternative: we developed document templates for Business Impact Analysis (BIA), Business Continuity Plans (BCP) and more.

Visit the StoneRoad site and go to the Shop section to view the various templates available and get your program moving with a low cost alternative to expensive software! Each template provides instructions on what information is needed so that you can build your program with less fuss – and with more results!

Here’s just a sample of our document offerings:

1) Test Scope Charter Document (Word Document)
2) Business Impact Analysis (BIA) (Excel Worksheets)
3) Operating Unit Business Continuity Plan (BCP) Template (Word Document)
4) Emergency Employee Logistics & Pandemic Plan (Word Document)
5) Test Executive Summary (Word Document)

…and more. We’re adding new templates all the time to help you. We even have BCM & DR books and ebooks available.

So download what you need and get started!

Happy planning!

Regards,
The StoneRoad Team

“Reduce Suffering Through Disaster Planning”

© 2014, Stone Road Inc.

BCM & DR Books to Help Build Your Program by A.Alex Fullick, MBCI, CBCP, CBRA, v3ITIL

The message about disasters, disaster planning and business continuity is slowly spreading throughout the globe, as we see more and more organizations beginning to realize the value of preparedness and response activities to protect their operations and instil confidence in those they do business with.

Here at StoneRoad, we’ve seen a spike in people asking us questions and seeking advice on Business Continuity Management (BCM) / Disaster Recovery Programs – and we couldn’t be happier.

So we’d like to remind you that there are some great books by our founder, Alex Fullick, that can help provide great insight into how a good program operates – and how it shouldn’t. The books noted below are available on Amazon.com and at our own shop over at www.stone-road.com.

1) Heads in the Sand: What Stops Corporations From Seeing Business Continuity as a Social Responsibility

2) Business Impact Analysis (BIA): Building the Foundation for a Strong Business Continuity Program

3) Made Again – Volume 1: Practical Advice for Business Continuity Programs

4) Made Again – Volume 2: Practical Advice for Business Continuity Programs

Keep an eye out for the next book by A.Alex Fullick; “Testing Disaster and Business Continuity Plans” expected to launch in the fall of 2014.

Until then, happy planning!!

Regards,
The StoneRoad Team

© 2014, Stone Road Inc.

BCM / DR: eBooks Now Available by A. Alex Fullick (Stone Road Inc)

We’ve been a bunch of busy beavers here at StoneRoad. We’re very happy to announce that two books by our founder A.Alex Fullick, ‘Heads in the Sand’ and ‘Business Impact Analysis’ are now exclusively available as ebooks at the StoneRoad shop.

Get your copies now using the links below:

Heads in the Sand
OR

https://stone-road.netfirms.com/cart/index.php?main_page=document_product_info&cPath=3&products_id=201&zenid=3d712e28f2680972874f7e4a8d473940

Business Impact Analysis
OR

https://stone-road.netfirms.com/cart/index.php?main_page=document_product_info&cPath=3&products_id=202&zenid=3d712e28f2680972874f7e4a8d473940

‘Like’ Join us on Facebook too at Stone Road Inc.

The StoneRoad Team.
(C) Stone Road Inc, 2014

BCM / DR: The Little Test Activities Often Forgotten

Having been a part of dozens of test to varying size and scales, I’ve come across quite a few instances where planners – including myself at times – forget to consider when organizing a BCM / DR test. I thought I’d come up with ten (10) areas that have at some point, been a fly in the ointment of test coordinators and caused issues further down the road and on one occasion, at the moment the test was scheduled to begin.

1. Production Priorities – Believe it or not, once everyone was so focused on testing they forgot to ensure that someone was left to support any production issues. While testing activities were underway, all members of a department were focused on ensuring that the test went well that no one was monitoring a production issue, which needless to say, caused allot of grief for business units. Don’t forget that even when you’re testing BCM/DR capabilities, you’re production environments are still ‘live’.

2. Test Strategy – Know ahead of time what strategy you’re going to leverage for testing purposes and ensure its communicated and agreed-to by everyone involved or else different groups will be working in isolation and not working towards the same thing.

3. Managing Scope – Keep people on track during planning and execution. If no one is clear on scope then the activities they plan and execute might not achieve the goals you’ve set. It also means that even though they might perform tasks successfully and everyone is happy, you still didn’t get what you originally planned for. It’s like being given a bicycle to get from A to B when you originally asked for a pickup truck. Sure you got to where you’re going but the goal was the truck. Did you really achieve your goal and scope if the scope and goal was to get from A to B with a truck? Nope, you didn’t.

4. Resource Assignment – When user activities are required it has been assumed the people needed will be available but often the department responsible for the resources are never approached about being part of the test and when they are, it’s too late because people are working on other initiatives. So make sure you speak with other teams early so that resources can be aligned early.

5. Change Management / Requests – This is relate to the scope; if you’re changing something – even times, dates etc – make sure everyone knows about it and that you document the desired change. Using the previous example about the bicycle and truck; it may have been a great idea to change the truck to the bicycle and it still worked for you however, the scope was the truck and there was no formal mention of changing it to the bicycle. If you’d managed it correctly and documented the fact you were going to use a bicycle, then it would have been known by everyone that the truck is ‘out’ and the bike was ‘in’ and everything would be a success.

6. Agreement – When you have key decisions made or need key decisions to be made, ensure you have agreement on the final outcome. It could be that if you make decisions without consulting impacted parties, they won’t support what you’ve determined and will continue on their original path. This only means confusion and failure further down the road. Keep everyone on the same page and part of the decision making process; if even as an FYI in some cases.

7. Documentation – Make sure you document all aspects of the test; most notably scope and goals and objectives. If you don’t who do you know you met them? You won’t even be able to talk to audit and prove you did what you set out to do because you don’t have anything that captures what you originally set out to do and quite possibly, nothing that sums up what you actually did (a test summary document).

8. Focus on Test Planning Rather Than Planning the Test – Try not to get far off the path here. It’s one thing to ensure you plan the test so that it doesn’t impact production systems or other critical aspects and it’s another to set up the test in a way that it has no relevance and doesn’t reflect what you’d actually do in a real situation. If that happens, you really aren’t testing anything. You need to know where the gaps are in the plans and that they’ll work in a real situation.

9. Test Timelines – Estimate activity sequences and schedule accordingly. If it takes 24 hours to get a mainframe up and running – from scratch – then have end users come in at the same time as the main frame team would be ridiculous, as they’d be sitting around for an entire day before they can do anything. That won’t make them happy.

10. Test Schedule – Plan ahead. When planning efforts are underway to schedule major initiatives over the next year or so, make sure that testing is part of that planning effort. This ensure that departments are aware of the test ahead of schedule and that they are able to plan for that initiative. Also, if you have 3rd party DR vendors involved, you often have no choice but to schedule test time a year in advance or run the risk of not having any time available to test, as the vendors other clients will take up all the available time.

Some of this may seem obvious but you’d be surprised how often the simply things can derail a test. Keep in mind the little things and you’ll have a great chance of success. Remember, if you have the most luxurious car in the world, it does nothing if you don’t have the key.

© StoneRoad 2014
A.Alex Fullick has over 17 years experience working in Business Continuity and is the author of numerous books, including “Heads in the Sand” and “BIA: Building the Foundation for a Strong Business Continuity Program.”

BCM/DR: Understanding Want and Need

BIA results can help determine many aspects of the BCM/DR program to come; they validate what is required – and what’s not. And what’s required and what’s not is determined through the development of the various strategies and approaches that are created as a result of the BIA findings. However, that doesn’t stop individuals of all levels from believing they know what they require for their restoration and recovery strategy regardless of what the BIA findings state.

This is because many individuals have a difficult time comprehending that they may not be the most important area within the organization and thus, aren’t required to be available immediately. And if a department – or particular aspects of a department – aren’t required immediately after a disaster, many will disregard that fact and begin to state what they must have; what they want vs. what they actually need.

The difference between want and need is something that all BCM/DR practitioners must clearly understand and communicate to department leads; especially those responsible for acquiring, developing and implementing the various strategies required to address BIA findings.

A department that is not required to have its processes become immediately available after a disaster will want specific action to be taken so they can become available sooner but resources, BIA findings and cost will determine that it is not needed.

Sometimes business people – even some IT personnel – will state they want something but there isn’t any information / data to back up their requirement. The BIA and resulting continuity, restoration and recovery strategies required to address those findings, determines what is needed and what isn’t. Here’s the difference between want and need:

• Need is based on what the agreed-to BAI findings state is required – based on the strategy developed. Then you know what you need and it separates from the want.
• Want is based on feelings and desire, and no one wants their department processes to be formally classed as not being required during a disaster – or at least not immediately required.

Need is something that if isn’t available, a department that wants to be up and running cannot be up and running because dependencies required to run the department (i.e. items that arrive from other departments) aren’t available or aren’t required based on BIA findings. So even then, when a department wants to be available, it still can’t become available because one of its dependencies aren’t needed. So even when people state they know what they want and what they believe they need, the BCM/DR professional must ensure that the strategy departments want aligns to the strategy the organization needs.

Make sure you know the difference and if asked why something isn’t provisioned for, you’ll understand – through the BIA findings – the reason.

© StoneRoad 2014
A.Alex Fullick has over 17 years experience working in Business Continuity and is the author of numerous books, including “Heads in the Sand” and “BIA: Building the Foundation for a Strong Business Continuity Program.”