Business Continuity: Inadequate Planning Affects CIOs

Excellent article and comments. Think Janet Ahlgren hit the target when she points out that COOP involves everyone involved in the operations of an enterprise. I suggest two final steps -- based on what smart military commanders have done throughout history to prepare for war (and any exec whose enterprise has been engulfed in a major disaster has "been to war"). Three quotes come to mind: (1) "No plan survives first contact with the enemy";(2) "The race does not always go to the swiftest nor the contest to the strongest - but that is the best way to bet"; and "If you ain't at war -- you'd better be practicing for it." Smart COs subject their teams to regular structured practice covering stuff that can go wrong and subject themselves and their team to randomly scheduled no-notice drills with objective "hot washup" assessments. Nearly every enterprise -- large or small should embrace this approach. A growing number of large and/or complex enterprises executives are investing in operational models of their business process -- that can readily be used to drill and test COOP. I suggest we move from COOP to COPE [Continuity of Operations Planning & Exercise]BZ to those that do.

Partnerships are essential. We would also suggest that looking at disruption and resumption as being somehow distinct from each other reflects bureaucratic thinking, not reality. Some government agencies and private sector companies already take an integrated approach. The State of Missouri, for example, has adopted a single system for planning, training, responding and recovering from natural and manmade disasters. It takes as given that different agencies and law enforcement organizations will have different systems and processes. To avoid the IT strategy obstacles Newcomb cites, Missouri now uses technology from IBM and VirtualAgility that overlays existing systems to enable everyone from Homeland Security to the local police to interoperate before, during and after a disruption, without sacrificing control of anything proprietary. It's a git' er done philosophy that's allowed Missouri to bypass bottlenecks that still prevent other public and private entities from developing practical COOP solutions. James O. Price, Jr. points out in his comment: A good BC/DR program touches the entire organization. With respect, we would add that a truly worthy program also touches all the different organizations that will respond to the disruption and take part in the recovery. Now that it's technically possible to address the entire crisis management cycle with one complete solution, why would anyone settle for anything less?

I agree whole-heartedly with Bill Lang's comments. I want to add, however, that CIOs need to understand what the BC professional needs to successfully perform his/her function, particularly in a large organization. BC/DR too often is the "ugly stepchild" in many organizations. Unfortunately, the end does not turn out like the stories of Cinderella and the Ugly Duckling. Too often, planners and coordinators are hired to satisfy an audit or regulatory requirement and not given the funding, staff or budget needed to establish a comprehensive BC/DR program. Time between events and the changing economic climate hit BC planners/professionals hard as, in the eyes of CIOs, it becomes less and less of a priority as opposed to initiatives that "keep the lights on" and generate revenue. BC professionals are often buried deep in the organization and do not have the opportunity to plead their case to the true decision makers. Typically, the position is made a part of an IT organization, thus adding fuel to the misconception that BC/DR planning is solely an IT function. While BC/DR should work with IT Security, it should not be a part of that organization. Ideally, it should have its own funding, reporting structure and staff and should occupy a significant slot on the organization chart. A good BC/DR program touches the entire organization - not just IT and should be treated/funded/supported accordingly.

CIOs need to leave BC to the professionals since this article makes it very clear that the whole BC picture is rather cloudy on the realities of business survival. IT security is a very narrowly focused effort to secure data so that data is not lost or stolen. There is very little actual Emergency Management, IT Disaster Recovery, or BC training in the data security field. The reason IT security is a separate field is because the "netting" that is data processing security has an almost insurmountable number of holes. The immediate and almost overwhelming need to secure data calls for many man hours of concentration to plug the holes in the netting and has created a cottage industry in data security. Once we ingrain a higher level of data security in our data processing systems, that data security industry will begin to dry up or morph into other areas. The analogy is that a Katrina of data integrity loss has burst the data security levees flooding the IT world with immediate need to survive the rising waters, and Information Security has been called in to sandbag the levees while the data processing core of software engineers rebuild the data processing levees with more integrity. BC is just one area of business survival and it addresses less immediate needs than the torrent of data security problems. This is why BC is slow to be addressed. When the data security breach waters are lapping at your nostrils, it's hard to think about less pressing BC stuff. Novice BC presentations and checklists talk about critical data and critical processes, while professional BC talks about the criticality of the data and processes. Any BC professional that simply says, identify your critical processes and your critical data doesn't really know what they're doing. BC Management (BCM) is really all about recovery time objectives and recovery point objectives and how to meet those objectives with interim business processes and appropriate forms of IT redundancy and IT DR as well as some Emergency Response. Simplistically, BCM addresses people, processes, and technology. But if the only part of "people" is where they are going to sit, you would have an incomplete plan. If you only addressed how "processes" would be done without IT, you would have an incomplete plan. If you only addressed how your "technology" would be recovered, you would have an incomplete plan. This is why it is better to leave BCM to the professionally trained BCM people.