A 2015 Evolve IP survey reports 56 percent of companies don’t feel prepared to recover from a business disaster. And 75 percent get a failing grade for disaster recovery, including those with existing DR plans. It’s clear that even the companies with detailed DR plans have trouble executing such projects.
It’s no wonder executives think developing disaster recover plans (DRP) is expensive and somewhat futile. Why spend all that time and money creating a plan that won’t restore operations when you need it to?
But DR projects can produce spectacular results. Here are five attitudes that cause DR projects to fail.
#1 “You’ve got our full support”
Another survey shows that 43 percent of IT executives plan to invest in new or improved DRP projects. But while the CIO and his direct reports understand the importance of DR, does the rest of the company?
Often executives don’t understand the full business danger an IT disaster represents –informational and financial. And if they do understand the revenue impacts, they still need to wrap their heads around the cost of prevention and recovery. DR projects need realistic budgets – money, time and people – to create a workable DR plans and keep them up-to-date.
#2 “We just need something documented”
Is your DRP project just to satisfy the board that you “have one”? Or is it to gain or keep some key customers? After all, if your business has a failure, their businesses will also suffer.
Many companies view the effort as just another “documentation exercise” to justify customers’ trust. But if the result is nothing more than a document, chances are slim the plan will ever work when it’s needed. A watered-down result protect neither the company nor its customers.
#3 “Let’s just worry about the main apps”
Which brings us to inadequate scope. Even proficient IT groups aren’t always familiar with planning for disaster recovery. They know about the individual databases and applications, so that’s where the focus tends to stay. They aren’t always keen on recovering beyond those silos, much less planning to handle a site-wide disaster.
Focusing on just highly visible apps results in a narrow project scope that doesn’t reflect your business operations as a whole. This also shortchanges the discovery phase (where all the dependencies are found) and the end-to-end testing phase. Without these, you might recover the “big apps,” but they might be unusable without the supporting infrastructure.
#4 “It’s just a matter of backing up the data”
As mentioned before, disaster recovery is more than keeping a set of data backups (and hoping you won’t need them). And it’s more than restoring a database or two. It’s also identifying your outage tolerance and recovery priorities in the event of a disaster.
Do you need to resume normal operations within a day, a few hours, or mere minutes? If minutes, you’ll need business continuity plans to take over full operations while your primary infrastructure is restored. If your plan documents only data backup and recover, how will operations continue normally while individual systems are recovered?
#5 “Our plan is complete”
That statement is never true. If you put your DRP on the shelf until you need it, it’s almost certain to fail. Business conditions change. Hardware changes, applications are added or replaced – or moved to the cloud… With such continuous change, a static DRP will be defunct when you need it most.
At the very least, annual disaster recovery tests should uncover infrastructure changes. After addressing and documenting the changes, the plan has to be retested. Otherwise, it will be as stale as a five-year-old desktop – and almost as worthless.
Give your DR plan the right attitude
If you don’t have a DR plan in place, or if it’s been a while since you tested it, your company’s operations are at risk. If you’ve got a dedicated DR team, get them moving again. If you don’t, consider a cloud-based Recovery-as-a-Service (RaaS) solution to make creating a plan simpler.
Either way, consulting RaaS experts can help you stay up-and-running when disaster strikes.
When did you last test your disaster recovery plan? How “out of date” was it? Tell us about your experiences in the Comments section.