Classic Mistakes

Here are the five most common errors that companies make when preparing for disaster.

Computerworld |

Disaster recovery is an unpleasant task. And that makes it a low-priority project in almost all companies, says Scott Lundstrom, an analyst at AMR Research Inc.

"There are no users screaming over business continuity," he says. "So given the firefighting nature of most IT organizations, [disaster recovery] never gets the resources it deserves."

Because disaster recovery takes a back seat to other IT projects, mistakes are bound to happen. We asked IT managers and other experts what's most likely to be forgotten or overlooked in disaster recovery planning. Here are the five classics.

MISTAKE 1: Failing to do your homework.

IT groups often neglect to ask users and line-of-business executives which applications they need most. This leads to faulty assumptions about disaster recovery priorities. In particular, IT tends to assume that heavy-duty enterprise applications should be restored first.

In reality, the most needed applications may be much more basic - e-mail and scheduling tools such as Microsoft Outlook, for example. How do you find out? Ask the users. "The business itself needs a plan in case operations are disrupted," says Elbert Lane, a lead software developer at San Francisco-based retailer Gap Inc. and a 20-year veteran of disaster planning at several companies. "They'll need procedures for doing paperwork, etc., so the question is, How would they recover? That's not just an IT issue, but a business [issue]."

The lesson: IT constantly hears the term mission-critical used in reference to CRM and ERP software. But to find out which applications the users really want restored first, simply ask them.

MISTAKE 2: Thinking it's purely an IT issue.

In a crisis, the performance of the IT staff may be the least of a company's worries. "A common assumption is that disaster recovery and business continuity are synonymous," says Don O'Connor, CIO at Southern California Water Co., a utility based in San Dimas. "They're not."

Even underprepared IT organizations have done some thinking about what to do when disaster strikes. But can the same be said of other groups? "In my experience, IT can respond relatively quickly," O'Connor says. "The part that's missing is the users."

The lesson: Company officers need to understand that rebooting systems and recovering data is just one part of the problem. Disaster recovery plans need to include line-of-business managers and end users who, in a crisis, will run the business in the midst of adversity. "Too often, continuity is something we task IT with," Lundstrom says. "It's really a business issue."

MISTAKE 3: Fighting the last war.

If, as the saying goes, generals are always preparing to fight the last war, too many enterprises spend their disaster recovery budgets and energy preparing for the most recent catastrophic event. While understandable, this is self-defeating; disasters are, by their nature, well-nigh impossible to predict.

Recent history offers a compelling example. The Sept. 11, 2001, terrorist attacks on the World Trade Center devastated many New York-based financial services firms. Many wished they'd had nearby backup facilities, and they proceeded to build such facilities at great expense across the river in Jersey City, N.J. But Manhattan's next major business-continuity crisis -- the August 2003 blackout -- took out electricity in Jersey City as well.

The lesson: While it's sensible to consider certain broad crisis categories (terrorist or hacker attacks, earthquakes, fires and so on), don't think you can anticipate future events. Plan not for specific crises, but rather for their effects. The Gap had servers located in the World Trade Center on Sept. 11, Lane says, but "we had set them up to fail-over to backups located in the South."

MISTAKE 4: Overlooking the people.

This is another lesson from Sept. 11: Top-notch backup equipment helps only if somebody is able to use it. "Some businesses had recovery data centers in Lower Manhattan," says Carl Claunch, an analyst at Gartner Inc. However, he says, immediately following the collapse of the World Trade Center towers, "police wouldn't let people in. The equipment was fine, but it just sat there unused." This can happen if a building is quarantined, an elevator stuck or a major road closed.

The other part of this gotcha is the expertise of those who finally do access backup equipment. Too many companies -- especially those that fudge their recovery exercises -- count on IT heroics to pull them out of a crisis. However, as the Gap's Lane says, "you never know if key personnel will be back."

The lesson: This is where strong documentation comes in. "We fashion our document so anyone in the business should be able to restart an application," Lane says. "You should be able to have somebody from the mail room start everything up."

MISTAKE 5: Conducting phony-baloney practice drills.

"Sure, companies do testing. But because full tests are so resource-intensive, they're scheduled in advance," Claunch says. The result: IT workers, driven by the natural desire to ace a test, cheat. "They prepare. They collect tools, review procedures," he says. "Then, when a real disaster hits, blooey."

This is a sticky problem for IT organizations stretched thin even before disaster planning is factored into their workloads. Lane says practices at the Gap are planned in advance. "We are a retailer; we need to support our stores" around the clock, he says.

The lesson: There is no easy answer here. Everybody concedes that surprise disaster tests are more effective, but performing one in a round-the-clock, e-business environment is a massive undertaking. Claunch suggests surprise tests of one IT subgroup at a time, leaving the rest of the staff to run operations. And some businesses use auditors to make sure IT workers don't lean on prepared information.

Ulfelder is a Computerworld contributing writer in Southboro, Mass. Contact him at sulfelder@charter.net.

Preparing For The Worst

Stories in this report:

Disaster Recovery

It’s time to break the ChatGPT habit