Breaking Up is Hard to Do

Breaking up is hard to do.  Those are not my words.  They were said, or sang by a much more talented guy named Neal Sedaka.  He sang those lyrics back in 1976, but they are still true today.  Breaking up is hard to do.  You can watch a performance of the song here.  (Watching this video could result in physical distress for viewers born after the year 1970.)  Staying in a relationship is easier than breaking up even if staying is unhealthy.  One of the main reasons people stay in broken relationships is that however unpleasant and unhealthy the situation is, change can be even more difficult.   Clinical Psychologist, Dr. Samantha Rodman wrote the following in a recent blog post for a website called TalkSpace:

“A common example of fear of change is when a person stays in an unfulfilling romantic relationship because they are terrified of being single, or of the effort and risk involved in trying to find a different partner. People often coast along in unfulfilling relationships, even marrying a person about whom they feel ambivalent, just because they are so scared at the prospect of breaking up.”

Change is hard to do.  Change is at the heart of what is hard about breaking up for many people.  Change is especially tough when you are in love with Microsoft Office.

I get it.  I’ve been there.  I created an Access Database of my music collection back in college.  I gave my heart and the better part of a year to that thing only to finally realize it just wasn’t right for me.  I could tell you story after story about PowerPoint presentations that I found myself watching in presenter’s mode over and over.  Sometimes even returning to the meeting rooms where PowerPoint and I spent time and standing at the podiums where we presented.  I can even remember when I caught my best friend installing the Analysis Toolpak in my budget spreadsheet in Excel.  You don’t want to get me started on the Las Vegas Lights text effect in Word.  I’m not going to get into the details on that one – they are right when they say what’s formatted in Las Vegas Lights stays in Las Vegas Lights.

There is hope for people like us.  I can tell you from experience.  If you are thinking of ending your current relationship with Microsoft Office to implement a new software tool for Business Continuity and Disaster Recovery, just follow these tips:

  • Embrace the change. Remember why you started looking for the new software tool in the first place.  There must be a reason you started evaluating new products.  There are probably dozens of them.  Word and Excel offer freedom in terms of formatting and styles, but they lack the robust capabilities that software tools designed for BC and DR provide.  Many organizations create detailed evaluation documents to ensure the products they are evaluating offer capabilities considered vital to the program; then they forget those capabilities and insist the new tool be customized to provide an experience and output exactly like Word or Excel.  Stay true to the original requirements and focus on the functionality gains you targeted in your software search.
  • Focus on the big picture. The new software should help you drive the program to success.  Success in terms of a BC/DR program is about organizational resilience improvement.  It’s not about reproducing a Microsoft Office user experience.  BC/DR tools are not designed to act or look like Office, so expecting them to will require complex customization and taxing administrative overhead. In the end you will still be frustrated because nothing looks or acts like Word and Excel except World and Excel.  We can’t ask a fish to ride a bike and be upset when it can’t.  BC/DR software is designed for program goals.  Define success at the program level and then select and implement the tool in a way that enables the functionalities to help you get there.
  • Preach to the choir. Gain momentum by selecting the most enthusiastic, most change-receptive units in your organization to be early adopters. Develop a momentum around the program using the new software as the catalyst.  Stress the value of the software in meeting organizational goals.  Reduce the stress of the change by marketing the advent of something new.  If the focus of the effort is less about replacing something that is comfortable, than it is about the curiosity and novelty of something new, exciting, and easy to use; the stress of the change can be replaced by the anticipation of a new experience.
  • Keep it simple. If I had a nickel for every implementation that started with the project sponsor stating how they would like to keep things simple and out-of-the box, only to then detail dozens of absolutely critical customizations, I would not have to write entertaining and informative blog posts like this for money.  To tell you the truth, I wonder if some clients remember anything about the software they selected when the implementation starts.  Some seem surprised to learn that in addition to not making coffee or starting your car remotely, the software can’t relay thoughts automagically into plan content.  Today’s software is advanced, but trying to get it to do every single thing the program requires will create unnatural interfaces and undue burdens on end users and administrators.  Let the software do what is was designed to do, and understand that no software replaces all human participation especially during a crisis.
  • Don’t limit the opportunity a software implementation provides. This is perhaps the most disappointing mistake organizations make when implementing new software.  The implementation marks an opportunity to review all of the program practices.  This is an unusual and valuable opportunity.  If the effort is confined to the software, your organization is passing on the chance to improve its performance across the board.  This doesn’t mean bending practices to meet software capabilities.  If you selected the right tool, it should mean configuring the tool to support improved workflows and practices that enhance all aspects of the BC/DR program.  Don’t install a new software to continue stale inefficient practices.  Use the change as an impetus to streamline all that you do.  The implementation may mean the chance for program evaluation by expert consultants.  It means the chance to have experienced consultants with unbiased viewpoints evaluate the program and organizational practices.  Allow them the opportunity to review all program activities with an eye toward recommending improvements.  Be receptive of the recommendations, rather than resentful of the feedback.  Feedback can be a valuable tool for progress.
  • Build change into the normal activities of the program. Change doesn’t need to be a source of apprehension and stress.  If change is adopted as a normal part of the program life cycle, the dread it can often inspire will be limited.  Schedule program reviews annually to examine all activities and identify opportunities to improve.  Welcome suggestions from those working to support the program and the stakeholders who are supported by it.  The implementation can be just the first in a regular pattern of program review that includes the survey and analysis of feedback by multiple parties, the assignment of action items targeted at improvements, and the update of online and off-line workflows.

So, there is good news for those of us struggling to end an unhealthy relationship with MS Office.  It doesn’t have be hard to do; it doesn’t have to mean tears or heartbreak; it doesn’t need to mean binging on Haagen Dazs ice cream and romantic comedies; and, best of all, I don’t have to stand in the rain in front of Microsoft’s home office blasting Peter Gabriel songs…again.  What it could mean is the start of something big for your program.  Plus, it really is possible to stay friends with Office.  (I really wish I could format that last line in Las Vegas Lights font.)

Step One

Organizations often make a false assumption as they approach the start of a Business Impact Analysis (BIA) or recovery plan building: they assume that staff members can define the business processes that they are engaged in as part of normal operations.  The truth is that many people struggle to define the processes that they are regularly engaged in at the proper level, despite being part of an organization for many years and performing in the same role for a long period of time.  A process inventory is an essential prerequisite for a BIA or for plan building.   Failing to define processes at the appropriate level will yield inaccurate BIA results and could result in the creation of ineffective recovery plans.

