Strategies for Y2K Contingency Planning.

Businesses have concentrated on Year 2000 issues to varying degrees. Many began the process early and over time concluded that their Year 2000 projects have been managed successfully, while others remain concerned that various critical systems may not be compliant. After all the time and money organizations have spent to fix or replace non-compliant systems, many senior managers can be forgiven for asking, "Why do I need Y2K contingency plans?"

Consider some of the issues that leave the organization open to multiple and significant business failures. The points below illustrate some of the potential Y2K failures and disruptions that may occur despite the best efforts of an organization to be prepared. While it is certainly impossible to anticipate every potential failure or disruption, an organization that has given thought and planning to risks in key areas will be better prepared to handle any contingency than an organization that simply waits to deal with failures when they occur.

Incomplete Functionality Testing

Any untested functionality is a significant business threat, particularly within a global organization due to system complexity and extended business support. Examples may include automated packaging and shipping facilities, building security systems, or billing systems.

Incorrect Code Repair

Automated or manual processes require considerable effort to ensure issue identification, particularly with less obvious issues. Automated efforts demand significant external support and manual efforts are tedious and require visual program code review. In either case, the business is exposed if testing is incomplete and unremediated.

Indequate Change Control/Change Management And Deficient IT/IS Inventories

IT/IS assets often change to support the business environment, which introduces possible Year 2000 error conditions if forgotten or overlooked in the repair effort.

Incomplete Infrastructure Compliance

While business applications may be Year 2000 compliant, the process may have overlooked infrastructure verification and compliance. Business applications may be inaccessible if infrastructure components such as electricity, water, telephone, or buildings are not Year 2000 compliant.

Non-Compliant Proprietary Software, Hardware, Or Embedded Systems 

Utility or connective third party IT/IS assets (software or hardware) are essential for distributive applications to operate. Businesses may be unable to perform mission critical functions if Year 2000 compliance remains unverified.

Non-Compliant Key Suppliers

Key suppliers supporting the core business elements or product delivery to customers present risk if they are not Year 2000 compliant.

Non-Compliant Customers

Customers that are not Year 2000 compliant may not be able to accept product delivery, affecting cash flow, inventory, expenses, and profitability.

Why Contingency Planning?

Contingency planning manages the business risks associated with Year 2000 from both a business function and related systems failure perspective. While there are options that organizations consider as viable alternatives to contingency planning, they do not provide the foundation for an organization to manage business operations on an ongoing basis given a failure occurrence. A solid contingency plan may, in fact, include other approaches as ways to further protect the organization, but by themselves these alternatives are insufficient to adequately protect the business enterprise and operations.

In the absence of contingency plans, some of the largest threats to continued profitability or corporate existence would arise from any number of areas. Customers, a company's greatest asset, could quickly seek alternatives to satisfy their own needs, resulting in a temporary or permanent loss of business and market share. Likewise, new business opportunities could be lost due to an inability to attract new customers because of Y2K disruptions.

Cash flow reductions due to customer losses and/or the inability to accept or pay for goods and services may also cripple a business. Vendor support for restocking supplies, equipment, and product also becomes problematic when the bills are not being paid. An organization's reputation can thus become tarnished, resulting in a loss of financial community confidence that can cause restrictions or increased costs in acquiring capital.

Disaster recovery contractors and other vendors will not necessarily assume responsibility for Year 2000 compliance of parallel or complementary systems. The Year 2000 is being viewed as a foreseen event and not as an unexpected potential disaster. Some organizations believe that there are viable alternatives to contingency planning, particularly as a solution to Year 2000 compliance. These approaches can leave significant issues unattended that senior management should be aware of and consider in decision-making.

While compliance efforts will continue well into the new millennium, companies must face the reality that things will be missed and mission critical systems and suppliers will fail. An adequate contingency plan will likely mitigate failures since issues are discovered and operable plans are implemented to prevent or overcome business disruptions. And Year 2000 contingency plans are documents that will serve as the foundation for enterprise-wide contingency plans.

