Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Discuss Year 2000 Issues -- Ignore unavailable to you. Want to Upgrade?

To: John Mansfield who wrote (1228)	3/21/1998 1:46:00 PM
From: John Mansfield	Read Replies (1) \| Respond to of 9818

From State of Texas Recovery Plans [draft] Definition A recovery plan is a manual with procedures, responsibilities and critical information needed to execute a recovery. Recovery from the loss of facility(s), information resources, and skilled key personnel is generally the accepted approach to building a recovery plan. A fundamental premise of a successful business continuity plan is that the plan is developed by those who must actually carry out the recovery in the event of an actual disaster. The planning effort should be centrally coordinated to ensure that the recovery plan will: be commensurate in scope with the impact and magnitude of loss or harm that could result from an interruption; identify and rank subsets of critical and essential business function activities and processes based on how long the organization can survive without each one; reduce confusion during a chaotic period by documenting an orderly recovery process that ramps up recovery at an acceptable, although degraded level, reducing impacts to the organization, over an extended period of time;' identify minimum recovery resources and establish a source for each; use available, or develop, cost-effective recovery strategies; contain written step-by-step procedures and documentation that addresses all elements of the plan; provide annual testing and maintenance process to ensure accuracy and currency of the plan. ... [lots more] [snip] -- Harlan

To: John Mansfield who wrote (1228)	3/21/1998 3:48:00 PM
From: John Mansfield	Respond to of 9818

Subject: DEVMODL: Topic 002: Generating a Last Ditch National Y2k Project Plan Date: Sat, 21 Mar 1998 14:32:33 GMT From: Chris Anderson) Organization: Intertech Systems, Johannesburg, South Africa Newsgroups: comp.software.year-2000 Generating a Last Ditch National Y2k Project Plan This article forms part of the "Y2k MODEL FOR DEVELOPING COUNTRIES" Series. In 1995, Ken Orr presented a slide which showed his predictions for the probable effects of Y2k for AWARENESS, DENIAL, PANIC, TRIAGE, LITIGATION. Taking his example and projecting forward to the current time, we are seeing AWARENESS and DENIAL moving forward until today, and expect to project them forward as an ongoing exercise. We have not seen any PANIC yet. TRIAGE is yet to come. Now that we are emerging from the "Middle Game" and moving into the "End Game" (to steal Chess terminology) and have a look at generating a Project Plan, starting today, a chilling picture emerges. There are really two project plans, one for Mainframes (the EBCIDIC scenario) and one for PC's and LANs (The ASCII scenario). The EBCDIC scenario presupposes total replacement of the Operating System software, Utilities and Middleware. And then retrofitting application software to work in this new environment. July 1, 1998 is in my opinion the "DROP DEAD" date for such systems. The ordering cycle and product lead times would preclude success. The ASCII scenario presumes application of patches, Setup of appropriate parameters, and also retrofitting of application software. But total replacement, and the corresponding disruption, is not necessarily an issue. Somewhere in between are those systems where a decision has been made to migrate to a different architecture or more commonly where an organisation has both EBCDIC and ASCII components. Another assumption is that if people do not start today, then 1 May 1998 seems to be the latest feasible start date. NATIONAL Y2k PROJECT PLAN Immediate Start: (1998-03-17) 470 working days Late start: (1998-05-01) 394 working days Drop Dead date: 1998-07-01 Support for Y2k Life Cycle: Early Start Late Start Target Milestone 1998-03-17 1998-05-01 2000-01-03 AWARENESS 1998-03-17 1998-05-01 2000-01-03 ASSESSMENT 1998-03-17 1998-07-01 2000-01-03 REMEDIATION 1998-03-17 1998-07-01 2000-01-03 VALIDATION 1998-03-17 1998-07-01 2000-01-03 TESTING 1998-03-17 1998-07-01 2000-01-03 IMPLEMENTATION OPTIONAL MILESTONES 1999-03-17 1998-07-01 1999-01-01 Year End Testing 1998-03-17 1998-07-01 1999-01-01 Euro compatibility Now this is a very crude model. It does not even attempt to apply estimates of how long each phase should take. However it is a starting point. The original suggestion that Y2k remediation and testing should be completed by end 1998 is probably no longer feasible. If however, 1997 year end test data is still available, an "asynchronous" test could be performed. Similarly, the 1998 year end data could be used for parallel testing during 1999. A complicating issue is that organisations differ in their end of financial period reporting dates. My suggestion, in order to obtain the maximum "parallelism" between phases is to chop the effort into smaller chunks, starting with Obvious Mission Critical Systems, put these into the Remediation and Testing cycle as soon as possible and continue the cycle for other systems. For example, any systems which would be affected by the impact of the Euro currency should be put on a separate fast track to make the dealine of 1999-01-01.. The function of the National Competence Centre would be to map the schedules of the Major Governmental Infrastructual Players against this base model as a base for the National risk Assessment. Local Competence Centres could do the same for Industry and Commerce. There would be great PR Awareness value in making this information public. An HTML version of this document, with diagrams, is to be found at cinderella.co.za ------------------------------------------------------------------------ Chris Anderson email: Y2K Cinderella Project webmaster@cinderella.co.za cinderella.co.za Striving for Year 2000 Compliance