The most common error in defining processes is the elevation of the individual tasks that are involved in performing a process to the level of a process.  If tasks are defined as processes, subject matter experts will have challenges identifying impacts at such a micro level of activity.  When processes are defined at excessively high levels of operation, the impact of a disruption can be exaggerated as all activity at such elevated levels is inflated.

Plan building is similarly problematic when processes are not properly defined.  Plans scoped at task level may fail to account for the complexity of operations and risk not identifying critical aspects of the recovery.   Planning at upper levels of the organization can result in over-sized plans that are difficult to execute and impossible to exercise effectively.

Prior to the start of a BIA or recovery plan building, business continuity leaders need to provide guidance to those identifying processes.  It’s more than just providing a working definition.  A means of comparing activities thought to be processes to the known attributes of a process is needed to establish a method of validation.  The activities being evaluated need to find similarity with what we know to be true for all business processes.  If there are difficulties in identifying the aspects of a process in evaluating an activity, it is unlikely that the activity is truly a process.

Providing BIA participants or planners a real-life example may help to simplify things.  Consider relating a familiar life experience to process identification.  Most people have spent time shopping online for auto insurance.   We go to websites for insurance companies, complete a request for a quote, and compare.  Providing auto insurance quotes is a business process.  The process is triggered when we complete and submit the online request form.  A series of coordinated activities follows:  Our data is compared to risk rating information.  A driver’s license history is reviewed.  A credit report may be run.  Our address and contact information may be validated against known sources.  A quality assurance check may be conducted.  All these activities are standardized and documented.  The result is the value item – the thing we as potential customers of this process desire – the quote.  Analyzing this example helps us to catalog the attributes of a process:

  • Processes are triggered by an event or action.
  • A process is a coordinated series of actions.
  • Processes have inputs in the form of resources such as data or work effort by staff members
  • Processes have standard procedures that are followed to ensure that they are properly performed. There is often training required to properly perform processes.
  • Processes create a something of value for a customer/client.

The coordinated activities typically result in a transformation.  The transformation may be to a tangible product or to data/information.  The result is the value desired by a customer/client.  As we assist in identifying processes properly, it is typically the inability to pinpoint the customer/client and the value generated by an activity that will effectively separate processes from tasks or procedures within the scope of a process.   The trigger/event that directly initiates the process will be particularly difficult to isolate in instances where a ‘process’ has been defined at too high a level of operation.

Adding process identification to the start of the BIA or to plan building will increase the time required for the project, but it is a prerequisite.  The time spent to properly define processes is still shorter than the time it takes to redo the BIA or to restructure the scope of recovery plans.   Taking the time to inventory processes properly is the business continuity equivalent of measuring twice to cut once.

Fairview Health Uses MaestroRS to Protect Critical Health Services

Health service providers cannot tolerate downtime.  There are quite literally lives hanging in the balance.  Fairview Health Services of Minneapolis, MN is no different.  Over 1,500 applications, many of them mission-critical, are necessary to keep operations functioning normally in their 12 hospitals, 54 primary clinics, and 36 pharmacy locations.  In the past, IT support managed their IT Disaster Recovery (DR) processes manually. While they were committed to having robust DR protocols, they struggled to keep Word-based disaster recovery plans up to date and accurate – and to verify that RTOs could be met. According to Maria Rothstein, DR Analyst & ITSM Office Manager, “We were faced with an enormous amount of work. Automation was the only way forward.” Fairview Health Services already used ServiceNow for IT Service Management and to manage their IT infrastructure. This made ServiceNow a natural choice for managing DR. The ServiceNow CMDB had a comprehensive inventory of Fairview’s IT network, along with other key data such as vendor and facility information. Rothstein says that, “We were constantly taking information out of ServiceNow and pasting it into our disaster recovery plans. That made no sense. By managing DR within ServiceNow, we could save huge amounts of time—and know that we had an accurate, up-to-date single source of truth.”

As a result of implementing MaestroRS, Fairview operationalized disaster recovery.  Standard ITSM and ITOM practices contribute to the build out and maintenance of actionable disaster recovery plans.  Fairview can now easily view graphics, custom, dashboards, and reports allowing them manage gaps between their organizational needs and their IT capabilities.   According to Rothstein, “it will allow us to have complete visibility of the RTO of each of our key applications, and we will be able to easily see the gap between our planned RTOs and what we can actually achieve.  Fairview can exercise to ensure readiness and gap mitigation efforts by facilitating realistic disruption scenarios using the Recovery & Exercise Management module in MaestroRS.

Rothstein is very enthusiastic about MaestroRS. She says that, “Our experience has been tremendous. And because the application was certified by ServiceNow, it got the golden pass—we knew it had successfully completed a defined set of architecture, integration, security, and performance tests, and had the capabilities we needed for success.”


Drive Successfully – Best Practices for Software Implementation

It’s like being behind the wheel of a car as it skids along a sheet of ice.  The helplessness of having your hands firmly on the wheel and your foot on the brake but not being able to change direction or stop leaves you breathless.   The imminent impact approaches in slow-motion. Your mind performs a flawless frame-by-frame recording of the event, a sort of a stop-motion filming for infinite playback after the fact.  A million thoughts go through your mind within fractions of a second: many have to do with what you could have done to avoid being in this situation.  But you’re not on ice, nor are you even in a car.  You’re in a software implementation that’s off the rails.  You are out of control, and there will be a definite impact – on the organization, and, perhaps, on your career.

This can all be avoided…the skidding, the feeling of helplessness, the torture of reviewing the what-if’s, and, most notably, the impact.  There are best practices that can be followed to help ensure things move according to plan.  John Donahoe, CEO of ServiceNow, spoke to a group of over 18,000 ServiceNow users at the Knowledge 18 conference about the best practices for customer success in implementing software[1].  Though Donohoe was speaking specifically to ServiceNow users, the practices are applicable to any type of software implementation.  He outlined four specific practices as being directly related to customer success:

Commit to an Out-of-the-Box Implementation

Failure to follow this first practice can doom an implementation before it ever gets started.  There are bound to be multiple competing voices clamoring for customizations that are micro-targeted at small facets of the organization and bring little, if any, value to the organization as a whole.  Attempting to placate all of the factions within your user community can have devastating long-term effects.  Over-customizing can hinder your organization’s ability to take advantage of future enhancements.  It may also impede your ability to install upgrades, and it can complicate security and the end-user experience.  Look to bring consensus around the implementation.  There are times where customization is necessary; however, one-off changes to benefit a small group of users should be dismissed as they do not provide the overall value required to justify the alteration.

Provide Clear Leadership and Governance