For instance, company leaders should be asking them-selves what happens when a mission-critical component is unavailable to support the business (e.g., staff, technology assets, embedded chip systems, utilities, security systems, key suppliers, etc.). What is the impact of these failures to the business? How prepared is the organization to respond to component failures that support mission-critical activities? What can be done to prevent or mitigate these disruptions?

At the planning level, the questions will include:

* Who has to be involved in the restoration of the failed business component?

* Who has to be informed of the problem when the lack of business functionality affects individuals or organizations outside of the company?

* What steps and processes must occur to maintain business as usual in the event of a failure?

* Is the failed component repaired, replaced, worked around, abandoned, etc.?

* What and where are the resources to make the business component operational?

Considering the questions just raised, businesses must prepare for system failures and the possibility that key suppliers will be unable to provide services and materials. The greatest uncertainty is when and what will fail. Contingency planning is the primary process by which the effect of a failure is minimized to allow business to be conducted as usual. Contingency planning is not just an IT/IS requirement, but an issue that will serve as the foundation for the entire enterprise.

15 "Real World" Examples

Millennia III has been providing end-to-end Y2K solutions for more than 50 major corporate clients since 1996. For the most part, these Y2K programs are in the final stages of repair and testing, as well as assessing risks from suppliers, vendors, and customers. While we and our clients are confident that they have minimized the vast majority of Y2K business risks, we are still advising and most of our clients are accepting our recommendations to create specific contingency plans.

Below are some examples of various Year 2000 contingency plans already adopted by businesses in the United States, the United Kingdom and Europe.

1. An additional payroll will be issued in December 1999 for distribution in January 2000 in case of system problems.

2. Alternate suppliers are being identified in the event a primary vendor is unable to deliver.

3. Printed copies are being ordered prior to Dec. 31 for critical year documentation and reports (e.g., P&L, General Ledger, Position Statements, and Customer Portfolio).

4. IT departments are setting up 24-hour help desk functions to field calls prior to and after year-end.

5. Some companies are creating "SWAT" Recovery Teams to react quickly and repair Y2K problems.

6. No vacations are being allowed for employees critical to the Y2K effort during the last two weeks of December and first two weeks of January.

7. Hotel rooms have been reserved near the office for key personnel.

8. Manufacturing companies are planning (and in some cases have begun) to stockpile inventory materials.

9. Year-end reporting will be changed from Dec. 31, 1999 to Nov. 30, 1999.

10. Certain tax filings will either be completed early or late (a small fine may be incurred in some cases for late reporting).

11. In some cases, commission payments will be postponed and forecasting and expense distribution systems will be brought forward.

12. Some insurers are depositing twice the value of known payment liabilities for January 2000 in banks other than those in which such reserves are normally retained.

13. Organizations are programming mobile phones to select between at least three networks. Staff is classified into geographic "clusters," which have between them mobile phones connected to each of the selected networks. The "clusters" have a temporary base local to their homes with basic equipment to support critical functions.

14. Where spreadsheet applications are run on client-server networks, alternative PC spreadsheet software is being installed on a number of dedicated, standalone PCs with crucial data downloaded to the PCs in a common format prior to Dec. 31, 1999. This will enable some, albeit skeletal, activity should the network experience failures. For network word processing software, templates are being created on stand-alone PCs as necessary and using common formats such as .txt as the intermediary.

15. Many companies are contracting with temporary personnel agencies and security agencies for additional support staff. Other plans call for training of staff from non-essential areas within organizations to support Y2K emergency efforts.

It's becoming conventional wisdom that Y2K, at least in the U.S., will not be the cataclysmic event that some have feared, but is more likely to result in a series of disruptions, the scale of which is anyone's guess. That's why it is imperative to put contingency plans in place now, even as you test the thousands of systems and millions of lines of code you may have repaired over the course of your Year 2000 project.

Experts concur that for every 100,000 lines of application code that are repaired, 1,000 defects will be introduced. Testing will find many, but not all; moreover, test results are only as good as the script devised for the test. Even with the highest level of confidence in your own Y2K compliance, you are still vulnerable to failures that could not have been foreseen.

Patrick Riley is the senior vice president of marketing at Millennia III (Westport, CT).