Executive Summary

Objectives and Scope

Background

Results

conclusion

Appendix I - Detailed Objectives, Scope and Methodology

Appendix II - Major contributors to This Report

Appendix III - Report Distribution List

Appendix IV - cDc conversion Milestones

Appendix V - Management’s Response to the Draft Report

Executive Summary

The task of converting all of the Internal Revenue Service’s (IRS’) computer systems to ensure they work properly in the Year 2000 is immense due to the size and complexity of the IRS’ processing environment. contingency planning needs to be an important part of the IRS’ overall Year 2000 conversion effort because of the risk that some systems may not be Year 2000 compliant when the century date change occurs.

IRS has a process to identify risk areas for contingency planning purposes. Meetings are held weekly to discuss the conversion process and to assess the need for contingency plans. However, improvements are needed to ensure the process provides adequate coverage and is consistently followed.

In addition, because systems that have completed the conversion process may still fail, the IRS needs to complete a comprehensive Year 2000 contingency plan before the century date change. consolidating Year 2000 and non-Year 2000 efforts will make better use of resources and help expedite both processes.

To help ensure that adequate contingency plans are in place by the Year 2000, management should address the following issues.

Although there have been efforts to clean up the conversion data files, records still contain missing, inaccurate, and inconsistent data which may affect the contingency management process. Due to the size of the files, constant updates, and accesses by multiple users, validity checks are needed to minimize errors.

Systems should not be considered satisfactory if components are past due dates or incomplete. A system with overdue or incomplete components, regardless of its overall conversion status, has the risk of not being Year 2000 compliant and may require contingency planning.

• Review and correct Year 2000 inventory files on a recurring basis to ensure information used to identify the need for contingency plans is accurate and complete.
• Establish validity checks for the Year 2000 inventory files.
• Develop procedures to identify, monitor, and contact owners of components or systems that have not completed the 12 milestones for Year 2000 conversion within a reasonable period after the due date.
• Develop procedures to identify "at risk" systems during the certification process.
• Adhere to the formal contingency Request Memorandum process to ensure timely development of contingency procedures.
• Assign responsibility for the IRS’ overall contingency management strategy, including Year 2000, and the coordination of resources to one area.
• consider monitoring the status of contingency planning as part of the IRS’ Year 2000 dashboard report.

Management's Response: Management did not agree with all of our findings or recommendations. Management’s response and our comments related to the response are presented at the end of each report section. Management’s complete response is included as Appendix V.

Objectives and Scope

We initiated this review as part of an overall strategy to assess the IRS’ efforts to ensure all systems function properly at the turn of the century. Audit work was performed during the period March through July 1998.

To complete this review, we obtained information from the Information Systems Division (including the century Date change Project Office), the Northeast Regional Office, Andover Service center, Fresno Service center, Martinsburg computing center, and Tennessee computing center. This review was conducted in accordance with generally accepted government auditing standards.

Our overall objective was to assess the IRS’ Year 2000 contingency planning efforts by determining if the IRS has adequately addressed the risk that all systems may not be converted by the turn of the century or encounter unexpected failures. This review did not include non-information technology and telecommunication contingency planning because the IRS was in the process of developing a contingency planning management method and an inventory tracking method for these areas at the time of our field work.

To achieve our overall objective, we:

• Determined if the century Date change contingency Management Plan covers all mission critical systems and clearly defines stakeholders’ roles and responsibilities for each system.
• Determined if the monitoring process effectively identifies systems at risk of not being Year 2000 compliant.
• Determined if "at risk" systems were properly issued contingency Request Memoranda and whether the responses were adequate.
• Determined if local contingency plans (business resumption plans and disaster recovery plans) have considerations for system failures that can be used in the event of a Year 2000 system failure.

Appendix I contains the detailed objectives, scope and methodology of our review. A listing of major contributors to this report is shown in Appendix II.

Background

