Business continuity software is nothing new. If you’re reading this, you probably already use it. But should you? Are these tools keeping pace with changing times, evolving needs, and the expanding role of the business continuity professional? As with anything related to business continuity, the answer to that question isn’t a simple one.

 

The age-old, number-one, top-of-the-heap complaint about business continuity software tools is that they are not easy to use – despite the marketing claims and ad campaigns to the contrary. Even the easiest of the bunch is complex and multi-layered, particularly for administrators and power users. But in defense of vendors, they have put an emphasis on ease of use in recent years and while these tools aren’t iPod simple plug-and-play, they’re also not as tedious and incomprehensible as they once were.

 

Still, there are those who say, why bother? Why not just use Word and Excel and SharePoint? Wouldn’t that be easier? Maybe, and we’ll get to that, but it’s also quite possible that BCP software consumers need to shift their expectations of what such a tool can and should deliver.

 

“Too often, companies buy software and build their program around the software and not the other way around,” says Al Berman of DRI International. “The software should not be the governance for how you approach business continuity.”

 

That tendency seems to be rooted in a BC program start-up mentality that focuses on plans rather than process and is all too often being driven by the need to check a box in order to verify that business continuity plans are “done.”

 

Any continuity professional can tell you that business continuity plans are never done – that it’s a process, not a project. So the focus on completion is one that’s sure to backfire. The plans will be there, but they may not work when you need them, and they may not make sense for your organization if they are built using a vendor’s methodology that doesn’t take into account the unique needs of your company.

 

Software “tends to be one-size-fits-all,” says Berman. “I think the software should have basic components that walk you through the process and that the smaller software which tends to be sold to smaller organizations is more expandable and flexible.”

 

Berman cautions against a “grand plan” type of goal. “We may talk enterprise-wide, but we build bottom up,” he says. “Software should be able to do small. The basic fallacy is to always plan for worst-case scenario, but if you build for that big worst case, you are never able to deal with what truly happens – local problems. We should be building plans at the site and the planning tool has to be able to start at the site and build up.”

 

There’s an adage that says “Planning is everything and plans are useless. I think that’s really true,” says Scot Phelps of the Emergency Management Academy.

 

“Sometimes we develop continuity plans because we have a regulatory requirement to do so, but if the job is to get the individual business units better prepared, then you need to drive them to plan in a way which educates them about business unit strengths and weakness and build their competencies.” To do that, software can be a tool but it can’t be the backbone of a program, Phelps says, unless the BC program leader is “more interested in documentation” than education.

 

Phelps says that the real problems with real BC plans and programs are “not something that software can fix.” He says we should spend less time and money on software and more on “making sure people have corporate credit cards and debit cards for emergency use and a way to solve small problems quickly – like Smartphones and access to data wherever they are. These are the things that would really drive improved competency. Make sure everyone has a Swiss Army knife and batteries and water and a change of clothes in the car. That’s preparedness.”

 

Phelps says traditional software-based plan building does not focus enough on “measuring how to build competency. And that’s the one of the most important things – how you are going to quantitatively show that the organization is better prepared. Telling me that we’ve dotted the i’s and crossed the t’s in our plans has nothing to do with actually being resilient in the face of crisis. If I want something from software, it’s this: I want quants.”

 

Eric Staffin, an executive board member with the BCI-USA, is looking for more than just traditional planning software and says he favors a governance, risk, and compliance (GRC) focus when it comes to tools – with one exception.

 

“I think for someone who is starting out, who doesn’t have a program and doesn’t have the experience, there are a number of software companies providing tools that bring people to a much better place than they would have been independently. Many of these tools are actually quite good, and I have seen successful implementations of these types of software packages to help people begin their business continuity planning efforts. But where it begins to break down is when people start to understand that programs need to be established with much broader capabilities.”

 

That’s where a GRC-based tool is an advantage in Staffin’s opinion. “A GRC solution is the way to go if you are going to bet on the implementation of a software tool set enterprisewide. They are front and center from a compliance standpoint as they relate to every domain. If you are a global company, it is critical to understand the regulatory requirements around your own facilities as well as the governance activities for the products that you sell or services that you deliver. GRC solutions are typically built on an audit core and allow you to calibrate your business continuity management programs and internally driven compliance efforts.” Staffin also believes tools with a GRC bent are better able to help BC professionals and the organizations they serve to better understand and manage risk.

 

“I think the larger problem is that this is so complicated and it is really impossible to have a single solution that encompasses all aspects of the lifecycle.” That has led many BC professionals to do the “easiest thing to understand” and focus their efforts on planning for events “rather than understanding what the risks – positive and negative – really are.” And he says many BCP software tools do the same.

 

He also cautions that traditional BCP software might actually impede the progress of business continuity within the organization. “Within a large corporate enterprise, the use of small-scale software narrowly defined for a specialty area is very difficult because licensing tends to be done with more large-scale firms. Just to get a smaller player on board is a high bar to cross. And if there needs to be broad adoption by multiple parts of the firm, that makes it even more challenging to fully integrate and train. It has got to be out of the box and useful,” he says.

 

Gartner analyst Roberta Witty says she has heard all of the criticisms of BCP software and she still believes it is quite useful. “I’ve heard all of that – particularly the ease-of-use argument – that it’s simpler to use Word docs and put them in a file folder. But the problem with that approach is that when you need access to the information to do analysis, it’s almost impossible. And to keep plans updated, you have to go through every document where that information might reside. There’s a greater likelihood that a much higher percentage of plans are going to be out of date. Why go through that?”

 

“It depends on what you want to do,” she continues, “how much data analysis you want to perform. If you don’t care that you have to update a thousand plans and as long as you have a way of managing that and showing dependencies, then I guess you can choose not to use a tool. But you’ll have less intelligence at your fingertips when you approach it that way. If you use the tools, you can mature your program faster and you’ll have access to a lot more information about your organization.” CI