Information Technology: Uncertainty Remains about the Bureau's Readiness for a Key Decennial Census Test
Released: 2016-11-16T00:00:00

Letter

Background

For the 2020 Census, the Bureau is significantly changing how it intends to conduct the census, in part by re-engineering key census-taking methods and infrastructure, and making use of new IT applications and systems. The CEDCAP program, which began in October 2014, is intended to provide data collection and processing solutions (including systems, interfaces, platforms, and environments) to support the Bureau’s multiple surveys throughout the survey life cycle (including survey design; instrument development; sample design and implementation; data collection; and data editing, imputation, and estimation). In October 2015, the Bureau estimated that, with its new approach, it expects to be able to conduct the 2020 Census for a life-cycle cost of $12.5 billion, which would be a reduction of about $5.2 billion from its estimate of what it would cost to repeat the design and methods of the 2010 Census. However, in June 2016, we reported that this $12.5 billion cost estimate was not reliable and did not adequately account for risks that could affect the 2020 Census costs.

In November 2015, the Bureau issued a 2020 Census Operational Plan, which is intended to outline the design decisions that are to drive how the 2020 Decennial Census will be conducted—and which are expected to dramatically change the Bureau’s approach to conducting the 2020 Decennial Census. The plan identified 350 redesign decisions that the Bureau had either made or was planning to make through 2018. In August 2016, we reported that the Bureau had determined that about 51 percent of the design decisions were either IT-related or partially IT- related (84 IT-related and 94 partially IT-related).

As of October 2016, the Bureau reported that it had made 68 IT-related and 62 partially IT-related design decisions. For example, the Bureau had decided that individuals/households are to be able to respond to the census on the Internet from a computer, mobile device, or other devices that access the Internet; that it intends to award a contract to provide mobile phones and the accompanying service to enumerators; and that it plans to use a hybrid cloud solution where it is feasible. However, the Bureau acknowledged that it still needed to make 16 IT-related and 32 partially IT-related design decisions, including on (1) the uses of cloud- based solutions, such as whether it plans to use a cloud service provider to support a tool for assigning, controlling, tracking, and managing enumerators’ caseloads in the field; (2) the tools and test materials to be used during integration testing; and (3) the expected scale of the system workload for those respondents that do not use the Bureau-provided Census identification.

To inform these design decisions, the Bureau held several major operational tests, including the 2014 Census test, which was conducted in the Maryland and Washington, D.C., areas to evaluate new methods for conducting self- response and non-response follow-up; the 2015 Census test in Arizona, which evaluated, among other things, (1) the use of a field operations management system to automate data collection operations and provide real-time data, (2) the ability to reduce the non-response follow-up workload using information previously provided to the government, and (3) the use of personally owned mobile devices by the field-based enumerators who go door to door to collect census data; the 2015 Optimizing Self-Response test in Savannah, Georgia, and the surrounding area, which was intended to explore methods of encouraging households to respond using the Internet, such as by using advertising and outreach to motivate respondents, and enabling households to respond without a Bureau-issued identification number; and the 2016 Census tests in Harris County, Texas and Los Angeles, California, which evaluated, among other things, the efficiency of non- response follow-up using contractor-provided mobile devices.

Looking forward, the Bureau has plans for two additional operational tests: (1) the 2017 Census test—a nationwide sample of how individuals respond to Census questions using paper, the Internet, or the phone— in order to evaluate key new IT components, such as the Internet self- response system and the use of a cloud-based infrastructure; and (2) the 2018 end-to-end test, scheduled from August 2017 through December 2018, which, as previously mentioned, is to test all key systems and operations to ensure readiness for the 2020 Census.

Overview: The CEDCAP Program

The 2020 Decennial Census operations are dependent on about 50 IT systems that are currently being developed or are already in production. Eleven of these systems are expected to be provided as CEDCAP enterprise systems, which have the potential to offer numerous benefits to the Bureau’s multiple survey programs, such as enabling an Internet response option; automating the assignment, control, and tracking of the caseloads of the field-based enumerators; and enabling a mobile data collection tool for field work. More details on each of the CEDCAP projects can be found in our June 2016 testimony and our August 2016 report.

