Preparing for the Unexpected – 2018-04-12: The Challenges of BCM/DR Programs – Part 1

No matter the industry, the size of your organization, or the location(s) of your business, Business Continuity Management (BCM) and Disaster Recovery (DR) programs always seem to experience a common set of challenges. Drawing from 20+ years of experience, Alex Fullick will discuss these many challenges that seem to transcend industry and location – and which seem to appear at one time or another – in every BCM/DR program. Listen in to hear why some of these challenges occur and how to deal with them when you begin to encounter the same issues in your program.


The StoneRoad Team




BCM & DR: When to Use Software

Often, when an organization initiates its Business Continuity Management (BCM) / Disaster Recovery (DR) program, it a pretty manual process: documents, power points and spreadsheets abound. They look good and they serve a purposes but when the program needs to mature and grow, the manual maintenance and monitoring processes just can’t keep up properly. Suddenly, the person responsible – use is usually only assigned to BCM/DR part time – can’t keep up and things begin to fall apart. It’s time for some help to automate the BCM process to keep it current and maintainable (not just the plans being maintained). Continue reading

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!

The StoneRoad Team

“Reduce Suffering Through Disaster Planning”

© 2014, Stone Road Inc.

8 Considerations for Online BCM/DR Solutions

To many, it might seem easier just to go the online application route to perform a Business Impact Analysis (BIA) or build Business Continuity Plans (BCP), Crisis Management & Communication protocols and even Disaster Team roles and responsibilities. However, it’s not always that easy. An online solution may not be the best bet to start with, as there are considerations organizations need to think of before going down the ‘online’ route.

1. Financial Considerations:
a. Product Cost – This is one of the main considerations for all purchases. If it’s too expensive – regardless of what it does and/or doesn’t do – many won’t consider it. So, the price is something that pops to the top of every list no matter what the requirements are. Once cost is balanced against other requirements, then the real decision get made. Want and need against the cost to get what suits the organization.
b. Administrator Training: Often, the purchase of a solution means that someone – either an individual or a group of individuals need to be trained on how to administrate and configure the new application.
c. User Training: In the past there have been instances where individuals must travel to the vendor’s location to receive training on their product – this may still occur for some products. If this is the case, then your organization must take into account the additional travel and accommodation costs attributed to the number – and length – of training courses that have to be taken before anyone can begin to use the product. In some instances, this might add weeks to your planned implementation schedule because the course offerings (training) may be dependent upon the vendor’s availability and if current courses have any available spaces.

2. Set-Up & Configuration: This requires your internal IT team to get involved. They need to ensure they have a server available or space on an existing server to house the new application. In many instances, they want to know more questions that you’re able to answer, and then chatting back and forth with the vendor for configuration requirements may take some time, especially if you encounter any issues.

3. Internal Technology Involvement: OK, so you bought the new online application – now what? Who internally is going to support it and do they need training on its workings and what’s required to support you and the internal users?

4. Support & On-going Maintenance: Make sure that if you have any questions, contacting someone for assistance is easily available. If you’re vendor is in another time zone, their support hours may not cover the time you’re in the office and thus, you only have a small winder each day to speak with someone. Find out what level of support is offered. In some instances most of the technical support ends up coming from your own internal IT personnel, which usually frustrates them, as they’re supporting a systems/application that isn’t theirs to start with.

5. Questionnaire Build: Most applications, such as those intended for Business Impact Analysis (BIA), come with some pre-existing questions, which you can leverage. However, in many cases the questions are generic and may not represent the full range of information you require. If that’s the case, then you need to ensure you have time available to plan out your questions and then insert them into the application. Depending upon the application functions, you may have to build in links between various questions. For example, if a question is answered with a ‘no’ then it skips the following questions that may appear if the answer to a question was ‘yes’. Good questions will help give you the information you need so be sure to spend time on the questions to ensure they meet the needs of your organization.

6. Reporting: One of the advantages to online applications, is they are able to provide all sort of reports and report formats. However, since each organization is different and the reporting isn’t standard from one organization to another – let alone reporting related to BCM/DR – an organization may have to design its own reports and build the criteria around them so that it gets the information it wants to make decisions based on the input from users. Designing reports may come at a later date once the user (BCM resource) is more comfortable with the application and when there is actual data to work from, rather than building the report before actual responses and input has been received.

7. Time: Time is money, as they say; do you have the time to get everything noted above coordinated before moving on to build your BCM/DR program? If the direction from senior management to build a program comes with deadlines (i.e. a BIA completed in 2 months with findings and recommendations) do you have the time to begin looking for an online solution, purchase it, design to you specifications, train users (including yourself), get users to complete the questionnaires (or whatever is being sought), capture the findings and present them to executives? Quite possibly not. The online solution may become a more long term aspect to enhance the program, rather than the component that kicks it off.

8. Growth: If you’re organization has grown by leaps and bounds it will become impossible to be able to manage all the various program components. Change would be happening so quickly (let’s hope) that a manual process would take too long and be too labour intensive to ensure plans are kept current, incorporating the change in so many locations (assuming new facilities are being utilized), new nationalities and requirements, new departments (spread over multiple locations) and new processes and client/vendor/partner needs. And this doesn’t begin to include the new challenges for Technology Recovery Plan (TRP).

In the end, an online solution will eventually expedite information and keep it manageable, it just can take allot of effort to get there. Sometimes the old manual method of acquiring BIA information is quicker and easier. Yet while that is being done, an online solution can be investigated and slowly built in the background being populated with the information being obtained from the initial BIA – when you’ve actually moved on from the BIA and working on developing contingency strategies and solution. The manual process for BCM/Dr can only last so long before it becomes harder to maintain. As the organization grows and hierarchical structures begin to ebb and flow to meet new challenges, the online version can respond much quicker than updating multiple documents.

In no way is this intended to deter organizations form using online BCM/Dr applications; in fact in the long run they can offer more good than negative. But, starting out fresh with them can cause delays and hindrances you may not have time to tolerate.

© Stone Road Inc. (StoneRoad) A.Alex Fullick, MBCI, CBCP, CBRA, v3ITIL

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.

Books by StoneRoad founder, A.Alex Fullick, MBCI, CBCP, CBRA, ITILv3.
Available at,,

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.

BCM / DR Program Templates Available from StoneRoad

Check out our revamped shop at We’ve added lots of new document templates to help get your new BCM / DR program off the ground – with more on the way. Each comes with built-in instructions so you don’t need to try and figure it all out on your own. You can even manipulate the templates if you want to so they address your specific need. Our goal is to show you ‘how’ to do things not just tell you ‘what’ you need to do.

Here’s a sample list of what we’ve got so far:
1 – Test-Exercise Project Change Request Template – $9.99
2 – Test-Exercise Scope Statement (Charter) – $29.99
3 – Test-Exercise Executive Summary – $29.99
4 – Operating Unit Business Continuity Plan (BCP) – $79.99
5 – Business Impact Analysis (BIA) (This one along can cost thousands for a software application.) – $79.99

Coming soon:
1 – Employee Logistics Plan – $tbd
2 – BCM/DR Program Policy Template – $tbd
3 – BCM / DR Program Overview (As a bonus, this will include the Policy template) – $tbd

If there’s something specific you’re looking for, send us an email. We’ve got lots in our arsenal and alwasy building new templates so we may just have what you need and just haven’t gotten around to getting it up on the site. We can always build something for you. You can reach us at

StoneRoad: Reducing Corporate Suffering Through Continuity Planning.

The StoneRoad Team
StoneRoad 2013 (C)