Year 2000 Assessment

Organization Year 2000 Program Phase or Activity Questions: Awareness Assessment Renovation Validation Implementation Program Management

Organizations Year 2000 Program Phase or Activity -- Processes:

Awareness -- Assessment -- Renovation -- Validation -- Implementation -- Program Management

2.0 Assessment

Organizations may not have enough resources, skill, or time to convert or replace all of their
information systems. Organizations must determine what systems are mission-critical and must be
converted or replaced, what systems support important functions and should be converted or
replaced, and what systems support marginal functions, and may be converted or replaced later.
The Year 2000 problem is not just an information technology problem, but is primarily a business
problem. Thus, the process of identifying and ranking information systems should not be limited to
a simple inventory of applications and platforms, but must include assessments of the impact of
information systems’ failures on the organization’s core business areas and processes.
The assessment should also include systems using information technology which operate outside
the traditional information resource area, including building infrastructure systems and telephone
switching equipment.

Key Processes
2.1. Define Year 2000 compliance
2.2. Focus on core business areas and processes and develop a Year 2000 assessment
document
2.3. Assess the severity of an impact of Year 2000-induced failures
2.4. Conduct enterprise-wide inventory of information systems for each business area
2.5. Develop a comprehensive automated system portfolio
2.6. Analyze system portfolio
2.7. Prioritize systems and components to be converted or replaced
2.8. Establish Year 2000 project teams for business areas and major systems
2.9. Develop Year 2000 program plan
2.10. Identify, prioritize, and mobilize needed resources
2.11. Develop validation strategies, testing plans, and scripts
2.12. Define requirements for Year 2000 test facility
2.13. Identify and acquire Year 2000 tools
2.14. Address implementation schedule issues
2.15. Address interface and data exchange issues
2.16. Initiate the development of contingency plans for mission-critical systems
2.17. Identify Year 2000 vulnerable systems and processes operating outside the
information resource management area

2.1. Define Year 2000 compliance

2.2. Focus on core business areas and processes and develop a Year 2000 assessment document

Information systems are not created equal. Systems supporting mission-critical business
processes are clearly more important than systems supporting mission support functions--
usually administrative--although these are necessary functions. A focus on core business
areas and processes is essential to the task of assessing the impact of the Year 2000
problem on the enterprise and for establishing the priorities for the Year 2000 program.

2.3. Assess the severity of an impact of potential Year 2000-induced failures

An assessment of the severity of Year 2000 failure needs to be done for each core business
area and associated processes.

2.4. Conduct an enterprise-wide inventory of information systems for each business area

An enterprise-wide inventory of information systems and their components provides the
necessary foundation for Year 2000 program planning. A thorough inventory ensures that
all systems are identified and linked to a specific business area or process, and that all
enterprise-wide, cross-boundary systems are considered.

2.5. Use inventory data to develop a comprehensive automated system portfolio and identify, for each system

· links to core business areas or processes
· platforms, languages, and database management systems
· operating system software and utilities
· telecommunications
· internal and external interfaces
· owners
· the availability and adequacy of source code and associated documentation

2.6. Analyze portfolio and identify for each system

· non-repairable items (lack of source code or documentation)
· conversion or replacement resources required for each platform, application, database
management system, archive, utility, or interface

2.7. Prioritize system conversions and replacements

An organization must determine priorities for system conversion and replacement by ranking
based on key factors, such as business impact and the anticipated failure date. An organization
also needs to identify applications, databases, archives, and interfaces that cannot be
converted because of resource and time constraints.

2.8. Establish Year 2000 project teams for business areas and major systems

Multi-disciplinary project teams consisting of domain experts in relevant functional areas,
system and software specialists, operational analysis specialists, and contract specialists
need to be established with explicit objectives and time schedules. Access to legal advice is
also a necessity.

2.9. Develop Year 2000 program plan, including

· schedules for all tasks and phases of the Year 2000 program
· master conversion and replacement schedule, including identification of systems and
their components
· assessment and selection of outsourcing options
· assignment of conversion or replacement projects to Year 2000 project teams
· risk assessment
· contingency plans for all systems

2.10. Identify, prioritize, and mobilize needed resources

Achieving Year 2000 compliance will require significant investment in two vital
resources--money and people. Accordingly, agencies will need to make informed choices
about information technology priorities within their organization by assessing the costs,
benefits, and risks of competing projects. In some instances, agencies may have to defer or
cancel new system development efforts and reprogram the freed resources to achieve Year
2000 compliance.

2.11. Develop validation strategies and testing plans for all converted or replaced systems and their components. Identify and acquire automated test tools and develop test scripts.

The testing and validation of the converted or replaced systems will require a phased
approach. For example, an approach developed by IBM includes four phases:
· Phase I--unit testing--focus on functional and compliance testing of a single
application or software module.
· Phase II--integration testing--test the integration of related software modules and
applications.
· Phase III--system testing--test all of the integrated components of an information
system.
· Phase IV--acceptance testing--test the information system with live operational data.
Regardless of the selected validation and testing strategy, the scope of the testing and
validation effort will require careful planning and use of automated tools, including test
case analyzers and test data libraries.

2.12. Define requirements for Year 2000 test facility

Agencies may have to acquire a Year 2000 test facility to provide an adequate testing
environment and to avoid potential contamination or interference with the operation of
production systems.

2.13. Identify and acquire Year 2000 tools

Agencies should identify and acquire Year 2000 tools to facilitate the conversion and
testing processes.

2.14. Address implementation schedule issues, including

the identification and selection of conversion facilities
time needed to put converted systems into production
the conversion of backup and archival data

2.15. Address interface and data exchange issues, including

the development of a model showing the internal and external dependency links between enterprise core business areas, processes, and information systems
the notification of all outside data exchange entities
the need for data bridges and filters
contingency plans if no data are received from an external source
validation process for incoming external data
contingency plans for invalid data

2.16. Initiate the development of contingency plans for mission-critical systems.

Agencies should initiate the development of realistic contingency plans--including the
development of manual and contract procedures--to ensure the continuity of core business
processes.

2.17. Identify Year 2000 vulnerable systems and processes operating outside the information resource management area

Identify and assess Year 2000 vulnerable systems and processes outside the information
resource management area, including telephone and network switching equipment, and
building infrastructure systems. Develop a separate plan for their renovation.

The Disaster Center Year 2000 Page| |The Disaster Center Index Page

Formatted and altered from text provided by: The United States General Accounting Office Accounting and Information Management Division HTML format Copyrighted by The Disaster Center 1998