The Real Niel

Disaster recovery and business continuity planning: Know the risks

Today, I want to talk with you about product management best practices and how they apply to disaster recovery and business continuity (DR/BC) plans. I can appreciate your skepticism

    Requires Free Membership to View

because the connection is not directly obvious. However, if you will bear with me for a few more paragraphs, I am confident this approach will begin to make sense.

The Real Niel
Niel Nickolaisen

In my voluminous spare time, I am responsible for implementing process improvements across all of our business functions (manufacturing, engineering, finance and IT, among others). As I teach our employees the principles of process improvement, one of the foundation principles I attempt to explain is that not all products, customers and processes are created equal. Quality product management is based on inequality among products. For example, the product line at one of our businesses includes more than 2,000 distinct products. Of these 2,000 products, only 10% (the A products) account for 80% of the sales revenue. When looking at ways to improve marketing, sales, production planning and distribution, we treat this 10% differently from how we treat the other 90% of the products. We make sure that we never run out of these products because they are in high demand. We make sure that these products have priority in our catalogs and sales presentations.

Of the rest of the 2,000 products, 30% account for the next 15% of sales. These are the B products. We need them, but if we have some hiccups in their sales, marketing or production, it does not hurt us too badly. The other 50% of the products account for the bottom 5% of sales. We treat these C products as custom-order items. We quote longer lead times when a customer orders a C product because we don't want to build C products, put them in our warehouses and pray that someone orders them.

I have found that by applying this same A, B, C stratification to our IT systems, we make better DR/BC plans and decisions. (See, I told you there would be a connection between product management and DR/BC!)

The A systems are those that can be down for only a short period of time before the business is at risk. The A systems are our real-time systems. The B systems are those that can be down for a longer period -- anywhere from hours to days -- before the business is at risk. The C systems are those that can be down for a long time before anyone outside IT even notices.

Once we have categorized our systems into the appropriate A, B or C status, we match our disaster recovery and business continuity plans to the system status. For example, our DR/BC efforts focus on protecting and recovering the A systems. Only our A systems qualify for hot or warm backup sites. We invest in redundancy of A systems. We look for and eliminate single points of failure in our A, and possibly B, systems but tolerate them for our C systems.

We factor our A, B, C categories into our help desk and response decisions. If an A or B system goes down, we immediately reallocate our resources, even those assigned to priority projects, to get the A and B systems back up. Not so for C systems -- they can wait until we have finished our priority projects.

As you might expect, segregating systems into A, B and C categories is not a process IT does by itself. This classification requires collaboration with our business customers. I typically approach system stratification as part of DR/BC planning. Together with a risk management committee, we define the criteria we will use to identify the A, B and C systems. With the criteria in place, we complete our sort. After we have completed the initial stratification, we schedule regular reviews to make sure we capture any changes, particularly A systems that have moved to B or C status.

I have found that taking this product management approach is the best way for me to focus IT's DR/BC efforts where they belong -- on the systems that matter most.

Niel Nickolaisen is CIO at Western Governors University in Salt Lake City. He is a frequent speaker, presenter and writer on IT's dual role enabling strategy and delivering operational excellence. Write to him at

This was first published in September 2008

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.