As you know, Mr. Chairman, the decennial census is a constitutionally mandated enterprise critical to our nation. Census data are used to apportion congressional seats, redraw congressional districts, and help allocate hundreds of billions of dollars in federal aid to state and local governments each year. Although an accurate population count is always a difficult task, the 2010 Census is a particular challenge because of various societal trends, such as concerns over personal privacy, more non-English speakers, and more people residing in makeshift and other nontraditional living arrangements because of economic dislocation or natural disasters. As a result, the Bureau is finding it increasingly difficult to locate people and get them to participate in the census. In developing the 2010 Census, a long-standing challenge for the Bureau has been the reliability of its IT systems. For example, in March 2009, we reported that the Bureau needed to develop a master list of interfaces between systems, set priorities for the testing of interfaces based on criticality, and develop testing plans and schedules. In the months that followed, while the Bureau strengthened its management and oversight of its IT systems, additional work was needed under very tight time frames. More generally, now that the census has moved to the operational phase, it will be important for the Bureau to stay on schedule. The enumeration has several absolute deadlines, and an elaborate chain of interrelated pre- and post-Census Day activities are predicated upon those dates. Specifically, the Department of Commerce—the Bureau’s parent agency—is legally required to (1) conduct the census on April 1 of the decennial year, (2) report the state population counts to the President for purposes of congressional apportionment by December 31 of the decennial year, and (3) send population tabulations to the states for purposes of redistricting no later than 1 year after the April 1 census date. To meet these reporting requirements, census activities need to take place at specific times and in the proper sequence. A timeline of key census operations is shown in figure 1. Although the Bureau has made progress in testing and deploying IT systems for the 2010 Census, significant performance issues need to be addressed with both PBOCS, the work flow management system, and DAPPS, the automated system the Bureau is using to process applicants and handle the payroll of the more than 600,000 temporary employees who are to work on the census during peak operations. In March 2009, we reported that the Bureau had a number of problems related to testing of key IT systems, including weaknesses in test plans and schedules, and a lack of executive-level oversight and guidance. In that report, we recommended that the Bureau complete key system testing activities and improve testing oversight and guidance. The Bureau agreed with our recommendations. Since that time, we have been monitoring and tracking the Bureau’s progress and, in February 2010, we testified that while progress had been made in respect to system testing, key IT systems were facing critical performance issues. For example, we reported that in December 2009, the Bureau completed two iterations of a key performance test, known as the Decennial Application Load Test. As part of the test, more than 8,000 field staff at about 400 local census offices performed a combination of manual and automated tests to assess the performance of key IT systems, including DAPPS and the first release of PBOCS. In the first test, DAPPS failed and other key systems, including PBOCS, performed slowly. In the second iteration, DAPPS completed the test, though performance was slow. Bureau officials stated that DAPPS performance shortfalls were a result of three major issues, involving system hardware, software, and the operating system. They said that they were taking several steps to resolve these issues, including upgrading and reconfiguring the system, and deploying additional hardware to support the system, and planned to complete these efforts by the end of February. At the time, officials acknowledged that it was critical that DAPPS be fully functional under a heavy load by mid- March, when the Bureau would begin hiring a large number of temporary employees (about 600,000) for NRFU who will need to be paid using the system. The Bureau has since completed many steps to improve DAPPS performance, and more are planned. However, as of mid-March, the system was still experiencing capacity limitations and slow response. These shortcomings were occurring even though approximately 100,000 temporary employees were currently being paid using the system versus the more than 600,000 employees that will need to be paid at the peak of field operations. For example, Bureau officials stated that they had already instructed DAPPS users to implement several work-arounds to improve system performance, such as reducing the number of system-intensive reports generated during peak hours. As of March 22, Bureau officials stated that they had completed additional steps to improve DAPPS performance, including upgrading and reconfiguring the system’s software and installing additional hardware. However, Bureau officials also stated that additional testing and system refinements may be needed to determine if these upgrades will address the performance issues previously described. Bureau officials stated that they may not have sufficient time and resources to add additional server capacity if these upgrades are not sufficient, so if performance problems remain, officials stated that the Bureau will identify additional work-arounds to reduce the demand on the system, including limiting the frequency and times when field office staff can generate certain reports and run system-intensive operations. Performance issues with PBOCS still need to be addressed as well. While the first release of this system was deployed for early census field operations in January 2010 and certain components of the second release were deployed in February 2010, both releases have known defects, such as limited functionality, slow performance, and problems generating certain progress and performance reports. For example, Bureau officials from a local census office in the Gulf Coast, working on hand delivering questionnaires in the hurricane-affected area, indicated that PBOCS has been operating very slowly and is occasionally unavailable. Although not necessarily indicative of PBOCS issues occurring elsewhere in the country, it does highlight some of the productivity problems resulting from the shortcomings with PBOCS. The Bureau has also had to restrict the number of PBOCS users per local census office due to capacity limitations. In many cases, temporary work-arounds have been communicated to field staff; however, these issues must be resolved and retested. Furthermore, the component of the second release that will be used to manage NRFU, the largest field operation, is still being tested and is not planned for deployment until mid-April 2010—about 3 weeks later than planned. With the NRFU operation scheduled to begin in early May 2010, this leaves little time to address issues identified during testing. Lastly, the development and testing of the third release of PBOCS is needed before the system is ready for later field operations, such as the final check of housing unit status (known as field verification), scheduled to begin in August 2010. In recognition of the serious implications that a failed PBOCS would have for conducting the 2010 Census, the Bureau has taken additional steps to mitigate the outstanding risks. For example, in June 2009, the Bureau chartered an independent assessment team, chaired by the Bureau’s Chief Information Officer, to monitor and report on, among other things, the system’s development and testing progress. Further, the Bureau stated that in January 2010, it also established the 2010 Census Application Readiness and Infrastructure Stability Group in order to centralize leadership and coordination efforts across key systems, including PBOCS. These efforts are encouraging. However, the aggressive development and testing schedule presents various challenges. For example, two of the three releases of PBOCS were not included in the performance test in December because development of these releases had not yet been completed. This increases the risk that performance issues, such as those described above, may reoccur in future releases of the system, and the Bureau’s ability to resolve and retest these issues before the system is needed for key field operations will be limited. In addition to DAPPS and PBOCS, the Bureau will rely on six other key automated systems to conduct the census. Progress has been made with respect to system testing. However, much system testing remains to be completed in the next few months, as shown in table 1. Given the importance of IT systems to the decennial census, it is critical that the Bureau ensure that DAPPS, PBOCS, and other key systems are thoroughly tested and able to meet full operational requirements. The limited amount of time to resolve what are, in certain cases, significant performance issues creates a substantial challenge for the Bureau. In contrast to the IT systems, the rollout of other activities is going more smoothly. Indeed, the Bureau has taken steps to address certain previously identified problems, and its plans to improve the enumeration of hard-to- count groups are generally more robust compared to similar activities during the 2000 Census. Those activities include procedures for fingerprinting temporary employees; the rollout of key marketing efforts aimed at improving the participation of hard-to-count populations; the Bureau’s plans for mailing a second, follow-up questionnaire and the removal of late mail returns; activities aimed at including the homeless and people residing in nonconventional dwellings; and the Bureau’s plans to secure a complete count of those in the hurricane-affected areas along the Gulf Coast. The Bureau plans to fingerprint its temporary workforce for the first time in the 2010 Census to better conduct background security checks on its workforce of hundreds of thousands of temporary census workers. However, the Bureau found that during address canvassing, an operation that the Bureau conducted in the summer of 2009 to verify every address in the country, 22 percent of the workers (approximately 35,700 people) hired for the operation had unclassifiable prints. The Federal Bureau of Investigation (FBI) determined that this problem was generally the result of errors that occurred when the prints were first taken at the local census offices.