Three things in life are certain: death, taxes, and the IT department’s opposition to whatever the business continuity team wants in terms of technology recovery objectives. Usually originating in an excess of stress and a lack of understanding, this attitude can sometimes be softened by empathy, education, and relationship-building.
Related: Learning to Talk to Your IT/DR Colleagues
Summary
- IT often pushes back on recovery objectives because the “why” behind BIAs never reaches them, and the work feels like added pressure.
- BC teams can reduce resistance by educating IT on the BIA process, involving them appropriately, and getting leadership to formally approve objectives.
- The goal is partnership, not a blame game, so gaps can be surfaced and closed over time.
Like Cats and Dogs
I’ve been a business continuity consultant for 27 years. One thing experience has taught me to expect is that at most organizations the IT department and the BC office will get along like cats and dogs.
Nine times out of 10, the IT department has an intensely skeptical, if not reflexively dismissive, attitude toward whatever the BC office says are the necessary recovery objectives for the organization’s applications and computer systems.
This happens even when the proposed recovery time objectives (RTOs) and recovery point objectives (RPOs) come out of a very solid business impact analysis (BIA). Such BIAs, executed with the participation of experts throughout the organization, represent a broad-based determination of how soon after an outage various systems and apps need to be restored to avoid an unacceptable level of damage—financial, reputational, or whatever it might be.
Too often, IT doesn’t know this background and doesn’t want to know it.
Instead, they say, in so many words, that the numbers are wrong, the process flawed, and the BC practitioners incompetent. Sometimes, I have the feeling that if the BC team said the sky was blue, IT would say, “No, it’s white.”
Going on Hunches
IT almost always think they know best regarding when apps, systems, and processes need to be restored. But their ideas are usually based on hunches rather than the consultative, systematic, impact-focused assessments that inform the BC team’s findings.
Often someone senior in IT will dismiss the BC team’s results by saying they did things differently at their previous employer, or they’ll say (incorrectly) that the business departments always say everything must be restored immediately. Neither of these arguments engage with the substance of the BIA.
Many IT teams seem to find enjoyment in saying everything about the BIA is wrong and take pride in derailing the process, if they can.
If you detect a note of personal frustration in the above remarks, you’re not wrong. As an advisor helping organizations improve their resilience, I’ve run into this situation more times than I can count.
You know what’s ironic? I’m an IT person. Before starting MHA, I coordinated IT disaster recovery for Bank of America’s Southwest region and was a Systems Programmer. In fact, MHA’s senior consultants are all deeply versed in IT, but we’ve all encountered this kind of resistance.
Understanding IT’s Perspective
This issue looks very different from IT’s point of view.
Expected to perform at 120 percent, but only being supported 20 percent, the IT staff must worry simultaneously about production, information security, the network, multiple applications, and the organization’s cloud-based services.
They don’t have enough time or money, but they are expected to keep everything working with no downtime. Meanwhile, the employees are practicing iffy digital hygiene while cybercriminals, now assisted by AI, are working overtime to break into the system and lock everyone out unless a ransom is paid and/or steal everyone’s data.
And now here comes the BC department saying, “By the way, you need to be able to restore these 20 or 30 or 50 systems, applications, or processes within four hours of an outage. Can you do it?”
From IT’s perspective, a single, seemingly off-hand line in a BIA can establish a requirement it would take 100 servers to meet.
Already worried about not meeting the sky-high expectations they are working under, IT sees BC’s requirements as creating more pressure and more chances for them to fall short.
Looked at it in that light, maybe it’s no wonder that IT’s default response to the BC team’s proposed recovery objectives is “You’ve got to be kidding me.”
Turning Conflict into Cooperation
There is no easy solution to this conflict between two legitimate priorities. But there are things the BC office can do to soften IT’s opposition.
Organizations that succeed in building strong BC and IT partnerships usually do three things well: they educate IT about the BIA process, involve IT constructively in the process, and ensure management formally supports the recovery objectives that emerge from it.
BC teams need to help IT understand what a BIA is and how it works. Many IT teams oppose recovery objectives because they assume the numbers were produced arbitrarily or driven by emotional business demands. In reality, a properly conducted BIA is a structured, methodical process grounded in operational impact and validated by experienced business personnel. BC teams should explain the methodology to IT upfront, including how interviews are conducted, how recovery priorities are determined, and how the final results are validated and approved.
It can also help to involve IT appropriately in the BIA process itself. Some organizations prefer to keep IT out of business interviews to avoid influencing the responses. Others include selected IT personnel to ensure technical dependencies are properly understood. Either approach can work, but what matters is that IT understands the process and feels included rather than blindsided by the outcome.
Another important step is validating the results through common sense and business alignment. Recovery priorities should reflect the organization’s core mission and operational realities. A hospital should prioritize patient care systems. A utility should prioritize systems related to generating and distributing power. A distribution company should prioritize fulfillment and shipping operations. When IT can see that the recovery objectives logically align with the organization’s mission, the process becomes easier for them to accept.
Formal management approval is also key. One of the biggest frustrations IT departments express is that organizations conduct BIAs but never formally approve the results or fund the improvements needed to achieve them. If leadership signs off on the recovery objectives, IT can begin building realistic roadmaps and requesting the resources necessary to close gaps over time. Granted, the BC team has limited ability to make management do its part.
Above all, BC professionals should approach the process as a cooperative effort rather than an audit or confrontation. The purpose of the BIA is not to embarrass IT or prove anyone wrong. It is to establish a realistic foundation for improving the organization’s resilience over time.
If BC teams can educate IT, involve them constructively, validate results, and maintain a spirit of cooperation, the IT team is much more likely to give them a respectful hearing.
The Path to Partnership
IT teams are typically dismissive of the BC office’s findings regarding recovery objectives. This tension usually results from misunderstandings, stress, and competing pressures and priorities.
The good news is that this conflict can be reduced through education, transparency, and cooperation. When organizations conduct rigorous BIAs, involve IT constructively, validate recovery objectives carefully, and secure management support, they create a stronger foundation for resilience planning.
MHA Consulting has extensive experience helping organizations improve collaboration between BC and IT. Contact MHA to learn how we can help your organization strengthen its BIA process, improve recovery planning, and develop a more effective and cooperative resilience program.
Further Reading
- Bridging the Gap: Aligning RTOs Between IT and the Business Units
- RTO vs. RPO: How to Resolve Conflicts Between Business and IT
- Aligning Business Recovery Efforts with IT Disaster Recovery
- Learning to Talk to Your IT/DR Colleagues
- Stack Attack: A Brief Guide to the IT Stack for BC Professionals
Frequently Asked Questions
At a typical organization, what is the relationship between the business continuity team and the IT department like?
In many organizations, the relationship is more strained than collaborative. The two teams often clash when it comes to recovery expectations and what is technically achievable. The BC office focuses on business-driven recovery requirements, while IT is preoccupied with providing computer services to the entire organization.
What methods do the BC team and the IT department, respectively, use in determining recovery objectives?
The BC team typically bases recovery objectives on structured business impact analysis, drawing on input from across the organization to determine how quickly systems must be restored to avoid unacceptable business impact. IT, on the other hand, often relies on personal judgments about impacts coupled with their knowledge about what is realistically supportable within current constraints.
How does the IT department typically respond to the recovery objectives put forward by the business continuity team?
IT teams are often skeptical of the recovery time and recovery point objectives proposed by BC. They frequently characterize those objectives as unrealistic and arbitrary while dismissing the validity of BC methodology.
What are some of the background reasons behind IT’s impatience with BC?
IT departments typically operate under significant pressure, managing production systems, cybersecurity demands, network complexity, and cloud environments with limited time and resources. They are expected to maintain near-continuous availability while also dealing with constant change and increasing risk. Against that backdrop, BC recovery targets can feel like additional pressure layered on top of already stretched responsibilities.
What can the BC team do to improve its working relationship with the IT department when it comes to recovery objectives?
BC teams can improve the relationship by clearly explaining how the BIA process works, including how recovery objectives are derived and validated. Involving IT appropriately in the process and ensuring they understand the methodology helps reduce skepticism and defensiveness. It also helps to frame the work as a joint effort to improve resilience rather than an evaluation of IT performance.
Why is it important for the BC office to win IT’s cooperation in setting recovery objectives?
If IT and BC do not align on recovery objectives, the organization runs a risk that an outage will cause significant operational and financial damage.