Our August 2016 report noted that the projects were at varying stages of planning and design, and none were in the implementation/deployment stage. The Bureau had previously developed several pilot systems to provide and test different capabilities, but in May 2016, decided that it would acquire six of the capabilities from a vendor, using a commercial- off-the-shelf IT platform, rather than continue to develop the capabilities in-house. This project is called the Enterprise Censuses and Surveys Enabling (ECASE) initiative. The capabilities that ECASE is to provide include key functionality intended to significantly redesign the 2020 Census and achieve efficiency gains, such as enabling an Internet response-option and an operational control system that automates the assignment, tracking, and management of enumerators’ case work.

The Bureau does not have a firm estimate for the cost of the CEDCAP projects. In 2013, the CEDCAP program office estimated that the program would cost about $548 million from 2015 to 2020. More recently, in July 2015, an independent cost estimate for CEDCAP projected the projects to cost about $1.14 billion from 2015 to 2020. However, this July 2015 estimate was developed before the bureau decided to purchase rather than continue to build six of the CEDCAP capabilities.

Prior Efforts to Insert Information Technology in Decennial Census Programs Experienced Problems

As noted in our prior reports, the Bureau’s past efforts to acquire and implement new approaches and systems have not always gone as planned. As one example, during the 2010 Census, the Bureau planned to use handheld mobile devices to support field data collection for the census, including following up with non-respondents. However, due to significant problems identified during testing of the devices, as well as cost overruns and schedule slippages, the Bureau decided not to use the handheld devices for nonresponse follow-up. Instead, it reverted to paper- based processing, which increased the cost of the 2010 Census by up to $3 billion and significantly increased the risk of not completing the Census on time. Due in part to these technology issues the Bureau was facing, we designated the 2010 Census a high-risk area in March 2008.

Further, we testified in November 2015 that key IT decisions needed to be made soon because the Bureau was less than 2 years away from end- to-end testing of all systems and operations to ensure readiness for the 2020 Census, leaving limited time to implement the systems. We emphasized that the Bureau had deferred key IT-related decisions, and that it was running out of time to develop, acquire, and implement the systems it will need to deliver the redesigned operations.

Government-wide Challenges Involving IT Acquisition and Operations

The Bureau is not alone in facing challenges in acquiring IT systems—it is a systemic issue that plagues the federal government. Although the executive branch has undertaken numerous initiatives to better manage the more than $80 billion that is annually invested in IT, we have a significant body of work that has found that federal IT investments too frequently fail or incur cost overruns and schedule slippages while contributing little to mission-related outcomes. We have previously testified that the federal government has spent billions of dollars on failed IT investments, such as the Department of Defense’s Expeditionary Combat Support System, which was canceled in December 2012, after spending more than a billion dollars and failing to deploy within 5 years of initially obligating funds; the Department of Veterans Affairs’ Financial and Logistics Integrated Technology Enterprise program, which was intended to be delivered by 2014 at a total estimated cost of $609 million, but was terminated in October 2011 due to challenges in managing the program; and the National Oceanic and Atmospheric Administration, Department of Defense, and the National Aeronautics and Space Administration’s National Polar-orbiting Operational Environmental Satellite System, which was a tri-agency weather satellite program that was terminated in February 2010 after having spent 16 years and almost $5 billion on the program, when a presidential task force decided to disband the system.

Our work has shown that these and other failed IT projects often suffered from a lack of disciplined and effective management, such as project planning, requirements definition, and program oversight and governance. In many instances, agencies have not consistently applied best practices that are critical to successfully acquiring IT investments, such as (1) program staff having the necessary knowledge and skills; (2) program staff prioritizing requirements; (3) end users participating in the testing of system functionality prior to end user acceptance testing; (4) government and contractor staff being stable and consistent; and (5) program officials maintaining regular communication with the prime contractor.