The Year 2000 computing crisis is a direct result of software and memory limitations in early computers. To accommodate these limitations, programmers had to create computer code as efficiently as possible. This led to the use of a two-digit representation of the year (e.g., 1998 is represented as 98). Since date fields are used in many critical computer functions, use of a two-digit date will cause many computers and computer applications to malfunction after the century date change.

The Year 2000 problem affects most of the IRS’ operations because of its reliance on computer and telecommunication systems. The IRS has approximately 130,000 personal computers; 1,000 minicomputers; 80 mainframe computers; and 100,000 communication devices. This hardware supports 135 major systems with approximately 94,000 application components containing over 60 million lines of programming code. The IRS also shares computer information with other entities such as state, local, and foreign governments; other Federal agencies; banks; and private corporations. Moreover, items such as security systems, office equipment, and transportation may have microchips, software, and time/date information embedded that use the 2-digit format.

To ensure the Year 2000 challenge is met, the IRS established the century Date change (cDc) Project Office in 1996. The cDc Project Office’s primary goal is to ensure that all current and future systems are Year 2000 compliant prior to January 2000 by scheduling the analysis, upgrading, conversion, testing, certification, and implementation of all systems. The cDc Project Office also has oversight responsibility that includes establishing policies and procedures as well as conversion standards, methodology, and schedules.

The cDc Project Office adopted the National Institute of Standards and Technology (NIST) standard of expanding all 2-digit year fields to 4-digit year fields. To ensure all existing and new applications are compliant with this standard, the cDc Project Office created a 14-step (milestone) conversion process (See Appendix IV).

Because of the complexity of the Year 2000 conversion process, the IRS developed a century Date change contingency Management Plan (cMP) so that systems at risk of not meeting the Year 2000 deadline are identified for contingency planning purposes. The IRS compares the current and planned progress through the first 12 milestones in the Year 2000 conversion process to identify "at risk" systems. A "green" status is used for satisfactory progress. If the variance from the planned progress is more than 5 percent, then the system moves to a "yellow" status. At 15 percent or more variance, the system becomes "red" status and subject to contingency requirements.

Even though the IRS has the cMP in place, the General Accounting Office (GAO) identified contingency planning as a risk area for the IRS’ Year 2000 effort because the cMP requires the development of contingency plans only for those areas at risk of not being converted by the year 2000. The cMP does not address the possibility that a system converted on schedule may still experience a failure.

The IRS recognizes the importance of contingency planning in its own internal procedures. The Internal Revenue Manual requires contingency plans be developed, implemented, tested, and maintained for all critical information systems located at the National Office, regional offices, district offices, service centers, and computing centers.

The IRS’ overall contingency planning effort is critical because the Year 2000 conversion is not the only significant challenge the IRS is currently confronting. The IRS is simultaneously addressing the 1999 tax return processing changes, mainframe consolidation, and the new Integrated Submission and Remittance Processing system.

Results

There are two important elements to the IRS’ Year 2000 contingency planning efforts:

1. A process for identifying systems at risk of not meeting Year 2000 conversion deadlines so that specific contingency plans can be developed.
2. The development of comprehensive contingency plans in case converted systems still experience failures.

Even though the IRS has a process to identify risk areas for contingency planning purposes, improvements are needed to ensure the process is complete and consistently followed.

At the time of our review, the IRS was just beginning the process of developing a comprehensive Year 2000 contingency plan in case converted systems still experience failures. Because these plans need to be in place by the Year 2000, the IRS needs to make better use of expertise gained from non-Year 2000 contingency planning efforts, rather than starting the process all over again.

To strengthen its overall Year 2000 readiness effort and minimize the potential for loss of revenue and increased taxpayer burden, the IRS should take corrective actions on the following issues. The first four issues are presented in the order they affect the identification of conversion problems and development of contingency procedures. The last issue addresses comprehensive contingency planning efforts.

• The computer inventory and monitoring system used for component conversions has missing, inaccurate, and inconsistent data.
• Late and incomplete component conversions are not effectively followed up on.
• The Year 2000 certification process is not monitored to indicate when contingency planning becomes necessary.
• The need for contingency plans is not always identified, evaluated, and monitored.
• Year 2000 and non-Year 2000 contingency planning efforts are not properly coordinated.

