Learning to Talk to Your IT/DR Colleagues

In some ways, the relationship between business continuity professionals and their colleagues from the information technology/disaster recovery team can be compared to that of a man who is drifting in a hot air balloon and asking for directions.

Imagine the balloonist seeing someone a hundred feet below on the ground and calling down to them, “Would you mind telling me where am I?” If the person answers, “You’re a hundred feet up in a hot air balloon,” there is a good chance he or she is an IT/DR person.

Or at least this is how the story goes when told from a BC person’s point of view.

The information is correct but also not very helpful, in that it doesn’t help the balloonist understand where they are in the larger context or assist them in getting to where they need to go.

However, if an IT person were telling the story, the takeaway might be that the balloonist brought the situation on themselves by asking such an imprecise question.

Regardless of how you interpret the story, the fact is that BC people (with their focus on recovering business processes) and IT/DR people (with their mission of restoring data and recovering computer systems) are very good at misunderstanding one another. These gaps in their mutual understanding often have real costs for their BCM programs.

The greater the gaps are, the greater the likelihood that the solutions that are put in place won’t meet the requirements of the organization. They will either over-deliver on system availability or data protection, costing more than is necessary, or they will under-deliver, not providing sufficient protection of the organization’s critical information or systems.

Another thing that can happen is the solutions implemented might not take account of critical dependencies among the various systems and applications, leading to serious problems down the road.

Clearly, the business continuity team, the IT/DR team, and the organization overall would all benefit if the BC and IT folks learned to communicate better.

Today’s post is based on two assumptions:

1. A good way of improving your communication with someone is to understand how the world looks from their point of view.
2. Most of the people who come across this post will be business continuity people rather than IT/DR folks.

With those assumptions as starting points, the post will try to advance the goal of improving BC–IT communication by the simple method of explaining what IT/DR people do all day and why.

A last point before we begin: In the following explanations, it doesn’t matter if the IT person is an employee, a contractor, or a consultant. The activities are the same for each type of worker, as are the potential communications pitfalls in the back and forth between them and the people on the business continuity side.

What the IT/DR Team Does All Day

The “Easy” button only exists on TV. In real life there is nothing easy about the complex, interdependent systems which the IT/DR team is responsible for protecting and restoring in the event of a disruption.

The main job of people working in IT/DR is to take the requirements that come from the BIAs and risk assessments and devise a recovery strategy that will meet those requirements in the event of a disruption.

Such a strategy typically addresses the following elements:

• Data protection. This is more than just data backup. For more information, see our recent post, “Data Loss Is Inevitable: These Tips Will Help You Recover.”
• Hardware redundancy. Many physical and virtual server protection strategies require the deployment of redundant hardware to allow for the swift recovery of operations after an event.
• Network redundancy. The IT/DR team must study the nexus between providing maximum backup network capacity and controlling costs, collaborating with the BC team in striking a sound balance, and then implementing the agreed-upon level of network redundancy.
• Software redundancy. Some recovery strategies require that key software be available in redundant implementations to protect critical apps and systems.

In addition to devising and implementing the IT recovery strategy, the IT/DR team does the following:

• Determines the data center setup that would best meet the strategy and manages the implementation of these centers, whether they are owned by the organization, co-owned, or in the cloud.
• Handles crisis management as it pertains to DR. (See last week’s post for more information on crisis management.)
• Ensures that the documentation explaining how to recover the various systems and applications is complete, correct, and at an appropriate level of detail. For example, if you have a database procedure, the documentation has to be detailed enough so that any competent Oracle or SQL person, for example, can perform the function based on the procedure documentation.
• Handles project management in terms of organizing and executing recovery tasks. This requires detailed knowledge of system and application dependencies and experience with technical project planning and orchestration.
• Devising overall recovery strategy. In the final analysis, the IT/DR team must determine whether the strategy meets the requirements and objectives set by the business side. The IT/DR person can share their insight into what the various projected requirements would cost, thus guiding the business side to realistic requests. Ideally, IT/DR people working in this role speak some business language and understand business needs as well as technology.

By understanding a little better where their IT/DR colleagues are coming from, BC professionals can better collaborate with them, to the benefit of both teams and the organization overall.

Such an understanding can ensure that the next time you are in a balloon and ask an IT/DR colleague for directions, you can frame your request in terms that make sense to them, and thus elicit a response that is helpful and actionable.