Year 2000 contingency planning is growing in size and intensity on the IT industry’s radar screen as we approach the end of 1998. Experts agree that contingency planning is an essential corollary to Y2K remediation efforts.
Surveys and statistics abound to justify this view to both jaded and concerned observers alike. Consider these facts: according to the Standish Group, only 27% of software projects are delivered on time, on budget. Another 33% are eventually completed, but they are late, over-budget or have scaled-down features. The remaining 40% are projects that fail utterly, where the system never goes on-line or is totally unusable.
Until now, most software testing done as part of routine maintenance and enhancement touched perhaps 20% of all code, but Year 2000 testing will need to evaluate 80% or more. The IT industry has never faced so many concurrent projects with immovable deadlines on such a massive, global scale. Its track record to date is not encouraging, and contingency planning is clearly a prudent measure to ensure business survival.
SUBHEAD: RISKS BEYOND YOUR CONTROL
Y2K issues are complicated by the fact that IT project risks are only one component of the much broader business risks posed by the Y2K problem. The complex web of interdependencies between enterprises, business infrastructure and political entities will threaten even organizations that have their own Y2K project risks well under control. Potential Y2K failures by suppliers, customers, telecommunications, utilities, banks and government may also result in an organization’s demise. Many of these risks are beyond an organization’s immediate control.
In the 1998 Cutter Consortium Summit, prominent Y2K expert Ed Yourdon marshaled an army of facts to underscore the need for concern for these external forces. Of the 9,000 electric utilities in the US, none are Y2K compliant today. Major telecommunications vendors are working hard on the problem, but are faced with massive software inventories of 300 to 500 million lines of code. For North American banks, the ripple effects from international banks in Asia, Latin America and Europe, which are far behind in their Y2K efforts, could pose a serious risk. The recent congressional scorecard rated the US government’s efforts a “D”. And in Canada, there are many who are skeptical as to the Y2K preparedness of government departments at all levels. The global list of Y2K-unready organizations in business and government is very, very long.
Although Y2K contingency planning is growing in importance, the statistics are grim. Nearly half of 250 IT executives surveyed in an August 1998 Information Week poll said their companies haven’t even started developing Y2K contingency plans; only one in four said they’ve completed such plans. These statistics are alarming considering optimists and pessimists alike both agree that much of the world’s technology will experience some level of failure. The Information Technology Association of America (ITAA) recently reported that 44% of surveyed organizations had already experienced a Y2K-related failure, and 67% had experienced failures under test conditions. Early identification of risk areas and strong contingency planning can mitigate two key Y2K risk factors: the severity of impairment and the duration. For example, an organization that has a failure in a software application may be able to process transactions manually via a contingency plan. Organizations that wait until the software fails are unlikely to respond quickly enough to recover their business operations and will therefore lose market share and confidence. Conversely, organizations that have a viable contingency plan in place (viable being the operative word here) increase their chances of early recovery.
Joe Boivin, president of the Global Millennium Foundation based in Ottawa, says: “The fundamental assumptions that form the basis of the contingency plan must be carefully examined. If the assumptions are modest, then the plan may be useless. For example, if a blackout occurs that exceeds the planned threshold, then you’re toast.” Organizations are advised to plan for the worst, and hope for the best. “No matter what an organization does, it will probably experience more problems than anticipated”, Boivin adds.
OVERCOMING RESISTANCE
Contingency planning requires a shift in focus from the data centre and the IT department to the wider sphere of business risk assessment, an area typically beyond the CIO’s span of control. There are strong links between Y2K remediation efforts and contingency planning, as the red flags raised in Y2K project monitoring trigger the alarm for alternative solutions.
Tim Morton, a vice president at Electronic Data Systems Corporation, says there are barriers against contingency planning. “It is, in many cases, a politically incorrect term because it implies incompetence,” he says. “The plans are not well received in many circles because you’re suggesting doubt.” IT executives need to take a lead role in orienting senior management towards the business risks of Y2K and broadening the narrow IT focus.
The IT area has skills and knowledge that need to be applied to Y2K business risks: a rigorous, structured approach for project management, and in-depth knowledge of the Y2K problem. IT project risk management is often confused with business risk management because of the similarities in project management approach, but business risk encompasses elements well beyond technology risk.
The business risk of Y2K failures caused the SEC to issue formal regulatory requirements in 1998 compelling organizations to address their risks and disclose their Y2K status. Senior company officials can be held liable for Y2K disasters, and ignorance will not be a plausible defense. They will need to show that they personally acted as leaders in a business crisis: that they sanctioned the full, needed investment for the technical work, performed an in-depth risk assessment (economic, safety, organizational, supply chain, contract performance, etc.) and developed a contingency plan to handle any crises created by Y2K failures. Arguments that their firms cannot be held liable for failing to meet contracted deliveries of parts because their European or Japanese trading partners’ systems crashed will probably not wash, as the lawyers will ask, “Did you show due diligence in risk assessment, contingency planning, monitoring and investment?”
FIVE-STEP RISK ASSESSMENT
Risk assessment is the well-spring from which the contingency planning will flow, which in turn must work in concert with Y2K remediation efforts. Part of risk assessment is posing the question: can you afford not to do this? The fundamentals of assessing and managing risk can be summarized in five steps:
- Identify the risks. Typical categories of risk are schedule, financial, technology, resource, business, and communications.Evaluate the risks. A risk-ranking scheme based on how likely it is that the risk will materialize and how much is at stake is necessary.Plan your response. The response to identified risk needs to be tailored for each organization.Monitor the risks. Throughout the project, the biggest identified risks need to be revisited as an integral part of the process.Document the status, and revise it on each iterative pass.
A comprehensive business risk assessment, which identifies critical business functions, their supporting processes and the potential impact of Y2K risks will enable an organization to focus its contingency planning efforts on priority areas. There simply isn’t enough time to develop and test contingencies for all business functions. First priority must be given to those functions that are absolutely necessary to sustain the business and that have the highest risk exposure.
The contingency plan needs to be a dynamic, interactive process working in concert with Y2K remediation efforts. Planning efforts must involve those who are accountable for mission-critical business functions and supporting processes as well as those who are knowledgeable about the business from a hands-on perspective. Triage decisions made about non-critical systems and slippages in remediation, which are still underway and incomplete, will require an appropriate response in the contingency planning efforts. The Y2K program manager should establish whether it is possible to circumvent an application, perhaps by using a manual process or redesigning the business process. For example, Kevin Schick of the Gartner Group suggests that a contingency option for the troubled IRS might involve converting current tax codes to a flat tax, on the premise that IT could implement a fairly simple system to process a single tax rate in a relatively short time-frame. Alternatively, re-examination of core business priorities should be performed. Joe Boivin says,” If you are a multi-national organization, and there are components of your business that depend on elements beyond your control (for example, bank branches in other countries), then you should consider abandoning them if there is insufficient profit motive to expend resources.”
INTERNAL AND EXTERNAL RISK
Mission-critical applications that cannot be circumvented will receive higher priority than applications for which it is possible to devise a workaround. This is a key factor in determining the relative priority of competing projects. Once work projects have been identified and prioritized, the Y2K program manager must consider two risk categories that require contingency planning. The first risk category – internal – relates to risk that can be directly managed within the control scope of the Y2K program office and the individual business units. The second risk category – external – relates to risks that are beyond the control of the Y2K program, such as the possible failure of key suppliers and customers, utilities, government, etc.
Executives may well plead, “How can I organize for contingency planning when the state of my own firm’s Y2K remediation efforts, and so many other key players, is in still in flux?” The answer is simple: you don’t have a choice, and the time to start is now.
Every organization needs to evaluate its business, and position the start time to maximize results, but Y2K experts agree it cannot be put off beyond the first quarter of 1999. Senior management should organize a contingency planning program that is separate from, but works with, the Y2K program. Business units, which should already be involved in Y2K remediation efforts, are best-placed to evaluate the business risks within their areas that require contingency planning. Facilitated workshops are the best approach for organizing teams to identify risks and failure points within their business processes that will require contingency planning.
Risks identified within business units need to flow upwards to the contingency planning manager, then to the Y2K program office, and from there to the steering committee in order to develop a strategy and a mitigating action plan, and to identify the triggers that will invoke the contingency plan.
Different strategies will be required for dealing with internal and external risks. External risks for inputs (e.g. key suppliers) will require an assessment to determine Y2K readiness and the key trigger dates that should invoke a firm’s own contingency plan; a similar assessment will be needed for outputs (e.g. key customers). A separate contingency strategy may be needed for infrastructure elements, such as utilities, telecommunications, public health services, and the like. The Y2K remediation status needs to be monitored on a regular basis and integrated with the contingency plan to ensure all bases are covered.
The examination of all fundamental assumptions is of paramount importance in contingency planning. “One overlooked assumption I’ve observed repeatedly in my workshops is: Where will your people be on Jan 1 to 3, 2000?” says Joe Boivin. “Who will fix your problems if your employees aren’t there? The Toronto Police, the Canadian Navy, the RCMP and the Coast Guard have already cancelled vacations in that time period to ensure a full complement of staff.” Existing business contingency plans should be re-visited to ensure that they will hold up under Y2K business failure scenarios. Moreover, it is critical that Y2K contingency plans be tested to ensure they work. “You can’t put the plan together and expect it to work when you need it.” Boivin notes. “There has to be a dress rehearsal. Every organization that has tested its plan has found holes.”
Many contingency plans assume backup sites will be unaffected, or that resources will be available for redeployement. But the Y2K problem is without historical precedent: unlike previous failures, you won’t be able call your neighbour for help. Every organization faces the difficult decision of predicting the impact of Y2K failures on both their organizations and the world at large in order to plan effectively for the coming crisis.