The computer Inventory and Monitoring System Used for component conversions Has Missing, Inaccurate, and Inconsistent Data

The cDc Project Office, business owners, and technical owners rely on the Application Program Registry (APR) data files to accurately reflect inventory and conversion progress. This monitoring tool is a key feature to help assure the IRS that its systems are Year 2000 compliant and to activate contingency planning for systems at risk of not meeting the Year 2000 conversion deadline.

Inventory and milestone accomplishments for the IRS’ application and system software are contained on the APR. There are two data files within the APR for inventory and for conversion milestones. We reviewed the May 26, 1998 APR that included approximately 94,000 application components and identified the following missing, inaccurate, and incomplete data:

• We found 64 component names in the conversion status data file that do not correspond to records in the inventory data file. These components do not have identified systems, responsibilities, or contacts.
• We found 42 component names in the inventory data file that do not correspond to records in the conversion status data file. These components do not have a record of planned or actual milestone accomplishments.
• We found 718 components in the conversion status data file that do not indicate whether IRS has committed to retire or convert these components. The weekly progress reports for this period indicated only 124 uncommitted components.
• We found 13,668 components in the conversion status data file that have dispositions that contradict the inventory data file’s lifecycle. It is unknown if these components should be converted or retired.
• We found 637 components in the conversion status and inventory data files that have dispositions and lifecycles that indicate they should be retired. However, the conversion status data file indicates the components have completed the conversion milestones including implementation (milestone 12). It is unknown if these systems should be retired or converted and placed into production.
• We found 551 components in the conversion status data file with milestones completed years before the cDc Project Office was established in 1996. Some notable examples include the dates: 1934 for an Impact Analysis Date (milestone 3); 1985 for a Unit Test Date (milestone 6); 0998 for a SAT Report Date (milestone 11); and 1977 for a Production Transmittal Date (milestone 12).
• We found 4,362 components in the conversion status data file that indicate testing had been performed before code conversion had been completed.
• We found 24,100 components in the conversion status data file that are shown to have been put into production before testing had been completed.

Although there have been efforts to clean up the APR data files, records continue to contain missing, inaccurate, and inconsistent data. If the APR is not accurate, management cannot rely on the data to determine if contingency planning is necessary.

Due to the size of the files, constant updates, and accesses by multiple users, it is difficult to minimize errors without having sufficient validity checks. The current computer validity checks do not prevent the situations we identified.

IRS management should review and correct the data files used to monitor the Year 2000 progress for the situations we reported. This should be a recurring process as the Year 2000 conversion continues and should include:

• Verifying the existence of components and the consistency of recorded information between data files.
• Verifying the accuracy of mandatory fields including disposition, lifecycle, phase and milestones.

Management’s Response: Management states that the cause of inaccurate data was a systemic problem that was corrected in August 1998. Management also states that a sizable portion of the existing inaccurate data has been resolved.

To ensure future computer data used to monitor the Year 2000 progress is accurate and complete, management needs to develop validity checks in the APR data files. These validity checks should include:

• comparing fields within data files for valid, compatible values.
• Matching similar and mandatory fields between data files for valid, compatible values.
• comparing fields within data files for proper sequence of events.

Management’s Response: Management’s assessment of cause states this issue was corrected in August 1998. Their corrective action is to continue to monitor these issues.

Late and Incomplete component conversions Are Not Effectively Followed Up On

The IRS compares the current and planned progress through the first 12 Year 2000 conversion milestones to identify "at risk" systems. These milestones are to be completed in one of five phases with specific deadlines. A "green" status is used for satisfactory progress. If the variance from the planned progress is more than 5 percent, then the system moves to a "yellow" status. At 15 percent or more variance, the system becomes "red" status and subject to contingency requirements.

