Every organization is a business unit that is unique in its own right. As a consequence, whether business continuity and disaster recovery are separate, mutually exclusive plans or whether they are integrated into one seamless, mutually inclusive process depends largely on the BCDR team’s discretion and the organization’s resiliency objectives. In generic terms, the disaster recovery plan is executed first in direct response to a crisis event. It is only after an emergency has been dealt with conclusively that business continuity concerns are addressed through the execution of a separate BC plan.

Organizations with a clearly defined commitment to their resiliency objectives approach the development of their business continuity and disaster recovery plans just like any other commercial, mainstream project. Goals and objectives are defined. Their requirements in terms of resources, assets and technology are detailed. Timeframes are established. The plan is put together, reviewed and improved upon. This is important for BCDR teams to define their resiliency policies in tangible terms.

The success of any business continuity project depends of a number of variables that come into play during a crisis. Nevertheless, some generic factors that are applicable regardless of industry specific parameters have been detailed below.

Managerial Backing

This takes precedence over any other factor. There is no point planning a business continuity or disaster recovery project if the enterprise’s leadership team doesn’t appreciate its importance. On the other hand, forthcoming support from the top management can translate favorably into various benefits such as:

Adequate budgetary allocations
Approvals for resource and personnel requirements
Policy outlines

Convincing the upper echelons of corporate hierarchy is not always easy but BCDR teams should do their homework and put their best foot forward. Below are some recommendations.

BCDR personnel with a strong technical background sometimes tend to overlook the commercial implications of not planning a business continuity project. Management teams become more responsive to BCDR projects when they see the monetary benefits of adopting a BCDR strategy, especially when the forecasted benefits are backed by research findings and statistics.
Lack of effective communication is another reason why many BCDR projects never get the go ahead from the organization’s top brass. Long presentations with lengthy explanations fail to make an impact.

A sound understanding of the target audience is usually a good place to start.
Next comes assessing the extent of awareness key executives who will approve BCDR projects have about business continuity and disaster recovery.
This assessment is then compared with what they ought to know in order to grant their approval.
Finally, the IT team creates a proposal that effectively guides the focus of the leadership and management teams in attendance from what they know about BCDR projects to what they should consider in order to approve the initiative.

Such an approach gives the activity a sense of purpose and can be measured later through tangible parameters for improvement.

Presentation format is another important factor to consider – be it a PowerPoint, a written report or a verbal demonstration. There is no right or wrong here. So one just has to figure out which option would work best, given the context of the proposal, its implications in terms of investment and the possible expectations of the decision makers.

Leadership and upper management become just as disinterested when BCDR projects lack clarity in terms of scope, investment, resources and duration. This can be a catch 22 situation for IT personnel because they can’t give a reasonably accurate approximation until the initiation phase of the BCDR project is underway. And a project can never be initiated without an approximation.

One workaround to this problem is being upfront with decision makers, but insisting nevertheless on being given the go ahead because a BCDR plan will prove crucial for insulating the organization’s revenue cycles in times of crisis. Another option is to reach out to key personnel in management, operations and facilities and arrive at numbers that are feasible for all the departments that would be involved. Such interactions early on also tend to come in handy later once the BCDR project has been deployed and collaboration between various teams becomes necessary.

IT personnel would also greatly benefit if they left out technical jargon and stuck to real world, layman terms while explaining scenarios to key personnel, unless the person in question is someone with a technical background. For instance, “exploring ways to improve connectivity, both within the office location as well as across the organization’s corporate network around the globe” is more likely to get people interested than “researching into possible WAN and LAN support options”. While both mean more or less the same thing, the first instance also suggests the commercial implications of upgrading network capabilities. IT staff could also take the assistance of someone from the human resources or marketing departments in this regard. This would additionally give IT personnel an outsider’s perspective on their proposal for a BCDR project.

IT teams should also make sure that the content in their BCDR plan proposals are prioritized based on criticality such that the most important information is put forth first, right at the start of the presentation, when those listening are still attentive. This should be followed by second most significant piece of data, then the third and so on.

Many proposals get rejected. And it would be unfair to attribute such a high incidence of failure to inadequacies in the plan itself. The rapidly changing technological landscape of present day businesses has made it increasingly challenging to arrive at a solution that stays relevant in the long run. And then, there are the all important and increasingly complicated concerns of data protection and adhering to regulatory norms.

