"...85% of current mainframe systems will be in production at the end of the century and less than 50% will be Year 2000 compliant..."
- Gartner Group
The "Challenge." Also known as Century Date Change, the Year 2000 (Y2K) "challenge" has gained enormous attention in the Information Systems (IS) world. Defining the problem is relatively straightforward. We are confronted with Y2K today because those who developed computer systems and applications over the past few decades used two digits to designate the year. Calculations work fine as long as both dates are in the same century. Unfortunately, as we move between centuries, problems arise. For example, if 00 is used to designate the year 2000, then calculations such as 00 - 95 result in -95 instead of 5. As a result, most of our legacy systems and some recently developed systems will abort or produce erroneous data once the year 2000 arrives. Systems that project dates (do calculations or logic operations using dates in the future) will run into the problem even sooner. Y2K can also be defined by its scope. It affects everyone, it affects everyone at the same time, and its deadline is fixed! Given this, its easy to understand why many are referring to Y2K as the single largest computer effort ever.
While defining the problem is simple enough, convincing senior management and even system managers that the threat is real, is not as easy. One of the greater challenges any Y2K project manager faces is getting started. To this end, the awareness phase of this document offers some guidance and examples from those who have been through it. Also included are briefings such as those given before Congress in May 1996 by Mr. Emmett Paige Jr., the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence; and others throughout the Federal government and industry to help new project managers get off to a quick start.
There are several key areas which must be examined in defining the Y2k problem. The first is time. Time is very critical, and it must be made clear that the organization cannot wait until 1999 to worry about Y2K. There are two very different reasons why this is true. The first is that many systems will fail before January 1, 2000. Many systems make projections or calculations for one or more years into the future. This is why the insurance and banking industries were among the first to understand the impact of Y2K. They experienced failures in the systems which calculated long-term loans and insurance policies. The second reason why time is so critical is that identifying every occurrence of a Y2k problem in a system is very time-consuming. Making an individual Y2K fix doesn't take long, but there may be many to make. In addition, testing the software after changes have been made is extremely labor intensive, due to the fact that files and databases must be aged (See Validation Phase), and any differences in output resolved.
Another aspect of Y2K is that commercial hardware and software are affected as well as application software. The Federal government is working to identify which versions of various commercial products properly process Y2K. www.itpolicy.gsa.gov/mks/yr2000/y201toc1.htm#vendors]
Still another aspect of Y2K that is sometimes overlooked is that it affects some physical devices such as elevators, access and environmental control devices, and card readers such as credit card readers. Such things generally fall outside the responsibility of the information technology community, but someone needs to evaluate and address them.
It must be pointed out during the Awareness phase that in order for application software to be fixed for Y2K, the source code must be found. While this might not sound like a burdensome requirement, very few organizations have a good inventory of their source code. It is possible to reconstruct source code, but it is not easy and generally requires hiring a company that specializes in such work, of which there are a very limited number.
Lastly, there is the potential of security breeches due to Y2K. Dates are often used to identify random number generator entry points, or as part of an encryption key. Although these might continue to execute as intended, Y2K may cause results to be repeated and thus be a security issue.
Obtain High Level Management Support
To be successful in addressing Y2K, senior leadership must understand and vigorously support efforts to resolve Y2K. Without buy-in from the top, all Y2K efforts will be difficult and the acquisition of required resources, all but impossible. Sometimes a business case (See Make a Business Case below) must be prepared before senior leadership will be convinced of the impact of Y2K on the organization. The Chief Information Officer (CIO) needs to champion Y2K and ensure that the Chief Executive Officer (or equivalent) understands that Y2K is a business issue, which needs the active support of the senior managers in each of the business/functional areas. Initial briefings must be well thought out and clearly emphasize the scope of the problem and the consequences of not addressing it immediately. Organizational case studies, if available, are a excellent way to highlight the problem. If none can be found, examples of other Federal systems already affected by Y2K are also effective.
The first step in attacking Y2K is to establish a full time Y2K Project Team. Because this team must operate at the highest levels of government or the corporation, technical expertise is less important than communications skills, general knowledge of the organization, and understanding the interaction among systems in the business units/functional areas. The team should have various technical areas, such as database, programming and systems analysis, represented as needed.
To complement the team's efforts, an organizational steering group should also be established which consists of customer representatives and other key organizational personnel. The steering group must be kept informed about Y2K efforts and be able to make decisions on resources and priorities for Y2K. The Program Manager should chair a working level group of the steering group which includes representatives of the various business units/functional areas.
The Year 2000 Project Team must decide early on an overall approach which must be publicized throughout the organization. To be successful, it is essential that each organization establish an approach that addresses each phase of the Y2K resolution process. As an example, the DoD management plan focuses on centralized management with decentralized execution. This allows the Military Services and Defense Agencies the flexibility to address the problem as they see fit while also benefiting from best practices in a well coordinated effort. The overall approach will be driven by the size and culture of an organization; and most importantly, how resources (funds) are allocated and expended in the organization. The approach makes it very clear who will be paying for Y2K activities, and what the priority for those activities is. Another part of the overall approach is how Y2K will be addressed and the terminology which will be used to describe it. The five phase approach you are reading is such a description, and is the one most Federal agencies are using.
Make Oral and Written Presentations
To successfully promote awareness throughout an organization it is essential that the Y2K project team establish a presence by providing oral presentations to personnel at every level. This will offer credibility to their efforts and allow those with questions a chance to ask them directly. As an example, the Air Force has developed a Y2K project team that visits all major commands and presents its Year 2000 Resolution Seminar to both senior management and technical groups. These slides are also made available to others via the Air Force Year 2000 Home Page.
The Y2K project team must also develop additional communication avenues for promoting awareness and sharing information. This includes publishing articles in organizational newsletters, developing a World Wide Web home page with links to Federal and industry Y2K sites, creating a Year 2000 mailing list, attending industry and Federal Y2K conferences, site visits, and video teleconferences. Incorporating these suggestions into an overarching awareness strategy will go a long way in organizing awareness efforts and ultimately Y2K resolution.
Identify Technical and Management Representatives
Identification of all technical and management points of contact (POCs) is critical to successful Y2k resolution. This includes system managers, budgeting and resource personnel, legal representatives, senior management, and of course contractors and other external contacts. Above all else, Y2K is a management nightmare that demands a tremendous coordinated effort. As a result, everyone who has a stake in its outcome must be made aware of their roles and responsibilities as quickly as possible. Just as important, each should know how other key players fit into the overall plan.
Identifying POCs will likely be a trying effort in the initial stages since many organizations try to decide who is best suited to represent their needs. Nevertheless, the earlier "permanent" POCs are identified, the easier the overall effort should be. The free flow of Y2K experiences among these people will help avoid duplication of effort and reduce the learning curve in Y2K activities and best practices.
Y2K will require expenditure of considerable resources (funds and people) which generally have not been anticipated. In order for senior leadership to ensure adequate Y2K resources, they must be convinced that resolution of the Y2k problem is essential for the organization to accomplish its core mission(s), or keep from going out of business. The business case must be developed for each system as well as the organization as a whole. The organization's entire inventory of systems will need to be examined and a decision made on the importance of each one to the business. Some systems may be terminated at this point because of their low relative importance to the organization. Senior management must be advised of commercial Y2K cost estimates www.gartner.com/aboutgg/pressrel/pry2000.html] and experiences from industry. In the end, they still must be convinced that their own business is at risk. This might require Y2K assessments being conducted on one or more critical systems to specifically identify Y2K problems that could occur if left undetected or uncorrected. It is very possible that system maintenance personnel have already encountered Y2K problems that have resulted in the loss of revenue, erroneous business decisions, or failure to accomplish the mission for a period of time. The business case should include analysis of the impact of database corruption by systems that do not correctly handle Y2K with the results being passed among systems like a computer virus.
Moving Beyond the Information Technology Community
External customers must be identified and educated as soon as possible. They need to know what Y2K is and how it can potentially affect them. Since most agencies will have limited resources to address the Y2K, some systems which customers depend upon today may not be around after the Year 2000 because they may be identified as non mission critical, and retired. Given this, it is critical that project managers immediately inform all customers of their options and ensure they play an active role in each phase of the company's Y2K resolution efforts. Business unit/functional area managers must understand the seriousness of Y2K and be convinced that their systems are not immune. They must also prepare contingency plans to compensate for systems that fail or that depend upon information from systems that fail.
Part of the education of the non IT community involves information about how this problem came to be. While there is a tendency to blame the information technology community for Y2K, it is imperative that this attitude be put aside and the problem addressed head on. One approach is to explain why dates were coded with two digits for year rather than four, and to show how long some of the systems have supported and benefited the organization. comlinks.com/mag/accr.htm]
As was pointed out in "Define the Problem" above, there are aspects of Y2K that go beyond the normal responsibilities of the information technology. Security and physical device Y2K issues must be investigated and resolved by the business unit(s)/functional area(s) responsible.
Establish Compliance Standards
The definition of Y2K compliance and the standards that deliver compliance are hotly debated issues. One definition for compliance, provided by IBS , states compliant applications and systems are capable of correct identification, manipulation, and calculation using dates outside the 1900-1999 year range and have been tested as such. This definition allows for long-term fixes based on 8-digit date fields and short-term fixes using logic-based approaches (allowing the system to maintain its 6-digit format). In either case, applications and systems continue to function as designed and data remains uncorrupted. How data is stored and processed "internally" is a decision to be made on a case-by-case basis.
The Federal government's Y2K Interagency Committee (IAC) has been addressing Y2K compliance and compliance standards since January, 1996. The National Institute of Science and Technology (NIST), has provided a standard date format, Change 1 to Federal Information Processing Standard (FIPS) Publication (Pub) 4-1. The General Services Administration (GSA) spearheaded efforts to provide contract language for new contracts and contracts to be modified alike. www.itpolicy.gsa.gov/mks/yr2000/y2kfnl.htm] They have also modified the Federal Acquisition Regulation (FAR) to include language related to Y2K. www.itpolicy.gsa.gov/mks/yr2000/yr2000.htm]
Some organizations, such as the Social Security Administration, have adopted standard date routines and require that they be used in all their software. There are several approaches that can be used to address date formats. One is to use a standard date format (usually four digits to represent the year) which ensures that there is no Y2K problem, but may require changes to other systems which might otherwise remain untouched. At the opposite end of the spectrum is a policy that states that no system will change the format of date information it sends or exchanges with other systems or databases. This effort minimizes the rippling effect of changes to other systems/databases. Unfortunately, this also leads to the need for the development and insertion of date translation or conversion software/bridges to ensure proper processing of information within the system.
There is no foolproof approach. Ultimately, the solution lays in talking to, and working with, the owners of the systems/databases with which your systems exchange information so that bridges can be installed at the proper time and place and removed as required on a predetermined schedule. This, again, emphasizes the importance of Y2K project management.
Start Preparation of a Project Plan
Even with incomplete knowledge of Y2K costs and schedules, it is important that meaningful work begins as soon as possible. It is advantageous to have a high-level organizational management plan which includes things such as: a brief statement of the situation, Y2K objectives, Y2K management strategy, and assignment of responsibilities as described in "Decide on an Overall Approach" above. The plan can be refined over time as more information becomes available and experience has been gained.
The Y2K Project Team should develop and publicize a Y2K corporate approach briefly outlining the organization's high level game plan. This approach will serve as the basis for the detail Y2K project management plan (PMP) which defines the organization's overall strategy in greater detail. The corporate approach should be included in the initial release of the PMP. It is critical the PMP address Y2K goals and supporting objectives such as sizing the problem; identifying current efforts and solutions throughout the Federal government and industry; informing and educating all customers; identifying best practices; and establishing metrics for assessing project completion. Once this has been accomplished efforts should then shift to immediately drafting the contents of the PMPs, focusing on the Awareness and Assessment Phases. While the first release of the PMP will be incomplete, it will still provide much needed guidance and direction throughout the organization. The amount of detail included in PMPs depends upon organizational needs. Some will undoubtedly go into great detail while others may offer little more than a corporate approach highlighting roles and responsibilities. Those who choose to do the latter are bound to find the effort more trying. Y2K is above all else a management problem. Attempting to prioritize and schedule systems changes, procure resources, and secure funding takes a team effort at every level. Those who attempt to accomplish these and countless other management tasks without a well defined PMP are planning for failure. While the actual Y2K "fixes" will take place in the trenches, placing those who will make these fixes in position to do so requires significant planning at the highest level.
BACK TO TOP OF PAGE