We reviewed the May 26, 1998 APR for components scheduled for Phase III Year 2000 conversion and identified 511 late and 195 incomplete components. Late components are those that did not complete implementation (milestone 12) until after the phase due date. Incomplete components are those that continue to have one or more missing completion dates for the first 12 milestones.

For the 511 late and 195 incomplete components, we identified the 11 corresponding maintenance organizations and the conversion status as of the Phase III due date. We determined that 181 late and 170 incomplete components that belong to 9 maintenance organizations had "green" conversion status at the time of the phase due date.

Organizations should not be considered satisfactory or "green" if components are past due dates or incomplete. A system with overdue or incomplete components, regardless of its overall conversion status, has the risk of not being Year 2000 compliant and may require contingency planning.

There are weekly reports called the "century Date change Oversight Report," the "Invalid Listing," and the "Phase III Missing Milestone Report." These reports show conversion status and missing milestone dates. We did not find procedures requiring the use of these reports to update and clarify component progress. In addition, there was no requirement to respond to the cDc Project Office as to the actions taken regarding these reports.

Management should develop procedures to identify, monitor, and contact owners of components or systems that have not completed the 12 milestones within a reasonable period after the phase due date. The information reports can identify and communicate between the cDc Project Office and the system owners any overdue and incomplete components. After contacting system owners with incomplete components that still appear to be "at risk," management should have procedures to begin contingency planning.

Management’s Response: Management does not agree with this issue and, accordingly, proposes no corrective action.

The Year 2000 certification Process Is Not Monitored to Indicate When contingency Planning Becomes Necessary

The Year 2000 conversion process has 14 milestones. The last two milestones are for the Year 2000 certification process and include "component-Level certification" and "System-Level certification." The component-Level certification takes place when Product Assurance reviews all documentation and certifies that the converted and tested program is Year 2000 compliant. System-Level certification is accomplished by testing with the system clock set to the year 2000. These milestones comprise the last 15 percent of the conversion process.

Despite the importance of these last two milestones in identifying conversion problems, we found that "at risk" systems failing the Year 2000 certification process may not receive proper consideration for contingency planning.

Procedures are not adequate in the cDc contingency Management Plan or the cDc Project Management Plan for systems that fail or become delayed during the Year 2000 certification process. The September 1997 release and the June 1998 consolidated draft cDc contingency Management Plans do not specifically monitor the certification process to identify "at risk" systems. The cDc Project Management Plan does not indicate the steps to remedy a system that failed or encountered a delay during certification.

The current method of identifying "at risk" systems using a 15 percent variance from planned progress will not work for the certification process. A system would be identified as "at risk" only when the deadline had been reached and no testing had been completed or the system had failed during the tests.

Develop procedures to identify "at risk" systems during the Year 2000 certification process before deadlines have been reached. This includes steps to remedy a system that failed or encountered a delay during either component-Level certification or System-Level certification.

Management’s Response: Management indicates disagreement with this audit recommendation and states that a contractor’s 100 percent programming code review and the end-to-end testing process already identify "at risk" systems during the certification process.

The Need for contingency Plans Is Not Always Identified, Evaluated, and Monitored

According to IRS procedures, the cDc Project Office should issue contingency Request Memoranda to business and technical owners when systems that should be 60 percent complete are less than 45 percent complete. When this occurs, business and technical owners are supposed to provide a response to the cDc Project Office within 30 days. The response should contain a contingency plan alternative, resources required for implementation, impact on ongoing conversion efforts, and contingency plan milestones. If a contingency plan is required, the technical owner is requested to submit a progress report to the cDc Project Office every two weeks.

As discussed previously, the cDc Project Office may not be identifying all "at risk" systems due to inaccurate computer data, lack of monitoring after due dates, and lack of monitoring during certification. In addition, the cDc Project Office does not effectively address "at risk" systems when the current process does identify these situations.

During the period October 1, 1997 to June 20, 1998, we identified 10 situations that required contingency Request Memoranda. After reviewing these situations, we determined all 10 contained some form of issuance, response, evaluation, or monitoring deficiency.