There needs to be a guiding force behind the implementation that provides a strategic approach to the roll out that adheres to the long-term vision of the software.  The leadership and governance group will ensure that the implementation stays on track toward resolving the issues that the software was purchased to address.  Leadership and Governance can also provide a firm hand in reviewing and making final determinations on requested customizations.  Proper governance can ensure that the organization is committed to a regular schedule of upgrades and is positioned to receive the optimal return on investment.

Invest in Change Management

Make sure the right team is in place to support the application.  Invest in training and certifying staff members, or hire staff that have certification and bring prior experience to the project.  Consider creating a Center of Excellence – a pool of capable personnel who can support the user community and will create and model best practices for using the software.  Market the implementation and upcoming changes.  It will be key to create excitement around the roll-out and to continue to drive interest preceding upgrades and changes.

Drive Business Outcomes

It’s not enough to say that the goal of the implementation is to ‘improve workflows’.  Avoid general statements around the aim of the roll-out.  Be specific in creating goals.  Develop top-down targets that are measurable, and report on your progress.  Consider why you chose to procure the system in the first place, and develop the means to quantify if you are achieving those objectives.

These practices are not applicable only to those at the outset of an implementation.  It’s important to note that you could steer out of a poor implementation.  There are no laws against shifting gears and re-implementing.  If you did not follow these best practices on the first attempt, try again.  Put the project in park, and develop a plan for success.  It is infinitely better to take one step back in order to take two steps forward than it is to continue onward at breakneck speed down the wrong road.

[1] John Donohoe, ServiceNow, ‘Knowledge 18 Day 1 Keynote, Works for You (Full Recording)’,, May 8, 2018

Fairchild Named Independent Software Vendor (ISV) of the Year

Fairchild Resiliency Systems Recognized by ServiceNow at Global PartnerNow Summit

Fairchild Resiliency Systems Receives Breakout ISV Award for Americas Technology Partners

Andover, MA— May 15, 2018 —Fairchild Resiliency Systems announced that it has been recognized by ServiceNow as the winner of the Breakout ISV Award for Americas Technology Partners for 2017. Presented at the Global PartnerNow Summit that took place as part of Knowledge 18, the largest gathering of professionals sharing how they are leading digital transformations across their companies and delivering great customer and employee experiences.

The PartnerNow awards recognize the tremendous contributions of the partner community who have delivered outstanding value to ServiceNow and our mutual customers. As an Americas Technology partner, the award recognizes Fairchild Resiliency Systems’ success in the ServiceNow Store based on achieving the highest revenue and total number of deals transactioned via the Store.

“We are very pleased to recognize Fairchild Resiliency Systems for this achievement,” said Tony Beller, vice president of Alliances and Channels at ServiceNow. “And look forward to continued customer success as they continue to drive business transformational solutions to our global ServiceNow enterprise customers.”

“This is a great honor for us”, said Aaron Callaway, Managing Director, Fairchild Resiliency Systems.  “This award confirms that our team’s commitment to the ServiceNow platform and our efforts in developing MaestroRS is helping to fulfill our mission of moving our clients to a new level of organizational resilience.  We would like to thank ServiceNow and in particular all those who have supported us in bringing our solution to the ServiceNow store and in continuing to make our store presence engaging and informative.  This is a great day for all of us at Fairchild.”

About Knowledge18

At Knowledge18, 18,000 attendees will participate in more than 300 breakout sessions and 120 labs, specialized networking events, and the exhibition hall with 175 sponsors representing solutions for IT, customer service, human resources, and security. With the combination of pre-conference training, a diverse content catalog, conversations with peers and ServiceNow experts, and CreatorCon, the conference presents the best opportunity for ServiceNow customers and partners to learn to create delightful experiences for employees and customers. Come see how to make the world of work, work better for people.

About Fairchild Resiliency Systems

Fairchild Resiliency Systems seeks to advance resiliency for clients through innovative software and consulting solutions. Fairchild has been and strives to continue to be a disruptive force for positive change in the Business Continuity and Disaster Recovery industry. Our mission is to elevate the level of effectiveness and efficiency at which our clients respond to and recover from disasters. We are driven by a passion for customer service that guides the design of our software and underpins our approach to the unique strategic solutions we collaboratively implement for our clients. By continuously challenging the notion of what’s possible, we are able to evolve and adapt our products and services to not only overcome the challenges faced by our clients, but to propel them to new levels of performance.

ServiceNow and Knowledge are registered trademarks of ServiceNow.



Leveraging the Network Effect in Business Continuity and Disaster Recovery

