|
by Philp
Jan Rothstein, FBCI
The Right Tool for the Right Job
"Man is a tool-using animal...
Without tools he is nothing, with tools he is all" - so said Thomas
Carlyle (1795-1881). When it comes to contingency planning, Carlyle could
not have guessed how appropriate his observation would be. Software tools
can streamline the disaster recovery or business continuity planning process
- or turn it into a nightmare.
- A major financial services organization invested 15 person-months'
effort in customizing an enterprise business continuity software package
- only to learn much of this work would have to be re-done for compatibility
with the newest software version.
- A medical malpractice insurer spent several thousand dollars on a
business recovery software product and never actually used it.
- A mid-size, regional bank was frustrated in their attempt to implement
a comprehensive business resumption plan based on a software product
that was not designed for the specific requirements and regulatory issues
of a banking environment.
- A pharmaceuticals company with complex operational requirements built
a corporate headquarters contingency plan in under six months based
on a sophisticated, relational-data-base-driven software tool.
- A large utility consolidated their storm response plan, crisis management
plan, IT disaster recovery plan, and corporate office recovery plan
into an integrated, consistent structure using a business continuity
planning system - and then enhanced their program through addition of
an automated emergency notification system.
- A large hospital automated and streamlined their I.T. data backup
and restore process with a software product which disclosed that some
essential data had previously been overlooked and not consistently backed
up.
- A 200-employee financial services firm built a business continuity
plan to provide for relocation of their call center and administrative
offices to a backup facility using a word-processor approach.
Many excellent business continuity and disaster
recovery plans have been implemented with little more than a word processing
program - and sometimes less. On the other hand, there are several aspects
of contingency planning which lend themselves to effective use of software
tools. Often, this is a function of the size, nature, structure and complexity
of the organization as well as the specifics of the continuity strategy.
Software is not a panacea for contingency
planning. It will not replace an expert, whether staff or consultant,
to guide the process and formulate strategy, although it may offer some
useful information in these areas. It will not make business decisions
for you. It will not magically produce a continuity program overnight,
and it may or may not reduce the overall level of effort.
On the other hand, the right software
tool can introduce structure, enhance maintainability, and even build
credibility of a well-thought-out continuity strategy. It can also prompt
the contingency planner to address aspects which might otherwise be overlooked.
What's out There?
There are several types of software products lumped into the ?business
continuity? category. Specific products are likely to overlap categories,
and some of the distinctions and overlaps among these types of software
tools can quickly become confusing Most of the software tools fall into
one or more these general categories:
- generalized business continuity planning
- data center disaster recovery
- telecommunications network or facility disaster
recovery
- business impact assessment or risk assessment
- recovery exercise planning and management
- environment-specific tools, such as for banking,
universities, call centers, trading
- floors, manufacturing
- project management
- real-time recovery management
- asset management and inventory tracking tools
- emergency personnel notification
- community emergency management
- crisis management
- data backup and recovery.
Most of the products operate on a PC or server,
although a few products are Internet- or intranet-based. For a multiple-location
or international enterprise, these may be important considerations, especially
if several individuals will be updating and accessing the software and
data.
Local-Area Network (LAN) server or
multi-user options for some packages are usually priced higher. Some of
the data backup and recovery products are mainframe-based. Windows graphical
user interfaces are common to most of the more sophisticated PC-based
software tools and may improve usability.
Watch Out!
Without a doubt, the most common pitfall in acquiring a contingency planning
software tool is falling in love with the software before figuring out
the business requirements - or even devising an appropriate continuity
strategy:
- a recovery services provider may offer a bargain deal on a software
package bundled together with their recovery services, which seems too
good to pass up;
- a staff member may have experience with a particular product at another
company;
- a slick sales pitch wins over whoever signs the checks - "just
buy our product, and a contingency plan will magically appear? - or
so it seems;
- management pressure to show some tangible work product could be met
quickly by using a canned package to deliver some impressive boilerplate
documentation.
As obvious as this may seem now, be warned that
many contingency planning software acquisitions are made on impulse. At
the least, a succinct list of specific requirements could avert a lot
of grief down the road. A matrix ranking business requirements vs. product
attributes and suitability to task, as well as both implementation and
ongoing effort and costs, can be invaluable. Don?t forget to include the
base option of using off-the-shelf software (word processing, spreadsheet,
project management, data base).
The second most common pitfall is
acquisition of software which does not fit the environment. This may occur,
for example, when an enterprise already holds a license to a product for
data center recovery, and someone decides to use the same tool for business
line contingency planning. Some tools can do both - few can support both
tasks particularly well.
The third most common contingency
planning software pitfall is trying to use a tool which does not fit the
enterprise. Remember that even the best software tools are intended to
suit a wide variety of technological environments, types of businesses,
business structures, cultures, threat/recovery scenarios, geographical
dispersion and levels of expertise. Even the best-of-breed contingency
software cannot be all things to all enterprises.
One of the best ways to avoid
these three pitfalls is to request a trial evaluation period of one or
more products which appear to match the enterprise requirements. Many
vendors offer trial periods for either limited or full versions of their
software for up to thirty days. Many packages offer model or sample contingency
plans which can be handy to experiment with the structure and usability
of the package, as well as for training.
The Price
Is Right
Many enterprises successfully implement a contingency plan without any
software tool at all. In many cases, a good book on contingency planning,
some careful research and training, plus off-the-shelf word processing,
spreadsheet, project management and database tools - your standard office
suite - can do the job.
As for the low end of both cost and
features, there are word-processor-based contingency planning packages
which typically provide templates, forms, outlines, and content which
can be easily tailored. These can cost as little as $100. At the high
end are products which typically offer such features as relational databases;
graphical, windowing user interfaces; multi-user networking; security
and access controls; audit trails; and report generation. Costs range
well into the tens of thousands of dollars. In between are a variety of
products which may have varying degrees of data base support and functionality.
Be sure to consider all of the cost
factors and not just the purchase price. A hundred-dollar tool may end
up costing far more over time than a $20,000+ tool - all too often, the
purchase price turns out to be a small percentage of overall cost, yet
'sticker shock' drives the purchasing decision.
In addition to purchase price, typical
cost factors may include:
- training (and retraining over time)
- travel (e.g., for training, user groups)
- ongoing software maintenance and new version upgrades
- ongoing support availability and costs
- customization effort and costs
- PC's and other equipment (or upgrades) to run the software.
Often, recovery service vendors such as recovery site
providers or consulting firms bundle their contingency software along
with their other services - e.g., a ten-thousand-dollar package free if
you sign up for a recovery site. Remember that the specific product may
not be suited to your enterprise needs, and that you will be probably
end up paying ongoing maintenance fees for this product. All too often,
organizations struggle to implement these "free" systems - at
a higher overall cost than if they purchased another product outright.
Ongoing maintenance and support
costs may range from five to twenty percent of the initial purchase price
(or of the "list" price) or of the product price at the time
of renewal.
New software versions may or may not
be included in the ongoing maintenance and support agreement. In some
cases, maintenance releases may be included but major upgrades may cost
more. Remember that upgrading to a new version may require considerable
effort, especially if the software has been customized. Upward version,
platform and technology compatibility should also be considered.
The Right
Tool for the Right Job
In choosing a software product, consider who is going to be designing,
implementing and using the contingency plan. If a single contingency planner
will be doing all of the work, a complex product may prove counterproductive.
On the other hand, a geographically diverse enterprise may choose a server-based
contingency planning software tool which can offer the ability to coordinate
input from multiple locations as well as provide access to the contingency
plan wherever it may be needed.
The culture and style of the organization
should not be ignored. It is unlikely that any single software product
will be comfortable for both a conservative, traditional enterprise and
an aggressive, high-technology company.
Just as important as matching the
software to the organization is a compatible methodology. Every contingency
planning software tool is based on the vendor's concept of an appropriate
plan development, implementation and ongoing management methodology. That
methodology may or may not be appropriate.
Among the first stages of the contingency
planning process are the business impact assessment (BIA) and risk impact
assessment (RIA). These assessment processes are addressed by several
of the contingency planning software tools to some degree.
Making
it Work
Once you have chosen and acquired a contingency planning software tool,
the fun part really begins. A sample or demo plan provided by the software
vendor can be very helpful for training. Some vendors offer training programs
on-site or at their own facilities; most offer consulting assistance.
A contingency plan is
a living structure which requires continual nurturing. Some packages have
steep learning curves, so when a new contingency planner or business-line
staff member is brought on board, costs can escalate. Some software vendors
offer regular training programs which could ease this burden - as well
as add cost. In a high-turnover organization, this could be a major concern.
The best software tools are especially
flexible. Customization and tailoring can be done through control fields
or files instead of programming. This flexibility even extends to terminology
and can really pay off when migrating to future software versions.
Getting your enterprise-specific information
into a contingency planning software package can be trivial or an ordeal.
Some packages offer convenient structures and tools to import data from
other sources. At the least, any package should provide the ability to
import documentation from a standard word processing program such as Microsoft
Word or Corel WordPerfect while maintaining existing document formatting.
Some packages can generate printed
data collection questionnaires, or offer data collection utilities which
can be customized and distributed. Some even link dynamically to external
data bases so that you can avoid maintaining essential data in two systems.
These features are especially valuable for such volatile data as telephone
directories and network or equipment configurations, which may best be
maintained outside of the business continuity area. On the other hand,
data ownership, security and synchronization could become important issues
if external data bases are utilized.
Of course, your living contingency
plan is going to be continually altered to reflect current business, environment,
technical, staffing and other information. Some of the more sophisticated
software tools provide audit trails and tracking mechanisms for plan modifications.
This can be particularly crucial if several people are modifying the contingency
plan. Continual maintenance and updating of the contingency plan make
version control an important feature of any software tool. Some software
tools even track distribution of copies of the contingency plan documents.
Contingency plan security and access
control should not be ignored. The contingency plan is likely to contain
sensitive, if not confidential, information about the organization. Security
controls for access to or modification of this data are built into some
of the more sophisticated packages. Security controls should be flexible
enough to allow for hierarchical access as well as compartmentalized access
(e.g., separate business units).
Vendor stability and longevity should
not be ignored. Since the early 1990's, the contingency planning software
industry has gone through a dramatic consolidation. Go with a vendor who
is likely to continue meeting your enterprise's evolving needs years from
now - and clearly spell out those expectations in the purchase contract.
A software escrow agreement - where source code is stored by a trusted
third party in the event the vendor fails - may be warranted.
When
You Need It Most
It is easy to forget the real raison d?etre for contingency planning software
- to facilitate the handling of and recovery from disruption. Usability
of the generated plan during a crisis should be factored into the evaluation
process. For example, the more sophisticated packages typically provide
the ability to generate segmented subplans by individual, department,
business unit, facility or location, while still managing the underlying
information globally.
Some packages are designed to be used
from a PC or laptop to manage the recovery process. Local-area network,
Internet or intranet-based tools may or may not be accessible during a
disruption, although the ability to coordinate and track tasks and events
could be helpful during a disruption.
Some software tools incorporate features
useful during the planning and execution of exercises. In addition to
managing the exercise process, these features may include the ability
to track contingency plan corrections or modifications which are uncovered
during each exercise. These same features can be useful to track and address
problems during an actual recovery.
Special
Tools for Unique Needs
Besides contingency plan development tools, there are many other types
of software products which may be relevant. Some examples include:
- Automated call-out notification systems, such as Dialogix, or Rapidreach.
- Data backup and restoration automation software tools for mainframe
or server environments.
- Recovery exercise planning and management tools, such as PlanAHEAD.
- Specialized tools for the unique needs of certain environments, such
as TC/DRP, CC/DRP and HD/DRP for telecommunications, call center or
help desk disaster recovery; BCP Business Continuation Plans For Colleges
And Universities or Professional Law Firms.
- Data recovery tools for damaged or corrupted disk drives.
TEN RULES FOR CONSIDERING CONTINGENCY
PLANNING SOFTWARE
- Know what you need - and what you don't need. Don't expect a software
package to identify your requirements or define your strategy.
- Match your environment. Software tools should match the culture,
environment and realities of your organization. Even the best tools
on the market cannot be all things to all enterprises.
- Be objective. An impartial validation of your software needs and
options can save a lot of grief. A consultant or auditor may provide
a useful perspective. Include all of the potential users in the evaluation
process.
- Be clear what the software is going to do - and not do. Make sure
it specifically matches your needs and objectives - for example, a business
continuity planning package may not adequately address your data center.
- Don't go overboard. Complex, sophisticated software tools may not
be productive or even usable in every environment.
- Go for functionality, not "sizzle." Web-based systems and
client/server support may be snazzy, but make sure they really add value
for your environment.
- Think 3-5 years out. Look at potential future requirements, both
business and technological. Will the package meet your needs in a few
years? Will the vendor still meet your needs, or even be around?
- You don't always get what you pay for. Focus on results, not price
- and not on sales pitches. Kick the tires, drive it around the block
before committing. Look at all of the initial and future costs, not
just the sticker price.
- Who will be using the software? If business-area staff will be heavily
interacting with the software, don't acquire a package with a steep
learning curve or your training effort may outweigh your contingency
planning effort.
- Know who you are dealing with. Thoroughly check out the vendor's
references, track record and financial stability.
Philip Jan Rothstein, FBCI,
is President of Rothstein Associates, Inc., a management consultancy emphasizing
business continuity. He is publisher of The
Rothstein Catalog On Disaster Recovery and editor of the book Disaster
Recovery Testing: Exercising Your Contingency Plan. He was elected
Fellow, Business Continuity Institute in 1994 in recognition of his substantial
contributions to the industry.
Copyright (c)2003, Rothstein Associates Inc. All Rights
Reserved.
|