The cDc Project Office did not:

• Identify one "at risk" system and therefore did not issue a contingency Request Memorandum.
• Issue two contingency Request Memoranda when "at risk" systems were initially identified. After being identified "at risk" a second time, these systems were finally issued contingency Request Memoranda.
• Issue four contingency Request Memoranda to "at risk" systems. The cDc Project Office and system owners took informal actions when formal notification, response, and monitoring should have taken place.
• Receive one contingency Request Memorandum response. As of July 22, 1998, the response was 67 days overdue.
• Timely evaluate one contingency Request Memorandum response to assess the risk and to determine contingency milestones that would require monitoring. The system owners were not contacted regarding deficiencies in the response for 68 days.
• Properly monitor one contingency Request Memorandum response for progress reports that update the contingency plan risk status.

The cDc Project Office established formal procedures for issuing and responding to contingency Request Memoranda. These procedures are not consistently followed. Not following controls designed to place "at risk" systems on notice can reduce the system owner’s accountability and adversely affect monitoring by the cDc Project Office.

The cDc Project Office can not totally rely on its future automation to accomplish its contingency oversight responsibilities. Although future automation of contingency Request Memoranda should help with the identification of "at risk" systems, it will not help with the evaluation and monitoring of the responses. The cDc Project Office should ensure the formal process is followed using manual or automated means, and that they adequately follow up by evaluating and monitoring documented responses.

Management should adhere to the formal contingency Request Memorandum process to ensure timely development of contingency procedures. This process includes accurately documenting the identification, agreements, and monitoring milestone accomplishments by the "at risk" system owners and the cDc Project Office.

Management’s Response: Management implemented a process as of October 1, 1998 that includes evaluation of both the need to issue and the suspension of action for a contingency Request Memorandum. Management also states that other steps have been taken to document the progress and to follow up on delinquent action.

Year 2000 and Non-Year 2000 contingency Planning Efforts Are Not Properly coordinated

As discussed above, the IRS has a process in place to initiate contingency planning for systems at risk of not completing the Year 2000 conversion process on time. However, there is also a need for a more comprehensive plan in case systems that have completed the conversion process still experience failures in the Year 2000.

The IRS has recently devoted considerable effort to the development of non-Year 2000 contingency plans for the computing centers, service centers, regions and districts. These plans are known as Disaster Recovery and comprehensive Business Resumption plans. Although the possibility of Year 2000 failures is widely known, none of the functions responsible for these plans included methods for dealing with Year 2000 failures. The recovery strategy of the non-Year 2000 plans is to establish operations at an alternate site using data back-up files. In most cases, this would provide no benefit in a Year 2000 related failure.

In a recent review, GAO outlined steps that the IRS needs to take to develop a comprehensive Year 2000 contingency plan, including the following:

1. "Identify IRS core business processes and prioritize those processes that must continue in the event of Year 2000 failures."
2. "Map IRS mission critical systems to core business processes."
3. "Determine the impact of information systems failures on each core process."
4. "Develop and test contingency plans for core business processes if existing plans are not appropriate."

The IRS is currently taking additional steps to establish comprehensive contingency plans for core business processes in case of Year 2000 failures. The initial meeting to start this effort and begin defining core business processes took place on July 29, 1998. The cDc Project Office has responsibility for this process with the assistance of a Year 2000 vendor.

However, starting the entire contingency planning process all over again for potential Year 2000 failures will lead to inefficient use of the IRS’ resources. It draws on cDc Project Office resources needed for the Year 2000 conversion and testing efforts as well as vendor resources rather than resources already assigned to contingency planning. Areas responsible for non-Year 2000 contingency planning include the Office of Security, Systems, and Evaluation, the Executive Officer for Service center Operations, the Northeast Regional commissioner's Office, and the computing center Directors. Disaster Recovery analysts also support this effort.