Due to the challenges of acquiring IT across the federal government, we added improving the management of IT acquisitions and operations as a key area in our 2015 High-Risk Report. As part of this new area, we also identified CEDCAP as one of nine programs across the federal government in need of the most attention.

The Bureau Lacks Processes for Effectively Managing Interdependencies between the CEDCAP and 2020 Census Programs

In August 2016, we reported that the CEDCAP and 2020 Census programs were intended to be on parallel implementation tracks and had major interdependencies; however, the interdependencies between these two programs had not always been effectively managed. Importantly, CEDCAP relies on 2020 Census to be one of the biggest consumers of its enterprise systems, and 2020 Census relies heavily on CEDCAP to deliver key systems to support its redesign.

Nevertheless, while both programs had taken a number of steps to coordinate, such as holding weekly schedule coordination meetings and participating in each other’s risk review board meetings, they lacked processes for effectively integrating their schedule dependencies, integrating the management of interrelated risks, and managing requirements. Specifically:

The CEDCAP and 2020 Census programs did not have an effective process for integrating schedule dependencies. Best practices identified in our Schedule Assessment Guide call for dependencies between two programs to be automatically linked and dynamically responsive to change, or handled through a defined repeatable process if manual reconciliation cannot be avoided. We reported that the CEDCAP and 2020 Census programs had both established master schedules that contain thousands of milestones and tens of thousands of activities and had identified major milestones within each program that were intended to align with each other. However, the CEDCAP and 2020 Census programs maintained their master schedules using different software where dependencies between the two programs were not automatically linked, were not dynamically responsive to change, and not handled through a defined repeatable process. Instead, the Bureau’s practice of maintaining separate dependency schedules, which must be manually reconciled, had proven to be ineffective and had contributed to the misalignment between the programs’ schedules. We concluded in our report that, without an effective process for ensuring alignment between the two programs, the Bureau faces increased risk that capabilities for carrying out the 2020 Census will not be delivered as intended. Thus, we recommended that the Bureau define, document, and implement a repeatable process to establish complete alignment between the CEDCAP and 2020 Census programs by, for example, maintaining a single dependency schedule. The Bureau agreed with this recommendation and indicated it would be taking actions to address it.

CEDCAP and 2020 Census did not have an integrated list of risks facing both programs. We reported that the two programs had taken steps to collaborate on identifying and mitigating risks, such as having processes in place for identifying and mitigating risks that affect their respective programs. However, we found that these programs did not have an integrated list of risks (referred to as a risk register) with agreed-upon roles and responsibilities for tracking them, as called for by best practices identified by GAO for collaboration and leading practices in risk management. This decentralized approach introduced two key challenges: (1) there were inconsistencies in tracking and managing interdependent risks, and (2) tracking risks in two different registers could result in redundant efforts and potentially conflicting mitigation efforts. To address this, we recommended that the Bureau establish a comprehensive and integrated list of all interdependent risks facing the CEDCAP and 2020 Census programs, and clearly identify roles and responsibilities for managing this list. The Bureau agreed with this recommendation and indicated it would take actions to address it.

Among other requirements management challenges, we reported that although the Bureau had drafted a process for managing requirements between CEDCAP and 2020 Census programs, the process had not yet been finalized. As a result, the Bureau had developed three system releases without having a fully documented and institutionalized process for collecting those requirements. In July 2016, Bureau officials stated that, due to the recent selection of a commercial vendor to deliver many of the CEDCAP capabilities, they did not plan to finalize this process until January 2017. We made three recommendations to the Bureau to strengthen its requirements management processes. The Bureau agreed with these recommendations and reported that it planned to take actions to address them.

Census Bureau Faces Several Information Security Challenges in Implementing the 2020 Census