The Network Effect is the idea that a product or service increases in value as more people utilize it.  This is a key concept underlying the rise of the Network Economy.  In the Network Economy the number of connections to a product or service drives its usability and value.  Airbnb is a flagship member of the Network Economy and a prime example of growth via the Network Effect.  The usefulness of the service has risen with the rise in users seeking accommodations and homeowners providing listings.  In 2008 Airbnb guests numbered about 20 thousand.  In 2017 the total number of guests were 100 million.  This service clearly becomes more valuable as more travelers use it and more homeowners list their homes as available.  Airbnb now offers more than three times the number of listings Marriott or Hilton offer.  These numbers come from a company called Vizlly, ( which offers services to hotels trying to fight back against Airbnb.  In 2008, it would have been hard to imagine that such a company would even exist.  Uber and Lyft are other examples of exponential growth via the Network Effect.  If you own a taxi company, you are probably engaged in a desperate search on a daily basis for the transportation version of Vizlly.

The good news for those of us in Business Continuity is that we don’t need to worry about countering the Network Economy or the Network Effect; we need to imagine ways to leverage them.  So, what service or product can we offer that can leverage the Network Effect?  How can we bring a value to our organizations that will grow organically and improve in value as more people become involved?  Our product is often viewed as not having a value.  Our activities are seen as a drag on current staff.  We ask them for valuable time in completing Business Impact Analyses (BIAs), building and updating recovery plans, and participating in exercises.  The most conscientious among our coworkers understand the need and benefit of doing these things, but they would likely rank their enthusiasm for participating in them equal to paying their insurance premiums.  The need is understood, but there is a perceived value only if something goes wrong.

The irony is that unless we provide value outside of when things go wrong, we can offer less value when things do go wrong.  BIA results and recovery plans are less useful as more time expires between refreshes. What product or service can BC program leaders provide that could leverage the Network Effect?  The answer is data.  BC should be the great aggregators of organizational data.  What is a recovery plan but coalesced information from a number of distinct sources?  The potential is there to have assessments and plans receive automated updates from normal activities that are not related to BC.  If our coworkers saw that their day-to-day activities would automatically have an update on their BIAs and plans, we would be in position to improve resilience by creating our own Network Economy.  Operationalized Business Continuity is our answer.  We can be like the leaders of the Network Economy: a transportation service without cars (Uber/Lyft), an accommodations service without properties (Airbnb), or a media service without content (Facebook).  BC can be a data service without the ownership of any information.  If we can operationalize business continuity, drawing people into our platform to enter information they need to capture for non-recovery related work processes, we can leverage organic updates to recovery plans that would be the seed of our Network Economy.  We can provide data related to multiple areas without actually owning any data of our own.

The platform solution is the vehicle for a BC Network Effect.  A BC solution that can provide or share an environment with IT, HR, Vendor Management, and other key business areas offers a chance at the Network Effect.  Platform applications are devouring the market as companies look to drive ROI from their existing investment in IT and to create synergies that can’t be adequately supported via APIs.   ServiceNow is such a platform.  It is dominating its marketplace.  ServiceNow, Meet the ‘Fastest-Growing’ $1 Billion Enterprise Software Firm, (, and it continues to generate organic growth within its clients’ environments.  CEO John Donahoe was recently interviewed as part of the company’s Q4 earnings conference call.

Rob Owens: “So, maybe you can expand a little bit on the low-code, no-code opportunity and what that could mean just relative to the installed base and potential expansion there as well as your opportunity in the end market.”

 John Donohoe: “Yes, Rob, I think the short answer is we don’t really know. But I think we have this platform that customers give us feedback that it’s easy to use, it’s fast to build on, it’s extensible. So, in addition to building outstanding out-of-the-box applications, we’re trying to incent the spread of that platform across enterprise. We’re going to do it a couple of ways. One, we’re investing heavily in our platform-as-a-business. And our platform-as-a-business, that is platform as our product line grew, as Mike mentioned earlier, very attractively last year. So, people are buying the platform with the intent of using it outside of our core applications as well as our core applications. Second, we are ceding the third-party development market, both inside companies and outside companies. So, our store, our ISVs in store grew 100%. 100% net new ACV growth from our partners through our store and OEM program last year. It’s still a relatively small program, but it’s a way where we can open up the ability to innovate on top of our platform. And we’re having a number of OEM partners like Nuvolo and Factor5 and Fairchild who have built applications on top of our platform, often a vertical solution or a specific use case that they’re gearing it toward. And then lastly, what the no-code platform is for, the no-code effort is to just make it easier inside the enterprise for non-IT, non-developer employees to extend the use of our platform in ways that even we can’t imagine. So, our goal is to unleash the next wave of innovation. Obviously, the more this happens, the stickier our platform becomes. It both opens up new doors of opportunity and makes it stickier. And so I think it’s too soon to tell to see how much it’s used.”

 I should have given you a shameless-plug alert for Fairchild and MaestroRS, but the truth is that ServiceNow and Fairchild are not the only platform – software combination that can help your program achieve the operationalized level of efficiency that is the goal here.  There are other platforms that could affect the same change.  (They’re just not as good. )

On a serious note, this isn’t going to happen on a stand-alone product.  The opposite of the Network Effect is building something on an island that forces users to learn something outside of their normal tool set that dictates a come-to-us approach, rather than a join-up network approach. The success of the platform is that it synthesizes disparate organization operations into a single access point simultaneously creating and sharing value.  Standalone tools are not going improve in value, like an Airbnb; because there is just no reason for anyone who isn’t responsible for BIAs or plans to log in.  There is no increase in value due to increase in use since the only users who will ever use the tool are only those who have been forced to do so.  There is no value in using the tool for non-recovery purposes, so the spread of value is decidedly finite.  One defining factor in the Network Economy is how infinite these products/services are.  There are no limits for their use. (‘Build Platforms Not Products’ Cloud Elements –

ISO22301 encourages BC practitioners to understand the ‘context of the organization’ encouraging us to recognize and make connections to all areas of the enterprise.  This understanding, and our efforts to make connections, will drive the creation of a culture of resilience.  The idea of the Network Effect is an evolution of this idea.  We can drive cultural change by aligning our efforts with the normal efforts of the organization.  Look for opportunities to join into your organization, find synergies between their work and yours, rather than forcing them to you. Cloud Elements, cited earlier, offers a distinction between a single-sided business model and a multi-sided business model.  Single-sided approaches solve an issue for a customer without thought to the network of the organization.  Adopt a platform approach that instead employs a multi-sided model encouraging users to interact in a way that creates additional services in the process.  Think of your program as a piece of the puzzle, rather than something that stands outside of it, measuring it, and never finding a place within it.

Starting a Business Continuity/Disaster Recovery (BC/DR) Program – Part II

This series is dedicated to providing direction for applying Project Management principles to starting a Business Continuity or Disaster Recovery (BC/DR) Program.  This is the second installment of a multi-part series.  In this installment we will focus on the Project Planning phase.  The first installment of this series can be reviewed by clicking here.  Subsequent segments will be aimed at additional phases of starting a BC/DR Program, on improving an existing BC/DR Program, and on elevating a mature program to a new level of efficiency and effectiveness.

The Project Planning Phase

It is important to understand that the project planning phase is a critical part of managing the project. Many projects fail before they begin due to inadequate planning at the outset.  Consider that you may deliver an incredible collection of project deliverables that check all the boxes for management in regards to content, presentation, and usefulness, but if those deliverables are provided late and/or over budget, the project will be considered a failure.  This needs to be spot on for success.  The quality of the deliverables, their timeliness, and the adherence to the established budget all need to be in line with the plan provided to management.  In addition, this phase may be the most difficult to execute successfully, especially for those new to project management.

Here are some of the items that need to be developed in the project planning phase:

  1. Work Breakdown Schedule (WBS)
  2. Milestones/Gantt Chart
  3. Cost Management Plan
  4. Communication Plan
  5. Risk Management Plan

In many ways each of these items is a project plan within the overall project plan.  The individual documents allow the management of the major aspects of the project.  It will take a considerable effort to develop them, but the work will be rewarded as they will serve as resources as the project progresses enabling you to stay on plan.

Work Breakdown Structure (WBS)

A WBS is a hierarchical breakdown of the deliverables of the project.  In creating the WBS, focus on the end goal and stay high level.  The WBS simplifies the project into manageable pieces that can analyzed for cost and efficiently managed for completion.  The WBS is a graphic representation of the project scope.  To start out, name the project and list the major deliverables under the project title.  Our project can be named Create a Business Continuity Program.  Earlier we identified three deliverables:

  1. Business Continuity Policy
  2. Business Impact Analysis
  3. Threat Evaluation

With the highest levels of the WBS graphed, focus on breaking down each major deliverable into smaller elements.   A good rule of thumb for breaking down the major deliverables is called 8/80.  The smaller elements of the deliverables should take between 8 and 80 hours of work to accomplish.  Go no smaller than eight hours for an element.  If an element takes longer than eighty hours, continue to break it down into smaller parts.  In addition, each work element should be completely independent.  There should not be any overlap between elements; each should be unique.  The elements may need to be broken down to different levels.  Some elements may require multiple levels of breakdown while others require none or few levels.  Do not feel as though all the segments need to be broken down to the same level.

Once the deliverables are broken down according to the 8/80 rule, attach a percentage representing the amount of work that element requires in relation to total work required for the project.  Indicate the budget allocated for that element as well.

The 100% rule should be applied to the WBS.  The 100% rule holds that the top level of the WBS represents the total work and budget of the project.  The rule also holds that each level of the WBS should also represent 100% of that level’s total work and budget.  See below.

The high level deliverables should add up to 100%.  The levels below must also add up to 100%.  Here we can see that 2.1.1 and 2.1.2 add up to 100% of the work and budget for level 2.1.

There are many websites that provide information about creating Work Breakdown Structures.  Most include examples and templates that can be downloaded.

Milestones/Gantt Chart

Milestones are key events in the lifetime of project. Mapping milestones and comparing progress to them ensures that you are not too deep into the details of the project and are keeping the overall project on course.  The milestones of the project include critical deadlines, key dates unrelated to deadlines, and deliverables. A milestone chart is great for reporting and presenting to management since it summarizes the key stages of the project without getting too detailed.

Identifying the milestones involves setting a sequence to the major elements of the project.    To create a comprehensive milestone chart, refer to the work breakdown structure, but understand that milestones are not isolated to only items in the WBS. Consider also key organizational events and initiatives that overlap your project.  Also consider any periods in which the project team will need to focus its time and effort on other unrelated activities.

The timeframes for completing each milestone will vary greatly by the size of the organization and the staff that will perform the project activities.  The ability to outsource portions of the project is also a factor to be considered.  In calculating the expected dates for the project milestones, consider required predecessors.  Milestones will commonly require that one or more other key activities, deliverables, or other milestones are complete.

There are multiple templates available for milestone charts.  The link below provides templates for MS Office.

A Gantt chart further breaks down the items in the work breakdown structure into tasks with defined timelines for completion and relationships to other tasks that serve as predecessors and/or successors.  A Gantt chart can also be used to identify the resource(s) responsible for completing each task.

In a Gantt chart, each tasks is represented on a row.  A timeline appears along the top or bottom of the page, and a bar is drawn on the task row to a length representing the length of time required to complete the task.   The graphic below is a very rudimentary sample.

There are multiple software programs available for creating Gantt charts and many templates for creating them within MS Office.  Here is a link explaining how to create a Gantt chart in Excel.  There are many tutorial videos like this on YouTube and elsewhere on the web.  If you feel it is important to link tasks together, visibly display connections between tasks and milestone icons, track resources, and involve constraints, it may be best to use a project management software program.

To create the Gantt chart, add the major elements from the work breakdown structure; then break out each major element into the individual tasks required.  Prioritize the tasks in accordance to how they may relate to each other and which tasks may be predecessors to other tasks.  In some cases tasks may need to be completed in tandem, but for our BC/DR project, linked tasks will most often have a finish-to-start relationship.  In a finish-to-start relationship, the predecessor task needs to be completed before the successor task can be started.  More information about task links is available here.

Review each task and draw the bar for each to represent the duration for the task.  Determine the resource responsible for performing each of the tasks.  When complete, review the resources assigned to tasks to ensure that no resource is over-allocated.

Cost Management Plan

The Cost Management Plan summarizes how project costs will be controlled.  The plan is not simply a summary of the expected costs for the project.  It includes a description of the method and manner in which costs are being estimated, and how the available budget will be periodically utilized.  It includes the estimated cost of each activity and a schedule of when costs will be incurred.  It also defines who has the authority to change the cost management plan and the procedure for how the costs are changed. The cost management plan should also define how costs will be reported and how often. Leverage the work breakdown structure in creating the Cost Management Plan.  In creating the WBS the budget amounts should have been tagged to each task.

For the BC/DR project, examples of cost contributors are the wages of the staff involved in the project, the purchase and implementation costs of any BC/DR and/or project management software (if applicable), the costs of outside consultants (if applicable), printing costs, the price of access to references such as those associated with historical disaster data, the wages of those who will be interviewed for the BIA, and the wages of those who will review and approve the BIA.  Travel may also be a cost depending on the delivery method for the BIA.  Travel may also be a factor if travel is needed for the threat evaluation and/or meetings to present on the status of the project or the final project findings.  Your organization may have its own standard policies for what contributes to project costs.  For example, some organizations do not account for internal staff when determining the cost of a project.  Assuming that your organization does account for internal staff in cost planning, ensure that you include the time it requires to update the project planning documents and the status reporting required of management.  These activities are essential and should be part of the overall project cost.

Determine if your organization has a template for creating a cost management plan.  A template will greatly simplify the process.  If your organization does not have a template, there are a multitude of templates available on the web.

A cost variance action plan may be required for the cost management plan.  The cost variance action plan designates actions and identifies individuals responsible if the costs of the project begin to escalate beyond the original plan.  The cost variance action plan sets specific percentage category ranges and defines actions and escalation points of contact based on how far the cost of the plan has deviated from the original plan.

Determine if your organization requires your cost management plan to incorporate cost performance or cost variance metrics.  If so, there are a few additional project management concepts with which you will need to be familiar:

Schedule Variance (SV) is the completed work to date compared to the planned schedule.  We calculate the Schedule Variance by subtracting the Planned Value (PV) from the Earned Value (EV).

Step 1: Determine the Planned Value (PV) for the project.  Planned Value is calculated task by task for each task that should be completed at the current point of the project.  We need to look at each task and determine what percent complete it should be given the current date.

Look at the example below:

Let’s assume that it is March 1st. The Planned Value (PV) for the tasks that were planned to be completed by March 1st is $4,150.  This is simply the total budget amount for all project tasks that should be completed as of today.  (If the date fell within the start and end date for any task, we would need to calculate the percentage of the task that should be completed by the date.)

Each of the tasks above should be complete; however, Task 2 is only 75% complete, and Task 4 is only 50% complete.  Tasks 1 and 3 are 100% complete.  Now we can calculate the Earned Value (EV) of the tasks by multiplying the planned budget amount for the task by the percent completed of the task.

Task 1 = $1,000 x 100% = $1,000

Task 2 = $400 x 75% = $300

Task 3 = $2,000 x 100% = $2,000

Task 4 = $750 X 50% = $375

The Earned Value (EV) = $3,675

Now we can determine the Schedule Variance (SV)

Schedule Variance = Earned Value (EV) – Planned Value (PV)

Schedule Variance (SV) = $3,675 – $4,150

Schedule Variance (SV) = -$475

A negative Schedule Variance indicates the project is behind schedule.

Cost Variance (CV) is the difference between the Earned Value (EV) and the Actual Cost (AC) of the project.  If the cost of the project is over the budget projection, the Cost Variance will be negative.  You can determine the Earned Value for the project by multiplying the total budget of the project by the percent complete for the project.  For example, let’s say we have completed 15% of the project, and the total budget for the project was $75,000.  To date, we have spent $10,000.

Step 1: Determine the Earned Value (EV) of the project.

                EV = Project Budget x Percent Complete of the Project

                EV = $75,000 x 15%

                EV = $11,250

Step 2: Determine the Cost Variance (CV) of the Project

                CV = Earned Value (EV) – Actual Cost (AC)

                CV = $11,250 – $10,000

                CV = $1,250

                The project is currently under budget by $1,250.

There are multiple resources available on the web for providing project metrics like those above.  Here are just a few:

Communication Plan

The communication plan defines the data, frequency, and methods utilized for delivering information regarding the project.  Communication is essential to keep stakeholders informed and to manage expectations.  To develop your communication plan, start with documenting the audiences with whom you will need to communicate.  For the BC/DR project, this may include the following:

The Project Team – people working on and overseeing the project

Vendors – external organizations providing services for the project or systems like a BC/DR software

BIA Participants – those people who will perform assessments of business processes

Site Managers – individuals who may be helpful in performing the Threat Evaluation

IT Management – individuals who will be interested to know the business needs for system and infrastructure derived from the BIA

Vendor Management – individuals who will be interested to know the business needs for external organizations derived from the BIA

Department Heads – department leads who will review and approve BIAs and will need to understand their RTOs and the dependencies on their processes

Project Sponsor – the individual who approved the project and may be funding the project through their assigned budget

The list of possible audiences is varied; thus the type and frequency of information delivered will vary as well.  Meet with the audiences to determine what type of information they would like to see and how often it should be delivered.  Also, discuss the method of delivery.  E-mail, reports, in-person meetings, and virtual meetings may all be utilized for project communication.

To manage the communication requirements, it may be advantageous to create a communication matrix.

Adopt a standardized format for all communications.  Adhere to the defined format and remain consistent throughout the project.  If available, utilize a site on the organization’s intranet to store all communications and project-related documents.  Socialize the URL and provide links in the communications delivered.

Once the communication plan is developed, consider adding key communication activities to the Milestone and Gantt charts.  Create recurring reminders in your e-mail/calendar program to help ensure communications are executed according to schedule.

Risk Management Plan

The Risk Management Plan identifies the risks that pose a threat to the success of the project and captures related remediation activities.  For the BC/DR project, create a risk matrix.  The risk management matrix will facilitate the capture of risk information for the project.  Include the probability of each risk and a measure of the impact the risk would have on the project if it were realized.

The probability ratings can also be captured as ‘low’, ‘medium’, and ‘high’.  Tasks with high probability and high impact are the primary concern.  These tasks can set the project back significantly or even require that the project be terminated.  Rank the risks in terms of probability and impact to facilitate efficient management of the project risk.  Think through the mitigation strategies carefully to ensure your project can be completed successfully.

Tasks from the mediation column of the risk matrix should be added to the project plan as they become applicable.  Be proactive wherever possible: if steps can be taken to avoid a risk, add those tasks to the project plan, and carry them out as if they were part of the normal work required.  New milestones may be necessary if any of the remediation activities are required in response to a realized risk.

With the risk management plan completed, you are through the project planning stage.  Keep in mind that each of the materials developed in this phase are living documents that will need to be updated regularly throughout the life of the project.  If managed properly, they will serve as valuable resources to help ensure success.

Avoid Common Disaster Recovery Plan Pitfalls

Disaster Recovery planning can be painstaking.  There are so many nuanced areas of focus that it is easy to miss key information that could hinder or block restoring systems and data within the time frames required by the organization.  Exercising plans is essential to help illuminate these hidden risks.  Here are some items we frequently find missing even in very mature disaster recovery plans.

1. Escalation Criteria/Requirements – ensure the plan identifies a clear procedure for escalating not only the detection of an issue that may require plan activation, but the procedure for notifying key contacts when the recovery is not going according to plan.  Contact information is essential, of course, but identifiable and measurable criteria that, if met, would require the notification of key staff members is often undocumented.  Without these guidelines in place, key performers will continue to bang their heads against a wall while the clock ticks away when a simple report on the road block or request for assistance could have easily saved valuable time.

2. Data Backup – Few IT professionals overlook data backup under normal circumstances.  That isn’t always the case when disaster recovery environments are being utilized.  Ensure that the plan contains instructions for enabling the backup of data being entered into DR systems.   The business users of the backup systems should also be alerted as to the RPO for the DR environment.  If the RPO is not socialized, the assumption will be that the DR systems have the same capabilities as production, and any loss of data in the event of a DR system failure would make the post-incident review more than uncomfortable.

3. Special Authorities – document the special access rights necessary to perform recovery tasks.  Do not assume that personnel with access will be available.  Capture the procedure for obtaining the IDs/passwords necessary in the event that key performers are not able to work.

4. Log of Actions/Events – capture a log of the actions taken during the recovery.  It’s unfair for management to assume that every decision made during the event will prove to be the right choice.  It’s not unfair to assume that a decision made was the right one based on the situation at the time when the decision was needed.  The ability to refer to a comprehensive log of actions and events will prove handy in responding to questions when reviewing the incident.  The log will also be useful as a means of improving recovery plans.

5. Failback Procedures – ensure that the plan contains the procedures to reverse any automatic or manual failover performed during the recovery.  DR plans are often remiss in detailing how to return to normal.  The process may not be as simple as a stepping back through the failover procedure.  Make sure the procedure is exercised and well documented.

The Work of Innovation

There is a common misconception that innovation involves people sitting around thinking about things until something groundbreaking comes to mind.  That abstract notion of what it means to be innovative and to bring an innovative thought to reality has next to nothing in common with the truth.  The easiest way to prove this is to examine a few job descriptions for innovation leaders/managers/contributors. Yes, you can actually get a job in innovation.  That is because the true form of innovation is hard work.  It is not as esoteric nor conceptual as most would believe.  It is a discipline that is much more similar to science than art.

Checking the job descriptions for innovative leaders and contributors, we can identify several themes.  These positions all require a mix of all or most of the following:

  • Experience in designing and applying a structured methodology to conducting tests/experimentation

  • A disciplined approach to evaluating problem statements and solutions

  • Experience in developing strategy statements and recommendations

  • Prior involvement with feasibility studies and the development of business cases

  • Ability to produce results individually and as a part of a dynamic cross-functional team

  • Ability to creatively apply technology to solve problems

  • Mature project management skills

  • Experience in gathering and analyzing consumer insights

  • Experience in gathering data and translating it into relevant implications and strategy

There is very little magic in the list above.  Judging from the requirements for working in the field of innovation, innovation largely consists of establishing and managing a scientific, measurable method of testing and evaluating a possible solution for feasibility and effectiveness against the strategic goals of an organization.  In other words, innovation is hard work.

This means that organizations who are typically thought of as ‘innovative’ are not beating their competition with some type of complex creative thought that is innate and gifted to a select few employees of that organization.  These organizations are not winning because they have managed to secure more high-level creative type employees than their competitors.  They are not lucky, nor have they discovered the secret to harnessing the portions of the brain that most of us cannot.  They are quite simply working harder than everyone else, and they are doing it consistently.

Starting a Business Continuity/Disaster Recovery (BC/DR) Program

This series is dedicated to providing direction for applying Project Management principles to starting a Business Continuity or Disaster Recovery (BC/DR) Program.  This is the first installment of a multi-part series.  In this installment we will focus on the Project Initiation phase.  Subsequent segments will be aimed at additional phases of starting a BC/DR Program, on improving an existing BC/DR Program, and on elevating a mature program to a new level of efficiency and effectiveness.

Starting a Business Continuity Program

Launching a BC/DRBC/DR Program requires its own plan.  This is not a plan as in a recovery or response plan, but a plan in the sense of a project plan.  Starting a BC/DR is no different than starting any project, and success essentially hinges on your project management skills.  You may want to reach out to the Project Management Office (PMO) if you are fortunate enough to be part of an organization that has one.  The PMO may be able to provide an experienced project manager who can assist by applying current project management theory and techniques to the initiative.  If your organization does not have a PMO, or a resource is not available, then gaining a basic understanding of project management is the starting point.

There are many available information sources for project management principles.  The Project Management Institute (PMI) is the leading authority in the field.  The PMI offers training and certification and most community colleges and universities offer courses in project management.

So let’s take a real-life approach to this and assume that you were invited into your supervisor’s office or your supervisor’s supervisor’s office on Friday afternoon, and, due to some outstanding work in a field that has nothing to do with business continuity or project management, you were “offered the opportunity” to start and lead the organization’s business continuity program.  You will do this, of course, while managing your non-business continuity, non-project management work responsibilities.  I feel your pain.  So, here’s where you are: you didn’t sleep much this weekend, you have a huge new project in your lap along with a bunch of other things on your already-full plate, and you’re probably not getting enough time, money, or people to make it happen.  Step 1 – keep reading.

This is still a project, and we still need to approach it as such despite the possibility that we are short on time and resources.  Here are the basics we need to know about project management and its application to starting a BC/DR.

Project Initiation

Project initiation is the first phase of project management.  Project Initiation is typically where a business case is created to provide the rationale for undertaking the project and proving that it is feasible.  Management will use the business case to ultimately determine if the project will be approved.  This may have already taken place and the project assigned to us after the fact.  If, however, we will be part of creating the business case, there are a ton of templates available online as well as recommendations for writing a good one.  Check internally first because there may be a standard template specifically for use by your organization.

The Business Case for a BC/DR
The business case needs to explain the why for performing the project.  Focus on describing the need for the project and how it solves an issue that the organization is facing.  Provide examples that are not exclusively IT focused as this can expand the scope of the case beyond traditional boundaries and allow areas like Supply Chain, HR, and other customer impacting areas to be included or considered. Without a BC/DR Program, the entire organization is at risk.  The organization could experience a disruption that causes injuries to associates and/or the inability to provide the products and/or services normally provided to clients.  Without a BC/DR Program there is a risk in regard to providing the safest possible working conditions for employees, and there are operational risks that could include regulatory and contractual breaches, diminished reputational status, financial loss and loss of financial opportunity, and a diminished competitive capability.

The goal of the project is the creation of a program that is focused on improving safety for all personnel and raising the state of readiness for the organization by understanding and mitigating risk and instilling an ever-improving culture of resilience.  The business case should demonstrate the value of performing the project.  For this part refer to the Business Continuity Institute (BCI).  The BCI is a leading authority in the field of business continuity.  The BCI offers a paper for download that details how business continuity delivers ROI.  This section can also leverage relevant industry requirements.  These are often the driver for the creation of a BC/DR Program.  Depending on the industry, the ability of an organization to continue operations can hinge upon proving it has an effective BC/DR Program.

While the benefits and ROI of implementing a BC/DR Program can be difficult to express numerically, one way to do so is to establish the cost of downtime.  The factors involved in determining the cost of downtime will vary greatly from industry to industry and organization to organization, but if we can have a few minutes with the CFO, we may be able to derive a dollar amount that can adequately highlight the value a BC/DR Program will bring.  (The CFO would make a great Executive Sponsor – keep this in mind for later.) Ask for an estimate of the losses expected for a day where no work activity could be performed.  If you are part of an organization where the products and services provided are extremely time-sensitive, the cost of downtime may be measured in hours, rather than days.  In either case, the value of a BC/DR Program is in improving safety for employees and mitigating against the cost of downtime.  Be careful not to infer that a BC/DR Program will ensure safety or that downtime can be completely avoided.  A BC/DR Program can only promise to improve safety and minimize downtime.

The business case will also need to detail the requirements for the project.  In this section we need to provide information on what will be done, who will do it, how it will be done, and the timeline (when) for completion.  Who will depend on how many people we can involve.  If it’s just going to be you, you may want to include estimates for contracting with outside consultants.  If it is just you, be savvy with the timeline estimate because the revision process for the business case will most certainly include shortening the project time frame.  These project requirements will set you and the organization up for success.  Understanding your current team’s high-level bandwidth, level of effort, and deadlines will help you determine the resources required to meet your project goal.  We see too often organizations asking employees to “Just Do it!” and these eager employees struggle with trying to do more with limited resources.  Planning will provide a logical progression to achieve success and meet your organization’s goals.

We can be more certain regarding what will be done and how it will be done.   Here are some traditional deliverables (what will be done) for the project:

  1. Business Continuity Policy

  2. Business Impact Analysis

  3. Threat Evaluation

Understand that there is a debate within the Business Continuity industry over whether to perform the Threat Assessment or the Business Impact Analysis (BIA) first.  We will not wade out into that discussion in this installment; although you can see we’ve placed the BIA before the Threat Evaluation.  Our position is that the BIA should come first; however, there is enough flexibility in the sequence that they can be performed concurrently if desired.

The Business Continuity Policy will establish the requirements and responsibilities for the BC/DR Program.   The Threat Assessment will examine the likelihood, impact, and state of readiness for threats to the organization, and the BIA will establish the Recovery Time Objective (RTO) for the processes engaged by the organization.  (The RTO is the measurement of time in which a business process or service must be recovered following a disruption.)  Note that we are referring to our deliverable as a Threat Assessment, rather than a Risk Assessment.  These are two different things.  A threat assessment is identifiable with standard business continuity procedures while a Risk Assessment is wider in scope.  The Threat Assessment and BIA will provide the background and organizational understanding for establishing the program.

Prior to writing the Business Continuity Policy, it will be helpful to review a few resources:

The documents above will give you the essential steps for completing the tasks required to starting a program, and, more importantly, will provide you with an overall understanding of what is necessary for establishing a successful BC/DR Program.

As you formulate the Business Continuity Policy, cite the need for a Steering Committee.  The Steering Committee should include an executive sponsor – someone from upper management who agrees to serve as the chair of the committee.  (Recall the reference made earlier to the CFO.) The executive sponsor provides a valuable top-level presence to the program, functions as the voice of the program to other members of executive management, and assists in avoiding and ending impasses that could occur between equals.  Include a suggested structure for the Steering Committee.  In addition to the Executive Sponsor/Chairperson and the BC/DR Manager, propose that leadership from the business areas of the organization also serve as committee members.  Their support for the program will be essential to long term success.  We will eventually request each business area participate in the BIA and in building and maintaining recovery plans.

 Designing and delivering an effective BIA is a major endeavor.  The Business Case should include the BIA scope, design, and delivery method(s).  There is some cross over here between Project Initiation and Project Planning.  We will need to plan the project at least at a high level in order to provide an idea of the scope of the BIA.  Determining the scope of the BIA is the first task.  The size and structure of the organization as well as the staff that can be allocated to the task will be considerations.  If the staff is not considerable, but the size of the organization is, it may be necessary to implement the BIA in carefully planned phases or to narrow the scope to a limited portion of the organization.  Part of that determination should include the implementation method(s).  Face-to-face meeting are preferred, but they may not be feasible given resource restrictions.  The use of a business continuity software tool may  help as well.  Distribution of electronic files developed in Word or Excel can be effective, but compiling the data for analysis and reporting can be time consuming.  A blended approach to implementation is often required given restrictions on travel and staffing.  If company culture allows consider engaging an external consulting firm to collaborate on the design and provide the delivery of the BIA.  This may be the best possible use of any financial resources the project may include as the results of the assessment will be delivered along with external endorsement.

As for BIA design requirements, capture the need to measure impact using a qualitative and quantitative method.  Many organizations allow BIA participants to provide their opinion on how serious the impact of the outage would be within their area of specialization.  This is not recommended as most people are passionate about their work and find it difficult to provide an estimate of impact without allowing that passion to bias their assessment.  If specific criteria are provided for determining impact, the BIA results are more likely to represent an accurate depiction of how an interruption would affect normal activities.   This will be vital for selecting appropriate recovery strategies later.  Include the time frames in which RTOs will be expressed.  Provide a Tier structure that defines how processes will be categorized.

The policy should also state that the BIA will capture dependencies on IT assets and vendors.  Speaking with IT leadership is advised as IT may already have RTOs and classifications for applications and assets.  Sharing the same measurements, if possible, will simplify the mapping of IT dependencies and the identification of gaps between business needs and IT capabilities.  Detail the need for IT to provide current application Recovery Time Actual (RTA) and Recovery Point Actual (RPA) information.  The RTA is a measure of time in which it has been demonstrated that an application or other IT asset can be recovered.  The RPA is a measure of time indicating the true age of the data associated with an application that can be recovered by IT.   In some cases a disruption may mean that data entered into an application will be lost if it was entered within a certain time period prior to the disruption.  These measurements will ideally come from the results of IT recovery exercises, rather than estimates of what is currently possible.

Include the minimum requirement for refreshing the BIA in the policy.  Many organizations will perform the BIA on an annual or bi-annual basis.  The available methods of delivery and staffing will factor into how often the BIA can be repeated.  If a software tool to support the BC/DR Program is available, indicate that the BIA should be updated whenever there is a change in how a process is performed, where it is performed, or if the technology utilized or the role of a supporting vendor is amended.  Maintaining BIA data continually allows the organization to be more confident in the selection of strategies for recovery and more efficient in managing the resources allocated to enabling those strategies.

The Threat Evaluation should provide a score for potential threats to the organization that considers the likelihood of the threat and the expected impact if the threat were realized.  The Good Practice Guidelines provides a useful scoring model for threat assessments.  Enhance the model by accounting for any mitigation measures in place to reduce each threat.  This will ensure that the most likely and most impactful threats come to the forefront.  In order to determine the likelihood of each threat, examine historical disaster frequency data.  Here are a few websites that may be helpful:

Understand that accounting for every conceivable threat is not possible.  Try to keep the analysis simple.  The assumption should be that both the BIA and the Threat Assessment will evolve and improve over time and as the organization changes.

The policy should include specifics for program assessment and reporting.  Include information on the standards that should apply to the program based on your review of IS22301 and other relevant industry-specific requirements.  Your location in terms of state/province and nation may require additional compliance standards for the program.  The standards ultimately adopted by the organization, as well as those applied by your industry and government entities, will drive much of the design of the status reporting that is necessary for the program.

Internal and external audit findings should be part of the program reporting requirements.  Reach out to the Internal Audit Department if possible to request a collaborative effort on areas of compliance and to introduce them to the relevant standards.  For BIAs, include reporting on completion rates, updates, reviews, and overall approval statuses.  Outline reporting on the RTO and Tier results from the BIA.  Reports detailing dependencies and any gaps between business needs and IT and vendor capabilities should be outlined.  Sample Threat Assessment reports are available online.  The threat assessment is not something that will need to be refreshed often.  It will rather be repeated for all locations for the organization and for newly acquired locations should the organization experience growth.

Following the advice provided here, a very persuasive business case can be developed to support the need for a BC/DR Program.  With the steps provided herein completed, we are through Phase 1 of the project.  Watch this space for the next installment covering Phase 2 – Project Planning.