Many of the steps needed must be taken regardless of whether the contingency planning is for Year 2000 or non-Year 2000 failures. Inadequate coordination will cause delays in developing comprehensive Year 2000 contingency plans and increase the risk that adequate plans will not be in place by the Year 2000.

Additionally, since the entire process will only be of benefit if completed before the Year 2000, the IRS should develop target milestones and monitor the contingency planning process to ensure milestones are completed timely.

Management should consolidate oversight responsibility for the IRS’ overall contingency management strategy and the coordination of resources into one area. This responsibility would include both Year 2000 and non-Year 2000 contingency planning, as well as coordinating with internal resources and vendors. coordination for this effort should be assigned at a high enough level to oversee all contingency planning resources.

Management’s Response: Management did not agree with our recommendation because the time-critical nature of being ready for the Year 2000 does not allow enough time to establish a centralized IRS office to manage Servicewide contingency planning. However, management states that it did develop a core business process that has been mapped to mission critical systems with guidance to develop failure scenario matrices. In addition, a century Date change Business continuity and contingency Plan was published in November 1998 to provide business owners’ assessments of areas that impact the IRS mission if supporting systems failed for Year 2000 reasons. Management states that the need for contingency plans will be established based on these assessments and other Year 2000 risk factors.

Management should consider monitoring the status of contingency planning as part of the IRS’ Year 2000 dashboard report. The dashboard report was established to help high level management monitor the progress of critical Year 2000 projects and areas. This monitoring should follow the key steps in the development and testing of these contingency plans to ensure they are appropriate for Year 2000 failures.

Management’s Response: The cDc Project Office included contingency planning as an element in its weekly status reports and meetings staring in November 1998. contingency planning will also be included in the Executive Steering committee dashboard starting with the January meeting.

conclusion

The Year 2000 problem is complicated by the size, complexity, and interdependencies of the IRS’ computer systems. In addition, the consequences of system failures and the absolute deadline make it a critical task for an organization as large and as reliant on computers as the IRS.

Because of the enormity of the task, systems may not all be converted in time due to resource constraints or other problems. Although the IRS has a process to identify risk areas for contingency planning purposes, improvements are needed to ensure the process provides adequate coverage and is consistently followed.

In addition, because systems that have completed the conversion process may still fail, the IRS needs to complete a comprehensive Year 2000 contingency plan before the century date change. consolidating Year 2000 and non-Year 2000 efforts will make better use of resources and help expedite both processes.

Detailed Objectives, Scope and Methodology

This review assessed the IRS’ Year 2000 contingency planning efforts by determining if the IRS has adequately addressed the probability that all systems may not be converted by the turn of the century or systems may encounter unexpected failures. Specifically, we:

1. Determined if the cDc contingency Management Plan covers all types of mission critical systems and clearly defines stakeholders’ roles and responsibilities for each type of system. As needed, we conducted discussions with the cDc Project Office and other stakeholders to clarify obtained information.
1. Obtained IRS’ requirements, other government requirements, and acceptable managerial practices for contingency plans.
2. Reviewed the cDc contingency Management Plan to identify its intended purpose and scope. In addition, we reviewed the plan to identify stakeholders’ roles and responsibilities.
3. Identified any type of mission critical systems discussed in the cDc Project Management Plan that are not covered in the cDc contingency Management Plan. For mission critical systems not covered, we obtained and reviewed any final or draft contingency management plans that would cover these systems and determined if these plans can be incorporated into one IRS-wide contingency management plan.
4. Identified any stakeholders’ roles and responsibilities discussed in the cDc Project Management Plan that are not covered in the cDc contingency Management Plan. Also, we ensured all stakeholders have been identified and their roles and responsibilities are appropriate for the type of system structure.
2. Determined the effectiveness of the cDc Project Office’s monitoring process to identify "at risk" systems of not being Year 2000 compliant. As needed, we conducted discussions with the cDc Project Office and other stakeholders to clarify the monitoring process.
1. Reviewed the cDc contingency Management Plan for the monitoring process used to identify "at risk" systems of not being Year 2000 compliant.
2. Identified mission critical systems that are not included in the monitoring process as described in the cDc contingency Management Plan. For those identified, we determined if there is an alternative process to monitor these systems.
3. Determined the reliability of using INOMS to monitor systems by reviewing prior and current projects conducted by Internal Audit and outside vendors. In addition, we reviewed the APR INOMS data files "convstatus" and "component" for missing, inaccurate, and incomplete data.
4. Tested the methodology of how systems are determined to be "at risk". This included reviewing historic data to determine if monitoring continues after target due dates have passed and if monitoring is adequate for systems attempting component certification (milestones 13 & 14).
3. Determined if systems identified as at risk of not being Year 2000 compliant were properly issued a contingency Request Memorandum and provided a proper response. As needed, we conducted discussions with the cDc Project Office and other stakeholders to clarify obtained information.
1. Reviewed the cDc contingency Management Plan to identify procedures for issuance and receipt of contingency Request Memoranda.
2. Obtained IRS requirements and acceptable managerial practices for proper issuance and response.
3. Obtained and reviewed all issued contingency Request Memoranda to determine the effectiveness of the cDc Project Office to notify and monitor "at risk" projects.
4. Determined if local operational contingency plans (includes business resumption plans and disaster recovery plans) have considerations for system failures that can be used in the event of a Year 2000 system failure. As needed, we conducted discussions with the cDc Project Office and other stakeholders to clarify information.
1. Obtained IRS’ requirements, other government requirements, and acceptable managerial practices for contingency plans that cover system failures.
2. Reviewed the comprehensive Business Resumption Plan and the Disaster Recovery Plan that were designed for service centers to determine their scope and whether they contain adequate and consistent provisions to minimize and correct a Year 2000 system failure.
3. Reviewed and discussed business resumption plans and disaster recovery plans for districts, computing centers, distribution centers, and compliance centers.
4. Discussed communication between the cDc Project Office and the developers of business resumption plans and the disaster recovery plans to determine if resources are effectively utilized to accomplish contingency planning.

Major contributors to This Report

Stephen Mullins, Regional Inspector General for Audit

Scott Macfarlane, Deputy Regional Inspector General for Audit

Edward Neuwirth, Acting Deputy Regional Inspector General for Audit

Michael McKenney, Audit Manager

Aaron Foote, Senior Auditor

Mark Judson, Auditor

Joe Smith, Auditor

carla Steiger, Auditor

Louis Zullo, Auditor

Michael Phillips, Acting Director, Office of Audit Projects

Vincent Dell’Orto, Audit Manager

Kim Woodard, Auditor

Report Distribution List

Deputy commissioner for Modernization c:DM

Deputy commissioner for Operations c:DO

chief Information Officer IS

Deputy chief Information Officer, Systems Development IS

Deputy chief Information Officer, Operations IS

Director, Year 2000 Project IS:cD

Director, Office of Systems, Standards & Evaluation IS:E

Director, Office of Information Resources Management IS:IR

chief Operations Officer OP

chief, Management and Finance M

National Director for Legislative Affairs cL:LA

Office of Management control M:cFO:A:M

Audit Liaisons

cDc conversion Milestones

The percentage of milestone conversion completed by tier and phase equals the count of completed components divided by the count of committed components multiplied by the points for the milestone. For example, the calculation would be (35/100)*10 for 100 committed components with 35 completed components for the Impact Analysis Report milestone. This is 3.5 or 0.035 percent completed for conversion.

After each milestone is calculated, the individual percentages are summed to create a total conversion percentage for the tier and phase. This total conversion percentage is compared to the percent of time that has elapsed for the phase. A "green" or satisfactory status is when the variance is less than or equal to 5 percent. A "yellow" or an at risk status is when the variance is greater than 5 and less than 15 percent. A "red" or an at great risk status is when the variance is greater than 15 percent.

Management’s Response to the Draft Report

Management's Response has been removed due to its size. To see the complete Response, please go to the Adobe PDF version of this report.