Practical IT professionals, whose proposals for BCDR projects get rejected, find innovative ways to incorporate resiliency measures into everyday tasks, such as the deployment of a new server or platform. While such limited measures can never take the place of a full-fledged BCDR plan, it can still garner some amount of mileage and raise awareness amongst employees without management teams having to rethink their leadership strategies.

End User Engagement

Most IT projects imply extensive end user intervention. Nevertheless, gathering feedback from these crucial participants is often overlooked. Research has shown time and again that the extent to which end user feedback has been factored during the planning stage is directly proportional to how effective the IT project will prove. The same holds true for BCDR projects. End user engagement should be given preference while drafting business continuity plans.

Users in a BCDR project can be broadly categorized into those who plan the project and those who implement the plan. These roles can overlap, especially in organizations with a small headcount, while they are logically split into two separate teams in larger enterprises. Involvement of both types of users early on during the BCDR plan’s development is essential to lend an all round perspective to the project.

Key participants, especially those involved in implementation, should be involved throughout the entire lifecycle of the project to ensure that the practicalities of executing the plan have been taken into consideration.

Project Head with Expertise

The individual who spearheads the BCDR project must be someone with the relevant knowhow and a deep understanding of project management methodologies. IT teams also need to be realistic about their BCDR expectations. Seasoned managers with prior experience in seeing through other related IT projects would be an added advantage in this regard.

BCDR projects by nature tend to bring professionals from different departments together. In such a scenario, an effective manager with a proven track record can easily iron out any friction that might arise when personnel from diverse groups have to collaborate towards common goals and objectives. Operational bureaucracies and jurisdiction can give rise to a conflict of interests between different groups and it takes a capable manager to hold the project together despite discord and disagreements.

Besides which, IT teams can count on a process driven outline for the BCDR project. Deploying a BCDR project implies taking crucial decisions such as adoption of contextually relevant project management methodologies, adherence to industry standards, compliance with regulatory norms and many more. Over the years, experienced professionals learn how to customize such structured guidelines to suit their specific needs.

A systematic and logically segregated framework for execution is the key to consistent results and managerial executives with the expertise and formal training can vouch for such positive outcomes thanks to the knowledge they have acquired in the field over many years.

Specificity of Goals and Objectives

This might seem like stating the obvious but there is a fairly high incidence of BCDR projects that have been launched without clarity on its prime purpose. The repeated failure of such plans with a lack of focus and direction can prove detrimental in the sense that decision makers in the future might have a skeptical mindset even while hearing out a proposal for a BDCR project.

The clearer the goals and objectives of the BCDR project, the easier it is for the IT team to prioritize different aspects of the plan. Getting this step wrong can prove counterproductive as it might lead to IT teams spending hours on end fortifying processes, systems and operations that might not be that crucial to the enterprise’s commercial interests.

Operational objectives vary from department to department. For instance, the commercial implications of a crisis situation for the finance team would be very different from those for sales or marketing. Each has a unique set of processes. The systems and applications they utilize may vary. The metrics for gauging productivity and efficiency are also distinct. IT teams must look at segregating the organization into specific segments and then bring senior personnel from each of these departments together to collectively reach a consensus on resiliency objectives. Such an approach serves the dual purpose of covering all aspects of a commercial entity’s business operations as well as involving key personnel from each of the departments in the BCDR project.

The impact of a crisis situation can be severe and in many cases even lead to fatalities and irreparable damage. The possibility of such consequences mandates the involvement of stakeholder groups in the decision making process to ensure that critical aspects of enterprise’s business related undertakings are not overlooked.

Identifying Prerequisites for a BCDR Project

The execution of any BCDR project entails the allocation of funds, assets, resources and technology. A good practice is to forecast the possible requirements while outlining the goals and objectives of the BCDR project. Even the most well planned BCDR plan can fall short of serving the purpose if its implementation requirements aren’t judged accurately. The requirements for the BCDR project must be accurately established early on. Revisiting these specifications at a later stage can lead to inefficiencies, budgetary excesses, loss of time and errors. For instance, providing uninterrupted access to mission critical applications along with its data would need to be broken down into specific requirements such as:

Number of servers needed
Manner in which the databases would be distributed
Network bandwidth and speed

Similarly, a business entity might want to optimize network traffic across multiple available connections through various load balancing algorithms while simultaneously minimizing technical glitches such as latency, jitter and packet loss. Such tasks would have to take into consideration the type of connections that are available, the bandwidth requirements for various applications and programs, their traffic routing policies and so on.

It must be noted that the requirements analysis for the BCDR project will evolve as the plan becomes more detailed. Nevertheless, the foundational needs of a BCDR plan’s objectives must be outlined right at the beginning of the life-cycle.