While the Bureau plans to extensively use IT systems to support the 2020 Census redesign in an effort to realize potentially significant efficiency gains and cost savings, we reported that this redesign introduces critical information security challenges related to the following: minimizing the threat of phishing aimed at stealing personal information, which could target 2020 Census respondents, as well as Census employees and contractors; ensuring that individuals gain only limited and appropriate access to adequately protecting approximately 300,000 mobile devices; ensuring adequate control of security performance requirements in a cloud environment, such as those related to data reliability, preservation, privacy, and access rights; adequately considering information security when making decisions about the IT solutions and infrastructure supporting the 2020 Census; making certain that key IT positions are filled and have appropriate information security knowledge and expertise; ensuring that contingency and incident response plans are in place that encompass all of the IT systems to be used to support the 2020 Census; adequately training Bureau employees, including its massive temporary workforce, in information security awareness; making certain that security assessments are completed in a timely manner and that risks are at an acceptable level; and properly configuring and patching systems supporting the 2020 Census.

For example, the introduction of an option for households to respond using the Internet puts respondents more at risk for phishing attacks. In addition, because the Bureau plans to provide its enumerators with mobile devices to collect information from households that did not self- respond to the survey, it is important that the Bureau ensures that these devices are adequately protected. More details on each of these challenges can be found in our recently issued report.

In early 2016, the Bureau’s acting Chief Information Officer and its Chief Information Security Officer acknowledged these challenges and described the Bureau’s plans to address them. For example, the Bureau has developed a risk management framework, intended to ensure that proper security controls are in place and provide authorizing officials with details on residual risks and progress to address those risks. To minimize the risk of phishing, Bureau officials noted that they plan to contract with a company to monitor the Internet for fraudulent sites pretending to be those of the Census Bureau. Continued focus on these considerable challenges will be important as the Bureau begins to develop and/or acquire systems and implement the 2020 design.

Uncertainty about the Bureau’s Readiness for the 2018 Test Remains

Looking forward, there is uncertainty as to whether the Census Bureau will be ready for the 2018 end-to-end test. We have ongoing work for this committee that is evaluating the significant challenges the Bureau faces in developing, testing, and integrating systems prior to the 2018 test. Among other things, we plan to address the following key questions: Is the Bureau sufficiently prepared to complete the development, testing, and integration of all of the systems and infrastructure in time for the end-to-end test? There are less than 9 months before the 2018 test is scheduled to begin, but a great deal of development work remains to be completed and the Bureau is still developing the plans and schedules leading up to the 2018 test. For example, as of October 2016, only 3 of the 50 systems (6 percent) had been delivered. The other 47 systems that the Bureau plans to use during the 2018 end-to-end test were in various forms of development, including:

22 systems (or 44 percent) that were expected to be delivered by the time the 2018 end-to-end test begins;

15 systems (or 30 percent) that were expected to be delivered after the 2018 end-to-end test begins; and

10 systems (or 20 percent) that did not have firm delivery dates.

Figure 1 depicts the percentage of systems that have been delivered, are scheduled before and after August 1, 2017, and that have not yet been firmly scheduled for delivery.

In addition, the Bureau has not identified the entire infrastructure (i.e., cloud solutions and/or data centers) that it plans to use for the 2018 test or 2020 operations and, as of October 2016, it did not yet have a time frame for the implementation of the infrastructure.

Is the Bureau effectively managing its significant contractor support? The Bureau is relying on contractor support in many key areas, including the technical integration of all of the key systems and infrastructure, and the development of many of the data collection systems. For example, in August 2016, the Bureau awarded a contract for the technical integration of the 2020 Census systems and infrastructure, to include an evaluation of the systems and infrastructure, development of the infrastructure (e.g., cloud or data center) to meet the Bureau’s scalability and performance needs, integration of all of the systems, and support for testing activities. However, key dates for this work have yet not been finalized.

