(C) Copyright IBM Corp. 1995, 1997
The Year 2000 and 2-Digit Dates: Guide
INDEX
CHAPTER 3. PLANNING TO RESOLVE YOUR YEAR2000 EXPOSURES . . . . . 3-1
Planning Considerations . . . . . . . . . . . . . . . . . . . . . 3-2
Inventory Your Software Portfolio . . . . . . . . . . . . . . . . 3-7
Inventory Your Hardware Systems . . . . . . . . . . . . . . . . . 3-7
This chapter and those that follow focus on Year2000 project phases: planning, exposure identification, exposure elimination, testing, migration, and the selection of available tools. The larger your computing environment, the more diverse its software, the more decentralized its physical environment, the greater control you must exercise, and the greater the communication that must exist across the individual projects.
THE TIME TO BEGIN BOTH PLANNING AND YOUR YEAR2000 TRANSITION IS NOW.
Consider the following:
o Getting requirements and design changes into the development cycle takes time. The review and modification of the application takes time. Securing resources and skills takes time. (If you have not kept current with the latest technology, your challenge might be greater and your options fewer.) Handling the problem in real time will disrupt your customer services, and the business impact might be significant.
o Most organizations are already short-handed when addressing their current workload and the challenges they face. Therefore, with this additional effort, perform a risk assessment and identify what is critical to the success of your business and determine and prioritize those work items.
o A significant amount of code rework might be required to complete your Year2000 transition. It is not merely a problem that can be fixed by expanding the data fields. You must make changes to your data dictionary, data bases, files, programs, and so on.
o Within some institutions, programs are already producing incorrect output, and many organizations that aren't experiencing problems today, can reasonably expect problems in the future. For example, insurance companies in 1996, when calculating rates for persons born in '95, might find themselves assessing 101-year-old rates on a new-born scale, or potentially assessing a new-born at the same rate as a centenarian.
Time to plan, design, implement, and test your Year2000 transition is limited. Each application is different and many can potentially fail long before the year 2000. Individual applications can have unique thresholds that could fail years earlier. Consider expiration dates on credit cards, drivers' licenses, 3- and 5-year business planning cycles as a few examples. For many organizations, the time remaining might be too short to complete a comprehensive Year2000 project across the entire software and hardware inventory. It is increasingly important to prioritize efforts on critical systems. Also, consider that each day that passes prior to your Year2000 transition allows more data to be added to databases and the potential for additional routines and programs that are not Year2000 ready to be added to existing system. Also, expertise that is present today might not be available later.
Finally, there have been projections that the availability of consulting and outsourcing services to meet Year2000 transition needs will become increasingly limited as we approach the year 2000. For organizations with applications that handle future dates or those with thousands of application programs, the consequence of delaying the resolution of the problem could seriously impact their continued future success.
1. Identify and communicate the organization goal:
The goal is to have the function and operation of an organization Year2000-ready before any disruption caused by 2-digit-year data occurs. IBM defines YEAR2000-READY as follows: The capability of a Product, when used in accordance with its associated documentation, to correctly process, provide and/or receive date data within and between the 20th and 21st centuries, provided that all other products (for example, hardware, software, and firmware) used with the Product, properly exchange accurate date data with it.
2. Identify the deliverables and associated schedules for the following:
o Hardware
o Software
o Documentation
o Training
o Maintenance
o Operations
o Administration
o Acceptance criteria for all deliverables
3. Analyze job assignments
For each task,
o Identify the responsible person or organization, for example
- Customers
- Management
- Chief Executive Officer
- Chief Financial Officer
- Chief Information Officer
- Software Development Managers
- Operation/Administration Managers
- Budget/Finance Managers
- others
- Computer vendors
- Solution Developers
- IT outsourcing vendors
- Consulting/Integration services providers
- System analysts
- System designers
- System/Application Programmers
- Operations personnel
- End Users
- Auditors, quality assurance people
o Measure the estimated completion time
o Identify precedences/dependencies
o Identify resources and skills
o Identify critical path schedule
o Measure efforts
o Measure costs
o Identify technical factors
o Analyze potential benefits
- Return on investment
- Achievement of business goals
- Potential quality and acceptance of the approach
- Your business keeps running
o Analyze risk factors:
- Complexity of the task
- Resource/time constraints
- Length of project
- Critical development skills
4. Measure the criticality of each task and prioritize:
Evaluate and determine how critical the functions of each entity are to the business success of the organization, and prioritize the sequence of providing Year2000-ready solutions. An entity could be an individual, a department, a division, a business unit, customers, vendors, and so on, that are involved in the operations of the organization. The factors contributing to how critical you consider a task to be might include pressure of demand from end users for Year2000-ready systems, legal issues, financial issues, or political issues.
IMPACT TO BUSINESS
To determine the impact to your business, consider including these tasks:
o Critical to the operation of the business (such as legal compliance)
o Critical to the uninterrupted operation of the business (such as payroll)
o Required to support the business (such as management and financial reports)
o Required to support the business; however, the importance and timetable for the activity is lower than an item above (such as regular scheduled reports)
o Desirable, but not absolutely required to support the business.
IMPACT TO OPERATIONS
Once classified by task, then determine impact severity. For example, you could use categories such as:
FATAL Operations will ABEND or terminate
CRITICAL Operations will produce an incorrect result. (For example,
expiration dates for food or pharmaceutical products are
calculated as over 100 years old, not one or several days old.)
MARGINAL Minor inconvenience, annoyance, or irritation. (For example,
inventory reports collate dates of 00 prior to 99.)
Based on the impact to a particular process, evaluate the desirability of reworking a particular piece of code. Here is an opportunity for your IS management and your business strategists to improve overall business efficiency by taking inventory, accessing your IT strategy, and making more efficient use of your IT infrastructure. Together these groups should consider possibilities such as:
o Abandoning the business process
o Combining the process with other processes
o Replacing the process with a new state-of-the-art process.
5. Establish a 'critical event horizon':
Business environments are unique. The initial date your institution will begin experiencing Year2000 problems is also unique. If you prepare business forecasts of a 3-year cycle, the fourth quarter of 1996 might be your critical event horizon. If you deal in automobile loans, 1995 might be your critical event horizon. It is likely to be a very rare institution that will not experience some form of Year2000 difficulty until 1999 or 2000.
6. Provide data administration:
o Identify the scope and responsibility of migrating the affected data
- Exclusive. The affected data object is created and processed exclusively by this business area and is independent of any other business area. This could be at an individual, department, or the business area level with further decomposition and analysis.
- Primary responsibility. The business area defines the affected data object and other business areas should use that definition or negotiate for its redefinition.
- Secondary responsibility. The affected data object is defined and created by a different business area in the enterprise, and is distributed only within the scope of the enterprise. Each business area defines its own use of the object which is provided by the business area with the primary responsibility.
- External exposures
- The affected data object is defined and created by either this or a different business area in the enterprise, and is distributed beyond the scope of the enterprise.
- Data is created outside your enterprise and then imported and used within it.
o Determine formats of the data dictionary
o Determine procedures for changing and entering data elements
o Determine procedures for collaborative data sharing and use
7. Decide project technical and management approaches:
o Programming standards, conventions, and guidelines
o Platform for application development
o Hardware/software
o Development methodology
o Development and test procedures
o Prototyping and parallel development
- Commonly used in software development projects and should be applied wherever appropriate.
- Apply a divide-and-conquer approach to partition the Year2000 project into smaller projects so that development and testing can proceed in parallel.
- Parallel development can shorten the development cycle. This is extremely critical when dealing with time-sensitive projects such as this Year2000 project.
o Process/data modeling
o Data dictionary
o Documentation structure, layout, and standards
o Reviews and walk-throughs
o Quality assurance procedures
o Testing methodology
o Automated tools
o Migrations of and bridgings to existing Year2000-ready systems
o Estimated future costs of maintenance
8. Identify project constraints, interfaces, and dependencies:
o End users/customers
- Availability of test and other data
- Availability of facilities and services
- Responsibility for reviews
- Responsibility for end user tests
- Other actions.
o Special contract negotiations
o Outsourcing and consulting services
o Interfaces and dependencies with other projects
o Supporting services and facilities required
o Hardware and software to be used
o Solution Developer-automated tools to be used
o Risks and alternative solutions
o Other assumptions.
9. Provide standards, guidelines, quality assurance, and review procedures:
o Year2000-ready standards for purchasing of hardware/software vendor products.
o Year2000-ready system requirements on request for proposal for outsourcing and integration services providers.
o Organizational Year2000-ready standard/guidelines/process for specification, design, development, and testing of new and existing software.
o Year2000-ready checklists for potential exposures.
o Standard for machine-human interface (Refer to "Guidelines" on page 5-17 for a list of standards.)
o Procedures for submitting and processing proposed changes. The procedures should evaluate why change is needed, consequence of not making the change, and its effect on product, cost, and schedule
o Procedures for sign-offs and approvals. The procedures should solicit comments from knowledgeable and affected people about likely effects on product, documents, schedule, and costs.
o Procedures for future follow-up.
The first step requires that you thoroughly understand your computing environment and compile an inventory of all the software programs within that environment. Such an inventory allows you to:
o analyze your portfolio for definition and movement of date-related data elements and the use of date-related calculations and manipulation
o identify and remove Year2000 exposures
o track and control changes to your portfolio to more easily monitor and prevent injecting new Year2000 exposures into your inventory while your Year2000 resolution work progresses
o test the new (Year2000-ready) version of the software programs in your portfolio.
Once you have completed the above activities, you are ready to migrate from your current computing environment to your Year2000-ready environment. The following chapters discuss these activities in detail and provide options and suggestions for your consideration.