Testimony Before the Subcommittee on Social Security
of the House Committee on Ways and Means
Hearing on Year 2000 (Y2K) and Other
Social Security Information Technology Issues
July 29, 1999
Mr. Chairman and Members of the Committee:
We are pleased to be here today to discuss the Social Security Administration's (SSA) progress in implementing key information technology initiatives critical to its ability to effectively serve the public. Achieving Year 2000 (Y2K) readiness is SSA's top information technology priority. Consistent with our prior reports(1) , SSA continues to make excellent progress on Y2K and has taken important steps to implement our recommendations for mitigating risks. Further, it has initiated a number of governmentwide best practices to help ensure its preparedness for the change of century. Nonetheless, SSA's work is not yet complete; certain tasks integral to ensuring its overall readiness for the year 2000 must still be accomplished.
Another major focus of SSA's information technology activities is implementation of its Intelligent Workstation/Local Area Network (IWS/LAN), which SSA expects will provide the agency with the basic automation infrastructure to support redesigned work processes and improve its service delivery. SSA continues to implement IWS/LAN and reports that it has now installed intelligent workstations and LANs in most of the approximately 2,000 SSA and state Disability Determination Service (DDS) sites included in the initiative. However, it has not yet implemented key processes that are essential to measuring the benefits derived from this investment.
The third initiative that I will discuss today is SSA's development of its Reengineered Disability System (RDS). RDS was intended to support SSA's modernized disability claims process and was to be the first major programmatic software application to operate on IWS/LAN. However, SSA experienced numerous problems and delays in developing this software. Based on a contractor's recent assessment of the initiative, SSA has now decided to terminate the original RDS strategy after 7 years of effort and about $71 million in reported costs. SSA now plans to proceed with a new strategy to address the needs of its disability determination process.
YEAR 2000: CONTINUING PROGRESS, BUT CRITICAL TASKS REMAIN
SSA first recognized the potential impact of the Y2K problem in 1989, and in so doing, was able to launch an early response to this challenge. SSA initiated early awareness activities and made significant progress in assessing and renovating mission-critical mainframe software that enables it to provide Social Security benefits and other assistance to the public. Because of the knowledge and experience gained through its Y2K efforts, SSA has been a recognized federal leader in addressing this issue.
Despite its accomplishments, however, our 1997 report on SSA's Y2K program identified, and recommended actions for addressing three key risk areas:(2)
SSA agreed with all of our recommendations and efforts to implement them have either been taken or are underway. Regarding state DDSs, SSA enhanced its monitoring and oversight by establishing a full-time project team, designating project managers and coordinators, and requesting biweekly status reports. It also obtained from each DDS a plan identifying the specific milestones, resources, and schedules for completing Y2K conversion tasks. In its most recent (May 1999) quarterly report to OMB, SSA stated that all DDS claims processing software had been renovated, tested, implemented, and certified Y2K compliant by January 31, 1999.
To address data exchanges, SSA identified all of its external data exchanges and coordinated with all of its partners on the schedule and format for making exchanges Y2K compliant. As of June 27, 1999, according to the agency, over 99 percent of SSA's 1,954 reported external data exchanges had been made compliant.
Among SSA's most critical data exchanges are those with the Department of the Treasury's Financial Management Service (FMS) and the Federal Reserve System for the disbursement of Title II (Old Age, Survivors, and Disability Insurance program) and Title XVI (Supplemental Security Income program) benefits checks and direct deposit payments. SSA began working with FMS in March 1998 to ensure the compliance of these exchanges, and reported earlier this year that the joint testing of check payment files and testing from SSA through FMS and the Federal Reserve for direct deposit payments had been successfully completed. Further, SSA stated, it began generating and issuing Title II and Title XVI benefits payments using the Y2K compliant software at SSA and FMS in October 1998.
Regarding its contingency planning, SSA has instituted a number of key elements, in accordance with our business continuity and contingency planning guidance.(3) In addition to developing its overall strategy for Y2K business continuity, SSA has completed local contingency plans to support its core business operations and has received contingency plans for all state DDSs. Also included among its plans is SSA's Benefits Payment Delivery Y2K Contingency Plan, developed in conjunction with Treasury and the Federal Reserve to ensure the continuation of operations supporting Title II and Title XVI benefits payments.
Another key element of business continuity and contingency planning, as noted in our guide, is the development of a zero-day or day-one risk reduction strategy, and procedures for the period between late December 1999 and early January 2000. SSA, as a recognized leader in addressing Y2K contingency planning issues, has developed such a strategy. For example, the agency plans for select SSA and DDS sites to process late December 1999 data during the first 2 days of January 2000 as a means of testing the accuracy of the systems prior to the start of business on Monday, January 3. Other features of the strategy include implementation of (1) an integrated control center with responsibility for the internal dissemination of critical data and problem management, (2) a timeline detailing the hours during which certain events will occur (such as when workloads will be placed in the queue and backup generators started) during this rollover period, and (3) a personnel strategy and leave policy which includes commitments from key staff to be available during the rollover period. Such a strategy should help SSA manage the risks associated with the actual rollover and better position it to address any disruptions that occur.
SSA has taken other vital steps to help ensure its preparedness for the year 2000. For example, it has used a Y2K test facility to test operating systems, vendor products, and mission-critical systems. SSA's test and certification procedures included (1) baseline testing to establish current-year data for comparison, (2) forward year testing of applications with business and systems dates set in 2000 and beyond, (3) comparisons of aged baseline results with forward year test results, (4) forward date integration testing of entire business functions (i.e., all interrelated applications), and (5) independent reviews of test outputs to certify Y2K compliance.
To ensure the delivery of benefits payments, SSA worked jointly with FMS and the Federal Reserve to test the transfer of approximately 7,500 electronic payments from Treasury to the Richmond, Virginia Federal Reserve Board through the Automated Clearing House network. SSA reported that it began generating and issuing Title II and Title XVI benefits payments using the compliant software at SSA and FMS in October 1998.
SSA Implemented a Y2K Change Management Process
To further reduce the risk of disruptions, in the fall of 1998 SSA instituted a Y2K change management process. We previously testified that this effort represented a best practice governmentwide that should be adopted by other agencies.(4) SSA's process is comprised of three key components: (1) a quality assurance process, (2) Y2K system re-certifications, and (3) a moratorium on discretionary software modifications.
A key feature of SSA's quality assurance process is its use of a validation tool to assess the quality of its previously renovated mission-critical applications. SSA began piloting the tool in November 1998 and expanded its use full-scale in December. The tool searches application programs to identify any date field or date logic that may fail as a result of any inadvertent modifications.
The second key component of SSA's change management process involves its plans to re-certify previously renovated applications where date errors had been identified and Y2K compliant software was then modified. The re-certification process includes performing forward date testing of the modified software and re-evaluating the software using the quality assurance validation tool. In addition, business function experts perform independent reviews of all test outputs before re-certifying the software's compliance.
Also, SSA plans to enforce a moratorium on discretionary software changes between September 1, 1999, and March 31, 2000. This moratorium is intended to help mitigate the risks associated with changing its certified systems by reducing the number of software modifications made. In those instances in which software changes are necessary--such as when compliant software must be modified due to legal or other agency requirements--SSA plans to re-certify the software's compliance. Examples of software that will be modified include applications impacted by Title II benefits rate increases and Title XVI cost-of-living adjustments that are to take effect in November, and certain cyclical software modifications that are to occur after September.
SSA Still Needs to Complete Critical Tasks To Ensure Year 2000 Readiness
While SSA has been a Y2K leader, it must still complete several critical tasks to ensure its readiness for the year 2000. These tasks include:
SSA reported as of mid-July that six of its external data exchanges were still in the process of being made Y2K compliant. In each instance, these include files that have been addressed by SSA but which need further action on the part of SSA's business partners to achieve Y2K compliance. For example, SSA transmits one file on cost-of-living adjustments to the Department of Veterans Affairs (VA). While SSA has made the file compliant, VA must still complete its testing in order to receive the file in a Y2K compliant format. VA is scheduled to complete its testing in August. In addition, SSA is waiting to verify the successful transmission of three compliant files from Treasury regarding information on tax refund actions. SSA expects to verify the compliance of the Treasury files during the first week of August. SSA also still needs to verify the successful transmission of two Massachusetts death data files. SSA expects to complete this activity by the end of this week.
Completing tasks in its contingency plans and coordinating with its own staff and its business partners to ensure the timely functioning of its core business operations is likewise critical. This includes coordinating with its benefit delivery partners on contingency actions for ensuring timely benefits payments. For example, SSA plans to assist Treasury in developing alternative disbursement processes for problematic financial institutions. SSA is also now in the process of testing all of its contingency plans, with expected completion in September. In addition, SSA must implement its day-one strategy, comprising actions to be executed during the last days of 1999 and the first few days of 2000.
SSA also has one remaining mission-critical stand-alone system--the Integrated Image-Based Data Capture System--which must still be certified as Y2K compliant. This system is used to scan and convert W-2 forms to electronic format for entry into the Annual Wage Reporting System. According to officials in SSA's Office of Systems, the SSA-developed application software has been renovated, tested, and implemented into production; however, SSA cannot certify the system's compliance until it has completed testing of the system's upgraded commercial off-the-shelf software used for tracking W-2 form data from the point of receipt to image scanning. This testing is not scheduled to conclude until late August.
The installation of software and hardware upgrades in SSA's Office of Telecommunications and Systems Operations must also be completed. For example, SSA must install Internet browser patches for the IWS/LAN software by August.
Finally, SSA must correct a number of date-field errors recently identified using its QA tool. SSA reported that as of July 23, 1999, it had assessed 92 percent (283 of 308) of its mission-critical applications (having a total of about 40 million lines of code),(5) and that it had identified 1,565 date field errors. SSA is in the process of correcting these identified date problems. As of mid-July, it reported that 44 of the 283 applications had been corrected, recertified, and returned to production. SSA plans to correct, recertify, and implement all of its remaining applications by November, when it is scheduled to modify some mission-critical applications to reflect Title II benefit rate increases and Title XVI cost-of-living adjustments.
IWS/LAN: INSTALLATIONS CONTINUE BUT CONTRIBUTIONS TO IMPROVED MISSION PERFORMANCE REMAIN UNCLEAR
The second major information technology initiative that I will discuss today is SSA's IWS/LAN modernization effort. SSA expects IWS/LAN to play a critical role by providing the basic automation infrastructure to support redesigned work processes and to improve the availability and timeliness of information. Under this initiative, SSA planned to replace approximately 40,000 "dumb" terminals(6) and other computer equipment used in about 2000 SSA and state DDS sites with an infrastructure consisting of networks of intelligent workstations connected to each other and to SSA's mainframe computers.
The resources that SSA plans to invest in acquiring IWS/LAN are enormous. The first phase of the planned project that started in 1996, was to be a 7-year, approximately $1 billion effort to acquire, install, and maintain 56,500 intelligent workstations and 1,742 local area networks, 2,567 notebook computers, systems furniture, and other peripheral devices. (7)
The basic intelligent workstation that SSA planned to procure included a 100-megahertz Pentium personal computer with 32 megabytes of random access memory and a 1.2-gigabyte hard (fixed) disk drive. We reported in 1998,(8) however, that the IWS/LAN contractor--Unisys Corporation--had raised concerns about the availability of the intelligent workstations being acquired, noting that the 100-megahertz workstations specified in the contract were increasingly difficult to obtain. At that time, SSA's Deputy Commissioner for Systems did not believe it was necessary to upgrade to a faster processor because the 100-megahertz workstation met the agency's needs.
Over the past year, SSA has continued its aggressive implementation of IWS/LAN. The agency reported as of mid-July 1999, that it had completed the installation of 70,518 workstations and 1,742 LANs at 1,565 SSA sites and 177 DDS sites. As the agency has proceeded with the initiative, however, it has revised its requirements several times based on the need for additional workstations. Specifically, between June 1998 and April 1999, SSA modified its contract with the Unisys Corporation three times to purchase additional workstations and related hardware. These modifications increased from 56,500 to 70,624, the total number of intelligent workstations acquired under the Unisys contract.(9)
In addition, because Unisys faced difficulty in obtaining the 100-megahertz workstations specified in the initial contract, the additional workstations acquired through the modifications were configured with processor speeds ranging from 266 megahertz to 350 megahertz.
According to SSA officials overseeing the initiative, SSA's initial estimates of its IWS/LAN requirements had not fully considered the needs of all SSA and state DDS sites. As a result, additional workstations were necessary to (1) ensure Y2K hardware compliance at all DDS sites, (2) complete installations in some of SSA's larger sites, and (3) support training needs. SSA reported that the contract modifications cost about $32 million and that it had completed the installations of all but 106 workstations acquired via the modifications by July 11, 1999.(10)
Beyond these modifications, however, SSA has continued to increase its requirements and is currently in the process of acquiring additional workstations to support the national IWS/LAN initiative. In particular, SSA's Office of Systems concluded during fiscal year 1999 that the workstations acquired via the Unisys contract and its subsequent modifications were not sufficient to fulfill the IWS/LAN requirements of all SSA and DDS sites. As a result, the Chief Information Officer (CIO), in November 1998, approved a request for a $45 million, 5-year follow-on contract to acquire, install, and maintain at least 6,900 additional workstations and about 275 additional LANs.
According to a Systems official, the intelligent workstation that SSA has specified for the follow-on contract is, at a minimum, a 333-megahertz Pentium II processor with 64 megabytes of random access memory and a 4-gigabyte hard (fixed) disk drive. SSA is currently evaluating vendors' proposals and expects to award the contract by the end of July.
Although the CIO approved the Unisys contract modifications and the follow-on contract, SSA's Deputy Commissioner for Finance, Assessment and Management had previously expressed concerns about SSA's need for the additional workstations and their expected benefits. In particular, in letters to the CIO in November 1998 and April 1999, the Deputy Commissioner recommended that the CIO approve the additional workstations from Unisys and the follow-on contract award on the condition that SSA would, respectively, (1) reassess the total number of work year savings for IWS/LAN and (2) reconcile the number of workstations against staffing levels. The CIO agreed to these conditions and requested that relevant agency components determine the reasons for the additional workstations and identify the benefits expected to be achieved from them. Although this effort has been ongoing for about 8 months, as of July 22, the study had not been finalized.
IWS/LAN's Actual Contribution To Improved Productivity and Mission Performance Remains Unclear
Last June we expressed concern that SSA lacked target goals and a defined process for measuring IWS/LAN performance--essential to determining whether its investment in IWS/LAN was yielding expected improvements in service to the public.(11) According to the Clinger-Cohen Act and OMB guidance, effective technology investment decision-making requires that processes be implemented and data collected to ensure that (1) project proposals are funded on the basis of management evaluations of costs, risks, and expected benefits to mission performance and (2) once funded, projects are controlled by examining costs, the development schedule, and actual versus expected results. We therefore recommended that SSA establish a formal oversight process for measuring the actual performance of IWS/LAN, including identifying the impact that each phase of this initiative has on mission performance and conducting post-implementation reviews of the project.
Although SSA agreed with the need for performance goals and measures, its Information Technology Systems Review Staff had neither completed nor established plans for performing in-process reviews of IWS/LAN to (1) compare the estimated cost levels to actual cost data, (2) compare the estimated and actual schedules, (3) compare expected and actual benefits realized, and (4) assess risks. In addition, while the Clinger-Cohen Act and OMB guidelines call for post-implementation evaluations to determine the actual project cost, benefits, risks, and returns, SSA has not scheduled a post-implementation review to validate the IWS/LAN phase I projected savings and to apply lessons learned to make other information technology investment decisions. According to the Director of the Information Technology Systems Review Staff, the agency has no plans to perform either in-process or post-implementation reviews unless problems are identified that warrant such an effort.
As expressed in our earlier report, it is essential that SSA conduct in-process and post-implementation reviews for the IWS/LAN initiative. Since 1994, we have expressed concerns regarding SSA's need to measure the actual benefits achieved from its implementation.(12) Moreover, as the agency continues to expand IWS/LAN via its follow-on workstation acquisitions, it is critical for the agency to know how well it has achieved the savings projected in its initial assessments supporting this initiative. Without such reviews, the agency will be unable to make informed decisions concerning (1) whether it should continue, modify, or terminate its investment in a particular initiative, or (2) how it can improve and refine its information technology investment decision-making process.
SSA Will Need to Continue to Address DDS Network Management Concerns
Our 1998 report also noted concerns among state DDSs about the loss of network management and control over IWS/LAN operations in their offices and dissatisfaction with the service and technical support received from the IWS/LAN contractor.(13) Accordingly, we recommended that SSA work closely with the DDSs to identify and resolve the network management concerns.
SSA has worked with the DDSs to address these issues. For example, it is providing additional servers to give the DDSs certain administrative rights capabilities, such as access to specific login scripts and full control over DDS applications. SSA has also worked with the DDSs to streamline the maintenance process and establish agreements that would allow the DDSs to perform their own IWS/LAN maintenance. Under such agreements, according to SSA, states could rely on their in-house technical staff--rather than the services of the IWS/LAN contractor, Unisys Corporation--to address maintenance problems. At the conclusion of our review, SSA had entered into a maintenance agreement with one state DDS--Wisconsin--and was considering the requests of four other DDSs.
Other issues also continue to concern the DDSs. For example, representatives of the National Council of Disability Determination Directors, which represents the state DDSs, stated that they remain concerned about SSA's attempts to implement a standard print solution. In addition, they stated that SSA has not ensured that the workstations implemented adhere to a standard configuration that provides all DDS system administrators with the same rights. SSA has acknowledged these issues and plans to work with the states to address them.
RDS: DEVELOPMENT PROBLEMS HAVE LED SSA TO DISCONTINUE THE INITIATIVE
SSA's work toward developing RDS has been ongoing for many years. The initiative began in 1992 as the Modernized Disability System and was redesignated as RDS in 1994 to coincide with the agency's efforts to reengineer the disability claims process. As shown in Figure 1, SSA had planned to implement the RDS software starting November 1996 and to complete the national roll-out by May 2001.
Figure 1: Planned RDS Roll-out Schedule
When completed, RDS was to be the first major programmatic software application to operate on SSA's IWS/LAN infrastructure and be part of the enabling platform for SSA's modernized disability claims process. Specifically, RDS was to automate the Title II and Title XVI disability claims processes--from the initial claims-taking in the field office to the gathering and evaluation of medical evidence in the state DDSs, to payment execution in the field office or processing center, and include the handling of appeals in hearing offices. SSA anticipated that this automation would contribute to increased productivity, decreased disability claims processing times, and more consistent and uniform disability decisions. However, after approximately 7 years and more than $71 million(14) reportedly spent on the initiative, SSA has not succeeded in developing RDS and no longer plans to continue the effort.
As Figure 2 shows, between 1993 and 1999, SSA took various steps toward developing the RDS software.
Figure 2: Actual RDS Roll-out Schedule
However, even in its earliest stages, this effort proved problematic and was plagued with delays. For example, in September 1996, we reported that software development problems had delayed the scheduled implementation of RDS by more than 2 years.(15)
An assessment of the development effort revealed a number of factors as having contributed to that delay, including (1) using programmers with insufficient experience, (2) using software development tools that did not perform effectively, and (3) establishing initial software development schedules that were too optimistic.
SSA proceeded with the initiative, nonetheless, and in August 1997, began pilot testing the first release of the RDS software in its Alexandria, Virginia field office and the federal DDS(16) for the specific purposes of (1) assessing the performance, cost, and benefits of the software and (2) determining IWS/LAN phase II equipment requirements. However, as we previously reported, SSA encountered performance problems during the pilot tests.(17) For example, Systems officials stated that, using RDS, the reported productivity of claims representatives in the SSA field office dropped due to the system's slow response time. Specifically, the officials stated that before the installation of RDS, each field office claims representative processed approximately 5 case interviews per day. After RDS was installed, each claims representative could process only about 3 cases per day.
In response to the RDS performance problems, SSA delayed its plans for expanding the pilot to other offices and in March 1998, contracted with Booz-Allen and Hamilton to independently evaluate and recommend options for proceeding with the initiative. According to the statement of work, Booz-Allen and Hamilton was tasked to provide SSA with a comparative cost, benefit, risk, and schedule assessment for RDS, and to propose alternative strategies for achieving its underlying objectives. The contractor was originally scheduled to deliver its report to SSA in September 1998, at which time SSA planned to select an option for proceeding to achieve objectives intended for the initiative. However, SSA later extended this milestone, with the draft report being delivered in February 1999. The agency subsequently required the contractor to address additional comments and concerns put forth by SSA, resulting in additional delays. SSA provided the report to us on July 26.
According to the Booz-Allen and Hamilton report, the RDS software had defects that would diminish the current case-processing rate at DDS sites. In addition, SSA had not been timely in addressing the software defects. For example, 90 software problems identified by SSA staff remained unresolved after more than 120 days. As a result, the Booz-Allen and Hamilton report recommended that SSA discontinue the RDS initiative and focus on an alternative solution involving the use of an electronic folder to replace the paper-based case folder in the disability determination process. Further, to reduce development risks, the contractor recommended that the electronic folder project be segmented into manageable sections.
SSA Plans to Launch a New Initiative
Based on the assessment it received from Booz-Allen and Hamilton, SSA has discontinued the development of RDS and has begun to pursue a new strategy for addressing the needs of its disability determination process. According to the RDS project manager, the strategy that SSA is now considering will be multi-faceted, incorporating three components: (1) an electronic disability intake process--which will include a subset of the existing RDS software, (2) the existing DDS claims process, and (3) a new system for the Office of Hearings and Appeals. In addition, we were told the strategy will rely on the use of an electronic folder to transmit data from one processing location to another. The electronic folder is to be a data repository, storing documents that are keyed-in, scanned, or faxed, and will essentially replace the current process of moving a paper folder from one location to another. SSA began pilot testing its new strategy on July 26.
However, as SSA is beginning to move forward with this new initiative, it needs to take advantage of opportunities to apply improved software development processes. In January 1998, we reported that SSA had begun taking steps to improve its software development capability.(18) Significant actions that SSA initiated include (1) launching a formal software process improvement program, (2) acquiring assistance from a nationally recognized research and development center in assessing its strengths and weaknesses and in assisting with improvements,(19) and (3) establishing management groups to oversee software process improvement activities. SSA has developed and is currently applying the improved software development processes to 11 projects.
Given the failure of RDS, it is imperative that any future software initiatives adhere to the improved processes and methods. Without such linkage, SSA again risks spending millions on a project that will not succeed. On July 27, SSA officials told us that the new post-RDS initiative will be linked to the agency's software development improvement efforts.
- - - - -
In summary, SSA has encountered mixed success in implementing its key information technology initiatives. The agency has clearly been a leader on Y2K and has demonstrated a commitment to addressing the challenges of the century date change. Further, the agency has worked aggressively to implement IWS/LAN as its basic automation infrastructure. However, the benefits of the IWS/LAN investment remain uncertain because SSA has not yet assessed its actual contribution to improved mission performance. In addition, after years of problems, SSA discontinued RDS, which will delay expected improvements in the processing of disability claims. To avoid repeating past mistakes on its future information technology efforts, SSA will need to, at a minimum, apply disciplined information technology investment management practices and adhere to improved software development processes.
Mr. Chairman, this concludes my statement. I would be happy to respond to any questions that you or other members of the Subcommittee may have at this time.
Contact and Acknowledgements
For information about this testimony, please contact Joel Willemssen at (202) 512-6253. Individuals making key contributions to this testimony included Michael A. Alexander, Yvette R. Banks, Nabajyoti Barkakati, Valerie C. Melvin, Kenneth A. Johnson, and Sonal Vashi.
1 Social Security Administration: Significant Progress Made in Year 2000 Effort, But Key Risks Remain (GAO/AIMD-98-6, October 22, 1997); Year 2000 Computing Crisis: Continuing Risks of Disruption to Social Security, Medicare, and Treasury Programs (GAO/T-AIMD-98-161, May 7, 1998); and Year 2000 Computing Crisis: Update on the Readiness of the Social Security Administration (GAO/T-AIMD-99-90, February 24,1999).
2 GAO/AIMD-98-6, October 22, 1997.
3 Year 2000 Computing Crisis: Business Continuity and Contingency Planning (GAO/AIMD-10.1.19, March 1998 [exposure draft], August 1998 [final]).
4 Year 2000 Computing Crisis: Readiness Improving, But Much Work Remains to Avoid Major Disruptions (GAO/T-AIMD-99-50, January 20, 1999).
5 Thirteen applications were not tested because they are no longer in use (e.g., obsolete, retired, replaced); 10 because they were incompatible with the QA tool; and 1 because it was no longer part of SSA's inventory. One application remained to be tested.
6 SSA's "dumb" terminals are connected to its mainframe computers through its data network and are controlled by software executed on the mainframes.
7 The national IWS/LAN initiative consisted of two phases. During phase I, SSA planned to acquire workstations, LANs, notebook computers, systems furniture, and other peripheral devices as the basic, standardized infrastructure to which additional applications and functionality can later be added. Phase II was intended to build upon the IWS/LAN infrastructure provided through the phase I effort.
8 Social Security Administration: Technical and Performance Challenges Threaten Progress of Modernization (GAO/AIMD-98-136, June 19, 1998).
9 SSA also used another procurement vehicle to procure 1,767 additional workstations that are also part of the IWS/LAN architecture.
10 According to SSA, the remaining workstations are to be installed by October 1999.
11 GAO/AIMD-98-136, June 19, 1998.
12 Social Security Administration: Risks Associated With Information Technology Investment Continue (GAO/AIMD-94-143, September 19, 1994).
13 GAO/AIMD-98-136, June 19, 1998.
14 The reported costs were for RDS software design and development, pilot tests, and contractor support.
15 Social Security Administration: Effective Leadership Needed to Meet Daunting Challenges (GAO/HEHS-96-196, September 12, 1996).
16 The federal DDS provides back-up services to state DDSs when the state offices cannot process their workloads and serves as a model office for testing new technologies and work processes.
17 GAO/AIMD-98-136, June 19, 1998.
18 Social Security Administration: Software Development Process Improvements Started But Work Remains (GAO/AIMD-98-39, January 28, 1998).
19 The Software Engineering Institute at Carnegie Mellon University, in Pittsburgh, Pennsylvania.