System
|
Topic: Contingency Planning -- ArticlesContingency Planning: When Time Runs OutBy Ian Hayes & William Ulrich What happens to an organization if mission critical systems are not century date compliant in time for the new millennium? Could the loss of an order entry system, a production assembly system, a trading system, a claims system, a patient admitting system or a key supplier bring a company to its knees? As organizations around the world struggle to meet the impending Year 2000 deadline, business executives must search for answers to this increasingly realistic possibility. If management does not plan for contingencies in various functional and technical environments, the survival of the company, or even a given industry, could be at stake. This article addresses contingency planning strategies for the Year 2000. There is no magic answer to the contingency planning process – it requires thoughtfulness, coordination, foresight and hard work. Contingency planning, by definition, establishes alternative Year 2000 resolution options when an initial action plan fails or falls short of its goal. Contingency planning requires that management be ready to take action when things do not go as originally planned, when unforeseen problems arise or when original delivery timeframes are exceeded. If everything always went the way we originally planned, there would be no need to consider alternatives. But Murphy’s Law states that "what can go wrong, will go wrong". Even if all goes according to plan, unforeseen problems or bugs will arise during the late 1999 and early 2000 transition window. Exceeding project deadlines is another area where IT has typically been left with no fallback position - an unacceptable option in a Year 2000 project. Why Plan For ContingenciesThere is unjustified sense of optimism surrounding the Year 2000 problem. A 1997 International Data Corporation (IDC) study found that only 2.8 percent of CIOs surveyed believe that they will miss their Year 2000 deadline. Furthermore, the survey found that 73 percent of Chief Executive Officers and 71 percent of Chief Financial Officers claimed that they have a strategy in place to address the problem. This response is not unexpected given that these individuals are responsible for the financial success of publicly traded companies. Misplaced optimism spawns complacency and complacency, coupled with the overwhelming challenge ahead, dictates that contingency planning will become an increasingly critical requirement for businesses over the next year and a half. Contingency plans should be generated as a fallback position for key business functions. Organizations will not have time to create a plan for every last item in an enterprise, which means that building of contingency plans must be prioritized in the same manner as remediation projects and test plans. A full blown business risk assessment provides the key to this prioritization process and is a basic prerequisite for the development of a contingency plan. Plan for contingencies only in situations that involve key business functions. Planning OverviewBuilding a contingency plan is a distributed process performed jointly by IT and business teams. The goal is to establish a set of fallback strategies, that support technical and business areas, that can be invoked in a timely manner to keep business functions working in an uninterrupted fashion through the Year 2000. Prior risk identification activities, which define the dependencies among various functions, systems and third parties, are the basis for building a contingency plan. Obtaining a model of at-risk functions, along with the systems and external entities that support those functions, is a prerequisite for beginning the contingency planning stage. Priority rankings of external entities and various computer systems are also required to ensure that the level of contingency planning and action to be taken is commensurate with the importance of each function, system and external entity. Assign Consequences, Probability To Risk FactorsThe first step in building a contingency plan is to examine the consequences and the probability of the risks associated with each function, system and external entity. Analysts should consider the following steps in assessing consequences and probabilities.
An example of how this process would work can be found in a policy issuance function found within an insurance company. The external entity upon which this function depends includes insurance brokers and agents. The downside of a complete shutdown of broker services is a 40% loss in revenue. Agent failures would account for another 55% revenue loss. A major IT based downside involves the loss of the policy system that issues and bills for policies. The financial risks involved in shutting down the policy system could impact up to 100% of revenues. Other external and internal risks should be categorized appropriately. The odds of a policy system failure is 20% based on remediation work currently underway. The odds of an agent failure at the field level is 30% based on analysis of technical field capabilities and Internet related risks. Broker failure is estimated to be a 10% risk based on the fact that the system used to input policies by brokers is relatively new and deemed compliant. Ranking the odds of failure across this business unit will help determine the level of spending and effort to be associated with contingency plans in each area. Identify Technology Based Risk Reduction AlternativesIf a technology based problem occurs, analysts must determine the appropriate IT and business based responses to mitigate risks related to that problem. In many cases, the IT contingency response to a system error is to "fix the system". The planning process should be pursued for each business area being examined as follows. 1. For each application system in the group, list the correction priorities to be applied if the system fails:
2. If a data file or data base is contaminated:
3. For each external data interface that fails, assess options to:
4. For the hardware device supporting various application systems, identify how support areas would respond if that hardware has problems:
5. For each application package supporting this system, list the sequence of responses that would be required to fix or supplement the functions of that package:
6. Where potential embedded technology failures might occur, list the likely response including:
7.If reporting or query functions fail, consider rebuild options that could supplement the data being provided by those functions. Identify Business Based Risk Reduction Alternatives The response to business related problems that might occur due to the Year 2000 tend to differ from technology driven responses. This category includes responses to direct threats to the business from suppliers, embedded technology, business partners, bad external data or the Internet. Business professionals must also plan to respond to IT related problems that may stem from system or infrastructure failures. General guidelines are listed below. 1. If a system failure is imminent and the IT team has no way to fix it, consider:
2. If a system failure occurs and the IT team has no way to fix it, consider:
3. If a system is going to be down for a brief period and repairs are underway consider:
4. If a product fails that was acquired from a supplier:
5. If a service supplier fails to continue to deliver that service:
6. If a product fails that was sold to a customer:
7. If a business partner fails:
Prioritize Risk Reduction OptionsAs soon as various contingency options have been identified for each situation, function, system and business area, analysts must prioritize responses to each situation that may arise. This is a matter of ranking each response to a given problem beginning with the most desirable to the least desirable based on the impact of that response. For example, stopping production of a product may be less desirable than selling the product at a loss for a period of time. Response ranking should be applied to both technical contingency and to business contingency options. Business unit sponsors and other executives should review and approve these plans and the applicable rankings that have been assigned to each situation / response in a given business area. Analysts should note that executives may argue that this level of contingency analysis is unnecessary because management can make these decisions "on the spot" as they do now when other crisis situations arise. Analysts should make it clear to these executives that there may be hundreds of concurrent problems arising during the late 1999 and early 2000 transition window. Many of the decisions being made during this time will have a ripple effect on other systems, functions and third parties. Preparedness, based on a well thought through action plan, may be what differentiates Year 2000 survivors from those that panic and cannot fulfill financial, legal and regulatory obligations Monitor Year 2000 Progress & CheckpointsOnce basic plans are in place, management, working through the project office, should closely monitor checkpoints so that the "point of no return" for a replacement or a remediation project does not pass unnoticed. If the window of opportunity passes on a date field expansion project, for example, management may need to invoke an emergency fix to that system or alternatively launch a procedural workaround solution. The project office must also keep business sponsors and end-users informed of progress so that event horizons or other checkpoint events do not end up blind-siding the business community. The business community has a similar obligation as far as monitoring and updating management on the status of suppliers, business partners, end-user systems and external data interfaces. When critical deadlines for a business unit come to pass, the management team for that business unit must identify and correct problems before they arise. About the AuthorsIan Hayes is the founder and president of Clarity Consulting, Inc., www.clarity-consulting.com in Hamilton, MA. Ian specializes in strategic consulting on the management and support of corporate business systems. A frequent speaker, senior editorial advisor for the Year/2000 Journal and contributing columnist for Software Magazine, Ian has advised dozens of companies on a variety of IT issues, including those related to their Year 2000 initiatives, and has written numerous articles on the topic. Ian has also served as keynote speaker for numerous Year 2000 seminars and sits on the Brainstorm Year 2000 National Symposium Series Board of Governors. Together, Ian Hayes and William Ulrich are authors of the best selling Year 2000 books, "The Year 2000 Software Crisis: Challenge of the Century" and "The Year 2000 Software Crisis: The Continuing Challenge" published by Prentice Hall.
|
|
Send mail to webmaster@systemtransformation.com
with questions or comments about this web site. |
Transformation