Details such as office locations, departments, business processes, systems that fall under the purview of a specific resiliency objective and so on allow the BCDR project to unfold in a cathartic manner without deviating from its primary purpose.

The needs and requirements of BCDR project objectives can be broken down into three primary categories:

Business – How a crisis situation affects the company’s revenue and what is needed to avoid such a loss. Preventing or at least mitigating the impact on the company’s earnings is the prime objective of any BCDR project.
Functional – Ensuring the availability of procedures, execution strategies and assets, both before and after a crisis situation. Functional outcomes detail the production output of individual systems which are integrated into a broader framework to facilitate achieving BCDR objectives.
Technical – Specifications of systems and infrastructure such as network speed, bandwidth, server storage space, database distribution, prioritization of application availability and so on. Requirements depend largely on the nature, scale and complexity of operations that have to be supported by IT systems.

Such a logical segregation of the needs and requirements for different objectives allows IT teams to assess the various options available at their disposal and map them to all the possible scenarios that might arise based on the type of crisis situation. This increases the probability of the BCDR project meeting the organization’s resiliency needs. The requirements analysis for the BCDR project objectives must be completed before work on the plan is commenced.

Project Scope

The extent to which a BCDR project can positively influence operational resiliency must also be established. This gives IT teams a blueprint for the range of tasks and activities that will have to be performed during an emergency. Like requirements, the scope of a BCDR project should also be forecasted while outlining the plan’s objectives.

For example, when a crisis occurs, organizations might want to facilitate a salary advance option so that employees can offset sudden and unexpected expenses during the emergency. Although a noble initiative that extends solidarity to the employees in distressing times, the decision can backfire with dire consequences for the company if not executed and managed with caution.

A BCDR objective of this nature would entail certain implications to be considered, such as:

How will the policy on salary advances during disasters be drafted? What clauses need to be included?
What should be the employee prerequisites for availing the facility?
Should the employee’s eligibility be gauged based on the submission of supporting documents?
Which documents should the employees submit to become eligible?
What should be the deadline for submitting these documents? How will it be calculated?
What should be the deadline for submitting these documents? How will it be calculated?
How will the company take a headcount of the number of employees who want to avail the facility? Will it be through

A written form,
Registration through an online portal
A mobile application or
Any other feasible option?

This is a rare occurrence but can’t be ruled out. Does the company have enough cash flow to provide the salary advance facility for all the employees on its payrolls?
Will the employees be allowed to pay back the advance at a later stage if they want to?

This would convert the salary advance into a loan from the company.

If yes,

What should be the timeframe for paying back the loan?
Will the company levy an interest on employees for the loan? If yes, how will this be decided?
Do statutory laws make the company liable to pay tax on the loan extended to employees? This can be applicable even when the company does not earn an income through the interest charged.
What steps should be taken if the loan or part of the loan is not reimbursed within the stipulated timeframe?

Detailed descriptions of the scope in such a manner are important to give the BCDR plan clearly defined boundaries. The extent to which a BCDR plan can make operations resilient must be clearly established through the project’s scope in order to avoid ambiguities on its effectiveness at a later stage.

The last thing an IT team wants is their BCDR plan to be deemed ineffective despite having been executed as planned. The BCDR plan might have worked as expected without any glitches during the crisis. But just because a specific area of business operations does not fall within the scope of a particular BCDR objective and consequently suffered an impact, it does not mean that the BCDR plan does not justify its investment. This is why demarcating the project scope in detail is so important in the initial stages. Besides clearly stating the operational segments that different components of a BCDR plan addresses, some experts even recommend that the scope must also be explicit about which business processes the plan does not cater to. Such clarifications early on can help avert ambiguities while gauging the extent to which the BCDR project has been successful at a later stage.

Getting More Done in Lesser Time

Research shows that projects with prolonged time frames that span over extended periods of time tend to lose focus and as a result fail to meet their objectives. Besides which, personnel who implement such elaborate plans run out of motivation and individual efficiencies also get hampered. Keeping operational timeframes short allows IT teams to focus on multiple minor tasks simultaneously. This strategy works even in the case of BC/DR projects.

The entire organization should be segregated into divisions, divisions into departments, departments into teams, teams into groups and groups into individual employees. Business operations must be logically segregated based on functional objectives and then broken down to the division, department, team, group and individual level.

