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.

THE COMPLIANCE PROCESS

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:

• Awareness
• Inventory, assessment, and planning
• Renovation
• Validation
• Fielding

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.

Awareness

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:

1. Scope the problem and lay out a high-level plan of activities. Centrally disseminate a common definition of types of problems being addressed and the goals of the Y2K effort, including exit criteria. Identify the Y2K failure, risks and mitigation approaches, and involve upper management in triage review. Current project management tools and techniques are indispensable. See what others in industry and Government are doing about the problem. Take a look at our Other Links for Year 2000 and our cost estimate data to help you.



2. Inventory all systems and system components, including Embedded Systems. Go beyond MIS systems to identify all systems at risk. Many organizations initially focus on their production information systems without considering the support and maintenance infrastructure and the other systems in the organization that are sensitive to dates like the phone and power systems, chips, heat and light management systems, and so on. For more information on different types of systems to inventory, please see Possible Systems At Risk. Do a high-level inventory of potentially affected code. First take a look at our Tools and Services Catalog for help in identifying specific tools and/or vendors who can help you with the inventory process.



3. Make a ROM estimate of cost. Use source lines of code totals for developed systems multiplied by industry cost factors to generate a quick estimate.



4. Refine the plan and develop contingency plans. Identify priorities, using disaster recovery plans to identify critical systems. Rewrite disaster recovery plans to reflect the Y2K problem and include safety consequences and secondary effects.


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.


5. Conduct a detailed assessment of the portfolio, using a consistent definition of Y2K problems. For developed systems, use available tools. For purchased, interfacing, and other critical systems, use a compliance questionnaire to interview the owners of the systems. The questionnaire is focused on establishing the types of issues that are, or are not, addressed by the other party. Once you understand this, you can gauge the risk this poses to your systems and then decide whether you want to negotiate a fix or a replacement. See what vendors of components, hardware and software, of all your platforms are going to do about the problem. Review the status of your support contracts with them. See our DISA COTS Product Compliance Catalog, as well as our COTS Considerations page for more information. For more detailed discussions of compliance issues including GSA's warranty language and GTE's compliance verification criteria, please see our Compliance Information page.



6. Identify potential solutions and their costs in dollars, schedule, and ripple effects. Select solution approaches for each type and mix of systems, balance against constraints, and generate a real cost estimate on the basis of the technical findings of the assessment and the proposed solutions. Ask yourself: How many systems are affected and need to be synchronously fixed, tested, and fielded? What?s the cost of change?in terms of effort, storage, licenses, bridges, testing, and deferred capabilities? How quickly can the solution be implemented? What?s the span of time your systems work with? (Systems using the US government?s fiscal year will encounter the Y2K problem in October of 1999.) What?s the cost of not changing, in terms of liabilities, malfunctions, and errors?



7. Refine the plan and get upper management approval of plan and its schedule and cost estimates.



8. Make a full system backup of everything

Renovation

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.

Validation

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.

Fielding

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.