In addition, the Bureau is relying on other contractors to develop a number of key systems, such as (1) development of the IT platform that will be used to collect data from a majority of respondents— through the use of the Internet, telephone, and non-response follow- up activities; (2) procurement of the mobile devices and cellular service to be used for non-response follow-up; and (3) development of the IT infrastructure in the field offices. The 2020 Census will be the first time that the Bureau uses a technical integrator in this manner; collects data nationwide via the Internet; and relies on mobile devices for non-response follow-up. A greater reliance on contractors for these key components of the 2020 Census requires the Bureau to focus on sound management and oversight of the key contracts, projects, and systems.

Does the Bureau have back-up plans in case key systems are not ready in time for the 2018 test? The 2017 Census Test (with a Census Day of April 1, 2017) will be the first time that the Bureau has an opportunity to test various IT systems and infrastructure in operation, including the Internet response system and the system to be used for phone responses. However, because the Bureau is revising its plans for the 2017 test, it has not yet determined whether or how it will test other systems and features prior to the end-to-end test, such as the mobile devices that the enumerator’s will use to record and upload household information and whether these systems can handle a nationwide scope. Uncertainty about what will be included in the 2017 test has the potential to add risk to the 2018 end- to-end test, and it will be important for the Bureau to make plans in case key systems are not ready in time for the 2018 test.

Can the Bureau adequately secure the systems and data, and respond to breaches should they occur? As described previously, the Bureau faces significant challenges in securing systems and data, and tight time frames can exacerbate those challenges. Because many of the systems to be used in the 2018 end-to-end test are not yet fully developed, the Bureau has not finalized all of the controls to be implemented, completed an assessment of those controls, developed plans to remediate any control weaknesses, and determined whether there is time to fully remediate any weaknesses before the system test begins.

We are continuing to evaluate these and other important areas related to the Bureau’s efforts to ensure its systems are ready for the 2020 Decennial Census.

In summary, the CEDCAP program has the potential to offer numerous benefits to the Bureau’s multiple survey programs, including the 2020 Census program. While the Bureau had taken steps to implement CEDCAP projects, considerable work remains for its production systems to be in place to support the 2020 Census end-to-end system integration test—which is to occur in less than a year. Given the numerous and critical dependencies between the CEDCAP and 2020 Census programs, their parallel implementation tracks, and the 2020 Census’ immovable deadline, it is imperative that the interdependencies between these programs be effectively managed.

Implementation of our recommendations to, among other things, use a repeatable process to establish complete alignment between the programs; establish an integrated list of all interdependent risks facing the programs; and strengthen the programs’ processes for requirements management would help align the programs and better ensure that the efficiency and effectiveness goals of the 2020 Census redesign are achieved.

Additionally, while the large-scale technological changes for the 2020 Decennial Census introduce great potential for efficiency and effectiveness gains, it also introduces many information security challenges, including educating the public to offset inevitable phishing scams. Continued focus on these considerable security challenges will be important as the Bureau begins to develop and/or acquire systems and implement the 2020 Census design.

In our ongoing work for this committee, we plan to address key questions about the Bureau’s ability to develop, integrate, test, and secure the IT systems and infrastructure in time for the end–to-end test. Given the short window of time before the test begins, it is important that the Bureau continue to focus its attention on implementing and securing the systems that will collect and store the personal information of millions of American people.

Chairman Meadows, Ranking Member Connolly, and Members of the Subcommittee, this completes my prepared statement. I would be pleased to respond to any questions that you may have.

Contact and Acknowledgments

If you have any questions concerning this statement, please contact David A. Powner at (202) 512-9286 or pownerd@gao.gov. GAO staff who made key contributions to this testimony are Carol Harris (Director), Colleen Phillips (Assistant Director), Shannin G. O’Neill (Assistant Director), Kate Sharkey (Analyst in Charge), Andrew Beggs, Chris Businsky, Juana Collymore, Becca Eyler, Lee McCracken, Andrea Starosciak, Jeanne Sung, and Umesh Thakkar.

This is a work of the U.S. government and is not subject to copyright protection in the United States. The published product may be reproduced and distributed in its entirety without further permission from GAO. However, because this work may contain copyrighted images or other material, permission from the copyright holder may be necessary if you wish to reproduce this material separately.