The BCDR project can then be split into various subprojects that consist of plans that cater to concerns of a specific entity within the organization. Various such short range plans can be deployed simultaneously in a coordinated exercise. The process can be gradually developed through as much iteration as required where operational modules are sequentially added with every new test. Finally, all the different plans can be stringed together to create an organization wide business continuity framework that can be deployed as an integrated solution.

Such a modular approach to designing the BCDR project comes with many benefits. Some of them have been detailed below:

Simplified procedures, activities and tasks
Specific procedures can be repeated multiple times without increasing the effort required
Facilitates collaboration through a process driven approach
Decentralized control and more autonomy during execution
Errors and issues are localized and can be easily fixed
Easy resource allocation
Reduced costs
Specific components of the plan can be deployed as standalone solutions

The measurement of the plan can be calibrated to a fine degree. This is another advantage of taking a modular approach while designing the BCDR framework which in turn gives organizations granular control over their systems’ operational framework. Managers can constantly keep a tab on whether the project is on schedule or not and take decisions accordingly. These regular reviews can help avert gross deviations from the BCDR goals and objectives.

Incidentally, prolonged schedules, budgetary excesses and locked in assets and resources that could be better utilized elsewhere are some of the main reasons upper management teams cringe at the prospect of undertaking a BCDR project. IT teams who anticipate a fair amount of reluctance from deciding authorities break down the entire BCDR project into single units so that resiliency objectives can be incorporated into the organization’s operational structure in phases. This is why IT teams focus extremely hard on the first unit as the results displayed during this phase help gain mileage for the subsequent phases. Many leadership teams favor this kind of approach as it allows them to stagger the expense involved.

Procedural Structure

Organizations can count on their BCDR projects being procedurally structured when an able manager with the necessary skills and expertise is in charge. Along with a structured approach to solving complex business continuity and disaster recovery related issues, experienced managers, thanks to extensive experience in the field, can accurately assess the situation and decide which project management methodology to adopt. Other managers make up for relatively less experience by adhering to conventional methodologies with a strong attention to detail. Others stick to a particular methodology either because it was best suited to their style of working or because it allowed them to reap more success, or both.

Some well known project management methodologies are listed below:

Waterfall – The most basic and easiest methodology to implement in which processes follow a sequential order and a given task is initiated only when the previous task in the production line has been completed.
Critical Path Method (CPM) – Processes are interlinked so that their various tasks can be concurrently executed in a logically determined sequence (critical path) that optimizes production efficiency.
Critical Chain Project Management (CCPM) – Here, the CPM methodology is taken a step further by giving preference to resource allocation and factoring in buffers for forecasted delays while executing critical tasks.
Agile – As the name suggests, this is a fast paced methodology that is typically characterized by many short spells of intense activity with quick turnaround timeframes. Agile is best suited to a rapidly changing business ecosystem that necessitates quick responses and frequent updates.
Rapid Applications Development (RAD) – This is another methodology immensely popular with developers where a structured approach to developing prototypes based on customer needs goes through much iteration.
Six Sigma – A methodology with a specific focus on quality control and the reduction of defects in products through data gathering and process improvement techniques. Six-Sigma is particularly useful when looking to optimize efficiency, productivity and consistency.
New Product Introduction (NPI) – A methodology that highlights cross functional interaction between different teams and divisions in an organization to deliver specific segments of a solution.
Packaged Enabled Reengineering (PER) – This is a methodology commonly adopted by IT teams looking to revamp an existing solution to keep up with the changing market trends.

Nevertheless, it’s important to mention at this juncture that once a methodology is adopted, the IT team will have to stick to it throughout the entire project’s lifecycle. Hence it goes without saying that deciding authorities must make an informed decision on the methodology they plan to employ.

As days go by, business enterprises of varying sizes – from small boutique firms to large multinational corporations – are becoming increasingly aware of the commercial benefits of having a business continuity and disaster recovery plan in place. External pressure as well, in the form of stakeholder concerns and stringent regulatory guidelines, has had its part to play.

In conclusion, it would be fair to say that a well drafted BCDR project does its bit towards business development. After all, potential customers do tend to favor businesses that can demonstrate a tangible commitment to operational resiliency through well documented and detailed policies which in turn brings in its wake a variety of intangible benefits such as brand perception, reputation and market standing. And present day entrepreneurs know how crucial these factors can be if they want to see an upgrade in their company’s financials.

See for yourself how the application works
Witness our cloud based platform’s security capabilities in action
Play around with the software and explore its features
Compare and choose a solution that’s relevant to your organization
Consult our experts and decide on a pricing mechanism

Request a Demo