System Transformation
The Knowledge Center for Information Management

Home Page

Knowledge Center Topics:
[ Transformation Articles ] [ Transformation Methodology ] [ Contingency Planning ] [ Transformation Solutions ]

Topic: Contingency Planning -- Articles

Contingency Planning for the Year 2000

By William Ulrich

In September of 1998, the Securities and Exchange Commission (SEC) mandated the disclosure of contingency plans in the 10Q and 10K filings of publicly held companies. This mandate drove many executives to launch contingency planning initiatives in the latter half of 1998. Now 1999 is upon us, year 2000 failures are occurring at an increasing rate and contingency invocation is just on the horizon. Unfortunately, many organizations do not have contingency plans in place. The planning process has been slowed by limited business unit participation, a focus on preventative versus future planning, inadequate funding and a myopic view of the world that considers only one side or another of a year 2000 failure. Companies that have fallen prey to these pitfalls must quickly recoup.

A year 2000 contingency plan is a well thought out, alternate course of action that avoids disruptions in business operations due to a date related computer error. Contingency planning is not adding more staff to a project, mandating success or increasing budgets. Every mission critical business function system, data interface and supplier needs a contingency plan. The remainder of this article outlines contingency pitfalls and introduces a process that companies can use to create contingency plans that ensure an organization’s long-term viability.

Barriers to Contingency Planning

The following pitfalls have resulted in ill-timed responses to narrowly defined problems, unusable piles of paper and the inability to successfully launch a contingency planning program.

Limited business unit participation: One of the most difficult tasks in launching a contingency planning initiative is getting the attention of business people that believe the year 2000 should by handled by technical people. The incentive that management should assume that when they arrive at work on January 3, 2000 that they would have no access to systems personnel or to suppliers to help fix year 2000 problems. With this thought as a backdrop, business analysts can begin to craft a series of backup plans for critical business function under their domain.

Overemphasis on preventative versus future planning: Preventative planning is a good idea, but is not the name of the game when the year 2000 arrives. Companies must have a finely honed, integrated strategy to maintain a functioning business environment when failures do occur. This means that management will be able to react to functional, system or supply chain failures so that those failures do not result in large-scale losses or the inability to function as a business entity.

Inadequate funding: Most organizations set aside limited funds for contingency planning in 1998 and, if they were reasonably prepared, set aside additional funds for 1999. This means that middle managers and direct reports to the CFO and CIO will be cutting corners at a time when they can least afford it. Contingency planning and invocation funding must be set aside now and reflect contingency requirements into and beyond the year 2000.

Considering narrowly defined year 2000 failure impacts: Some organizations are building tactical plans to fend off a system failure here or a corrupt data input there. Other companies are focusing solely on business continuity to develop options for a business unit in crisis. The biggest risk is that piecemeal planning, being performed by segregated teams, does not fully reflect the breadth of contingencies that must be deployed from across an organization. Management can only deliver integrated contingency plans by linking tactical failures to strategic impacts and visa versa via a central contingency management team and planning repository.

Contingency Planning Defined

The goal of contingency planning is to mitigate business risks due to a mission critical functional failure caused, directly or indirectly, by non-compliant hardware or software, vendor, package, embedded device, supplier or external interface or environment. With little time left, companies must quickly solidify backup strategies for business units and technical teams.

Management is discovering, however, that contingency planning is not necessarily intuitive. One financial institution described the process as a "tail chasing" exercise because they could not determine where various aspects of the plan began or ended. It is important, therefore, to understand how your organization can build contingency plans that are both comprehensive enough to deal with impending issues, yet practical enough to be clearly articulate and applied.

Contingency planning addresses all aspects of a given year 2000 failure across an enterprise. These failures may include technology failures, power outages and the inability of customers to acquire products or services. Planning teams must accommodate the upward, downward or lateral ripple effect of any failure that of a critical business function, regardless of that failure originates.

Contingency planning is a non-linear process that cannot be performed by a single task force or business or business unit. The planning process must rather be approached as a centrally coordinated, yet highly distributed series of facilitation exercises. In order for management to successfully initiate a contingency planning project, they must incorporate two key sets of deliverables; the bottom-up, tactical portion of the plan and the top-down, business-driven component of the plan.

The bottom-up process assesses tactical impacts of a system problem, project overrun, data interface error or supply chain interruption. Project teams may already by building bottom-up contingency plans to deal with localized year 2000 failures. But bottom-up planning does not consider business-driven priorities, revenue continuity, enterprise-wide impacts or the ripple effect of a system or supply chain failure. This is where top-down planning comes into play.

Top-down contingency planning deals with failures in mission critical functions and the ability of business units to work around or contend with those failures to ensure business continuity. This process, which readies businesses for potential interruptions in ongoing operations, should be deployed across various business units, infrastructure (telecommunications, power, facilities, etc.) teams and executive committees.

Integrating bottom-up and top-down contingency plans completes the planning exercise. Integrating bottom-up plans and dependencies with top-down, business-driven contingencies allows an enterprise to ensure that the most critical organizational components have contingency plans and to verify that a bottom-up plan does not conflict with a top-down strategy. This approach also considers the ripple effect of a failure based on the bottom line impacts that a year 2000 problem has on the business.

Essential Elements of a Contingency Plan

The essential elements of a contingency plan include determining functional criticality, planned mitigation strategies, failure scenarios, failure probabilities, contingency losses, contingency options, contingency costs and trigger dates. Each of these planning elements should be included for each contingency that is linked to a mission critical function, system, supplier or data interface within an enterprise.

Criticality analysis involves ranking the importance of a function, system, supplier or interface on a one-to-five scaling (with 5 being most critical) and building contingencies for high priority items. Current mitigating action should be considered as a way of determining the likelihood of a failure. In other words, if the current plans to marginally test a system, the odds of a problem are likely to be high. Failure identification requires that business unit and technical subject matter experts perform "what if" analysis on key functions, suppliers and technologies in their areas. There can be one or more failure scenarios assigned to a given business function, supplier or technology and each one of these scenarios may require a contingency plan.

Once a failure scenario has been identified, analysts can assess the likelihood or probability of a failure using a one-to-five scaling (with 5 being high) strategy. Once these factors have been assigned, analysts can multiply contingency failure probabilities by a functional system or supplier criticality factor as a way to prioritize contingencies. Contingency loss analysis determined how much a failure would ultimately cost an organization. Not all losses can be translated into a cost figure, but most failures have a monetary impact. Analysts can then calculate the cost of the contingency plan and compare it to the projected contingency loss as a way to weed out plans that are not cost justifiable.

The contingency plan itself outlines how a business or technical unit can mitigate the impact of a failure. Analysts must also assign a projected trigger date to each contingency to signify when they anticipate invoking the plan. Pre-2000 contingencies, which could include stockpiling parts or shutting down a plant, may have specific dates assigned to them. Post-1999 plans, on the other hand, are typically invoked when a problem becomes apparent. As plans are invoked, contingency coordinators, using a relational tracking database that contains the totality of all contingency plans, can record the invocation of a plan and share this data with other area within the enterprise.

The importance of beginning contingency planning now is critical because certain plans may need to be invoked before the year 2000 arrives. If you are just starting out, focus on mission critical systems, suppliers and business units as a top priority. There is no time to waste, but be judicious and avoid sidestepping essential planning requirements.

Send mail to webmaster@systemtransformation.com with questions or comments about this web site.
Copyright © 1999, 2000 Tactical Strategy Group, Inc.
Last modified: March 8, 2000