|Home > Y2K >|
The following Y2K material has been kept available by MITRE for historical purposes only and has not been updated unless noted.
Start Immediately -- Go Over These Steps
WHERE TO START-A Y2K PROCESS
The successful Y2K process is concerned with two issues -- compliance and certification. Compliance addresses the operational issues of the system in the Year 2000 and beyond. Certification addresses management's responsibility in obtaining compliance, ensuring that each program exercises due diligence in achieving Year 2000 compliance and documents their effort. Compliance Process and the Certification Process were developed to assist organizations in addressing these issues. These are described as separate processes, but should be undertaken simultaneously, and considered joint efforts between those certifying, and those bringing the system into compliance.
A typical Y2K effort has five major phases, as developed and used by the DOD. Please see the Government Accounting Office's (GAO) Year 2000 Computing Crisis: An Assessment Guide [PDF] for more detailed information on the five phases of the compliance process. In addition, for a more thorough discussion of the Year 2000 problem and the compliance process, please see the October 1997 Crosstalk magazine article Dealing with Dates: Solutions for the Year 2000. These phases are also referred to in the MITRE Assessment Briefings. The process can be tracked using a Triage Scorecard or some similar mechanism. Upper management should be apprised of the process at each phase. The five phases are:
For each of the four types of systems (developed software systems, purchased software systems, interfaced systems, and other critical systems), the exact steps within the phases will differ, as will the relative amount of the effort taken by each phase.
Each organization must educate their people about what the Y2K problem is and how to deal with it. Many have a hard time believing that something as trivial as a lack of two digits in a date can cause a serious problem.
Inventory, Assessment, and Planning
This phase involves eight steps:
An important part of this step is identifying alternative approaches to be taken, should renovations and validations lag or fail. Your contingency plans should deal not only with internal remediations, but also address the work of vendors and service providers as well as customers and correspondents with whom your operation interfaces. Contingency plans must include critical milestones for measuring progress or critical delivery dates where decisions must be made to pursue an alternative solution if the objective is not met. Contingency plans need to take into account the mission criticality of applications because, in all likelihood as the time-certain deadline approaches, it will become impossible to fully implement all changes for all applications. Contingency plans may even need to recognize that, in some cases, correspondent relationships may need to be altered or customer relations severed. For guidelines and more detailed information, see Contingency Plan Guidelines and the Year 2000 Contingency Plans briefing available from our Briefings, Article, and Events page.
Now you are ready to commence implementing fixes-. Here you must define new and/or revised procedures and accompanying training, brief upper management on changes and revisions so that adjustments can be approved quickly, and use modern techniques to identify needed design changes. You should revisit your Contingency Plans, revise them as appropriate, and start planning your contingencies. Take a look at our Tools and Services Catalog for help in identifying specific tools and/or vendors who can help you with the renovation phase.
Here you test fixes, using an exit criteria checklist. Testing fixes to Y2K problems will require new and expanded procedures compared to our traditional approaches. On top of all this, as mentioned above, systems typically deal with a window of time, a range of dates both before and after the present date, which expands the amount of testing you must do beyond just the arrival of January 1, 2000. You should also begin testing your Operational Contingency Plans to be sure they are doable within your organization's resources. This can be accomplished through either a paper study or a dry run of your plan's activities. In addition, take a look at our Tools and Services Catalog for help in identifying specific tools and/or vendors who can help you with the validation phase.
Here you field fixes, including training end users. You need to identify
training needs, establish a training plan, and start training people to
properly execute your Contingency Plans.While most organizations will
be able to use their traditional methods for fielding new systems and
upgrades for the changes needed for Y2K, there will probably be several
additional issues that impact their traditional approach. The need to
ensure that all changes are implemented on time against a firm, no-slip
deadline, will be new for many organizations. The simultaneous changing
of commercial components, developed components, and procedures will also
be new for many. Finally, for those forced into a change in their interfaces,
the coordination and simultaneous activation of your new release with your interfacing partners will be especially challenging when more than
one interface is changing.
Page last updated: January 27, 1999 | Top of page
Solutions That Make a Difference.®