Five things to consider when rolling out business continuity software

By David Farr, CBCP.

I’ve just spent the last three and a half years rolling out, supporting, and improving business continuity software tools for a major high tech company. Before I begin a Masters program, I wanted to share some of my thoughts, in hopes of making life easier for others involved with BC software. If you are about to roll out a BC software tool, or are thinking of changing tools, consider the following tips.

1. It’s all about requirements, requirements, requirements

This first point is by far the most important. If you don’t know what you are looking for in a business continuity software tool, you probably won’t get what you want. Since most software is implemented using a project management methodology, your firm will likely identify the budget, timelines, people resources, and other such constraints. It’s also important to think about technical requirements. For example, would your company prefer to let the vendor host the software or would they rather install and maintain it on their own servers? What database platforms does your company support – SQL Server, Oracle, something else? How fast are your organization’s end-user computers? What operating systems do they run? These and other technical requirements can be gathered by consulting your information technology department.

More important still are the business requirements. Identifying all of the stakeholders who will need to use the tool – from end users to administrators to upper management – is crucial. If you do not consult with your users and document their needs for the software, you will have headaches later. Any requirements you didn’t gather will come back in the form of complaints and endless change requests (see point 4 below). Moreover, most people are more likely to embrace a new piece of software if they have been involved in rolling it out.

2. Know what’s out there

The business continuity software market is a dynamic, constantly changing landscape. Many people have looked at the offerings available at various times and said, “I could make a better one.” Some of those individuals have tried. For this reason, there are many products to choose from. A widely cited Gartner article (1) comparing various BC software products is already out of date. I know of three new products that aren’t even on its list because they were introduced after the article was written.

So, how do you choose the right one? It’s simple: go with the one that best meets your company’s requirements (see first point). Note the use of the word best. I didn’t say fully or completely or perfectly for a reason: no BC software is perfect. They all have their strengths and weaknesses. You need to go with the one that is the best fit for your organization. Comparing the competing products against your requirements will help you make an objective decision.

BEWARE THE DOG AND PONY SHOW. All vendors’ salespeople will make their products look better than they are, and say their products can meet all of your needs, even if they can’t. If you’re not sure about a product, ask for a trial version. Then you can see for yourself.

3. Talk to other firms that are using the software

Most business continuity software vendors have user groups or conferences where you can interact with other organizations that are using their software. The current economic environment has tightened some corporate belts so much that all feeling is lost below the navel, but these events are a very useful source of information. If your firm won’t splurge for you to attend a conference, you can still participate in conference calls with users from other firms.

Most user firms will give you an objective evaluation of the software and the vendor. This is particularly useful if you are about to buy a product, but aren’t sure about its reliability, support, and other aspects. It is also useful even after buying the software because other companies can share ideas with you to help you improve how your firm is using it.

4. Consider your change and incident management policies

Save yourself some frustration and accept up front that your business continuity software implementation won’t be perfect. No one’s is. Even if you miraculously gather all the requirements, choose the right software, and configure it precisely to match those requirements, you’ll likely find those requirements changing over time. Most modern businesses seem to be in a constant state of flux. Organizational units come and go, people move around, policies and systems change – all of which can affect both your BC program, and the software tools that support it.

It’s important to know your organization’s change and incident management policies (and also those of the vendor if they are hosting your business continuity software). Know what is required to make a configuration change to your production software environment and when you can do so. Understand the vendor’s release schedule so you know when you might need to do upgrades. And, most importantly, have a documented, easy to use plan for responding to problems, issues, and other incidents with the BC software. This should include not only who to contact, but also procedures for escalating urgent issues and for recovering the BC software. After all, you wouldn’t be setting a good example if your business continuity software didn’t have a recovery plan! If the vendor is hosting the software, make sure you review their recovery strategy too.

5. Training and support

I’ve seen many a software roll out fail because people didn’t want to use it. Introducing new software always means a change in how people do things, so some people will naturally be resistant. If they don’t want to use the software because they’re more comfortable with productivity software, like Microsoft Word or Excel, try selling them on the benefits. Most BC software makes maintenance, auditing, and enterprise reporting easier.

Even if you convince people to use the business continuity software, it will still flop without proper training and support. Users who are frustrated because they can’t do something in the tool are not going to be giving it positive reviews, so make sure you offer training courses, quick reference guides, and a clearly defined process they can follow to get help. Also, create a channel they can use to make suggestions to improve the software and ensure that these suggestions are documented and reviewed at regular intervals. The more you can show your users that you care about them and their opinions, the more successful your software tool will be.

Finally, make sure your company allocates enough resources to provide effective training and support. Both of these ongoing activities chew up a substantial amount of time. It is important to estimate the amount of person effort required to provide training and support before the tool goes live, and evaluate whether the required effort is changing over time. If your firm is having trouble keeping up with all the training and support requests, you might need to hire more people. If that isn’t an option, consider replacing some training sessions with videos or computer-based training and decentralizing the support by training (part-time) decentralized super users in various organizational units. Implementing these suggestions will please your users and keep you from getting overwhelmed with requests.

That’s it! If you’re about to roll out a new business continuity software tool, then I wish you luck. Considering these items in advance should help to smooth your path. But there will still be bumps along the way! That’s part of the fun, challenge, and learning experience of rolling out new software.

Author
David Farr was an Administrator and Technical Analyst of Business Continuity software tools at Research In Motion prior to starting his Masters degree at the University of Waterloo. He can be reached at dmfarr@uwaterloo.ca

Reference

(1) Noakes-Fry, Kristen. Stevens, Les. Witty, Roberta J. How to Understand and Select Business Continuity Management Software, Gartner, April 2008

•Date: 21st August 2009• Region: US/World •Type: Article •Topic: BC software
Rate this article or make a comment - click here