Managed by U.S. Customs and Border Protection (CBP), SBInet is to strengthen DHS’s ability to detect, identify, classify, track, and respond to illegal breaches at and between ports of entry. It includes the acquisition, development, integration, deployment, and operations and maintenance of a mix of surveillance technologies, such as cameras, radars, sensors, and C3I technologies. Surveillance technologies include unattended ground sensors that can detect heat and vibrations associated with foot traffic and metal associated with vehicles, radar mounted on fixed towers that can detect movement, and cameras mounted on fixed towers that can be used to identify and classify items of interest detected and tracked by ground sensors and radar. These technologies are generally commercial off-the- shelf products. C3I technologies include customized software development to produce a common operating picture (COP)—a uniform presentation of activities within specific areas along the border—as well as the use of CBP network capabilities. Together, the surveillance technologies are to gather information along the border and transmit this information to COP terminals located in command centers, which are to assemble it to provide CBP agents with border situational awareness, to, among other things, enhance agents’ tactical decisionmaking regarding potential apprehensions. Since fiscal year 2006, DHS has received about $4.4 billion in appropriations for SBI, including about $2.5 billion for physical fencing and related infrastructure, about $1.5 billion for virtual fencing (e.g., surveillance systems) and related infrastructure (e.g., towers), and about $300 million for program management. As of May 2010, DHS had obligated about $1.02 billion for SBInet. The SBI Program Management Office, which is organizationally within CBP, is responsible for managing key acquisition functions associated with SBInet, including prime contractor management and oversight. It is organized into four components: the SBInet System Program Office (SPO), Operational Integration Division, Business Operations Division, and Systems Engineering Division. The SPO is responsible for such key contractor oversight activities as verifying and accepting contract deliverables and conducting contractor management and technical reviews. In addition, the Business Operations Division has primary responsibility for monitoring the prime contractor’s cost and schedule performance. As of May 2010, the SBI Program Management Office was staffed with 194 people—105 government employees, 78 contractor staff, and 11 detailees. (See figure 1 for a partial SBI program organization organization chart.) chart.) In addition, CBP has engaged the Defense Contract Management Agency to, among other things, perform surveillance of the prime contractor’s EVM, systems engineering, hardware and software quality assurance, and risk management. Further, the SBI Contracting Division, which is organizationally within the CBP Office of Administration Procurement Directorate’s Enterprise Contracting Office, is responsible for performing contract administration activities, such as maintaining the contract file and notifying the contractor in writing of whether deliverables are accepted or rejected. The SBI Contracting Division is organized into three branches: SBI Contracting, SBInet System Contracting, and SBInet Deployment Contracting. As of May 2010, the SBI Contracting Division was staffed with 22 people—18 government employees and 4 contractor staff. (See figure 2 for a partial SBI Contracting Division organization chart.) In September 2006, CBP awarded an Indefinite Delivery/Indefinite Quantity (IDIQ) prime contract to the Boeing Company. The contract was for 3 base years with three additional 1-year options for designing, producing, testing, deploying, and sustaining SBI. In September 2009, CBP exercised the first option year. Under the prime contract, CBP has issued 11 task orders that relate to SBInet, covering for example, COP design and development, system deployment, and system maintenance and logistics support. As of May 2010, 5 of the 11 task orders were complete and 6 were ongoing. (See table 1 for a summary of the SBInet task orders.) Through the task orders, CBP’s strategy is to deliver SBInet capabilities incrementally. To accomplish this, the program office adopted an evolutionary system life cycle management approach in which system capabilities are to be delivered to designated locations in a series of discrete subsets of system functional and performance capabilities that are referred to as blocks. The first block (Block 1) includes the purchase of commercially available surveillance systems, development of customized COP systems and software, and use of existing CBP communications and network capabilities. According to program officials, as of July 2010, the Block 1 design was deployed to TUS-1 and was being deployed to AJO-1, both of which are located in CBP’s Tucson Sector of the southwest border. Together, these two deployments cover 53 miles of the 1,989-mile-long southern border. Also, according to program officials, as of July 2010, TUS-1 and AJO-1 were to be accepted in September 2010 and December 2010, respectively. In January 2010, the Secretary of Homeland Security ordered an assessment of the SBI program. In addition, on March 16, 2010, the Secretary froze fiscal year 2010 funding for any work on SBInet beyond TUS-1 and AJO-1 until the assessment is completed. Also at that time, the Secretary redirected $35 million that had been allocated to SBInet Block 1 deployment to other tested and commercially-available technologies, such as truck-mounted cameras and radar, called Mobile Surveillance Systems, to meet near-term needs. According to the SBI Executive Director, the department’s assessment would consist of a comprehensive and science- based assessment to determine if there are alternatives to SBInet that may more efficiently, effectively, and economically meet U.S. border security needs. Further, the Executive Director stated that if the assessment suggests that the SBInet capabilities are worth the cost, DHS will extend its deployment to sites beyond TUS-1 and AJO-1. However, if the assessment suggests that alternative technology options represent the best balance of capability and cost-effectiveness, DHS will redirect resources to these other options. According to program officials, the initial phase of the assessment, which addresses the Arizona border, was completed in July 2010, and the results are currently being reviewed by senior DHS management. Officials were unable to provide a date for completion of the review. Our research and evaluations of information technology programs have shown that delivering promised system capabilities and benefits on time and within budget largely depends on the extent to which key acquisition management disciplines are employed. These disciplines include, among others, requirements management, risk management, and test management. As is discussed in the following section, we have previously reported on the extent to which these disciplines have been employed on SBInet. Contractor management and oversight, which is the focus of this report, is another acquisition management discipline. Among other things, this discipline helps to ensure that the contractor performs the requirements of the contract and the government receives the service or product intended. DHS acquisition policies and guidance, along with other relevant guidance, recognize the importance of these management and oversight disciplines. As we have previously reported, not employing them increases the risk that system acquisitions will not perform as intended and will require expensive and time-consuming rework. Since 2007, we have identified a range of management weaknesses and risks facing SBInet, and we have made a number of recommendations to address them that DHS has largely agreed with, and to varying degrees, taken actions to address. For example, in February 2007, we reported that DHS had not fully defined activities, milestones, and costs for implementing the program or demonstrated how program activities would further the strategic goals and objectives of SBI. Further, we reported that the program’s schedule contained a high level of concurrency among related tasks and activities, which introduced considerable risk. Accordingly, we recommended that DHS define explicit and measurable commitments relative to, among other things, program capabilities, schedules, and costs, and re-examine the level of concurrency in the schedule and adjust the acquisition strategy appropriately. In September 2008, we reported that a number of program management weaknesses put SBInet at risk of not performing as intended and taking longer and costing more to deliver than was necessary. Specifically, we reported the following: Important aspects of SBInet were ambiguous and in a continued state of flux, making it unclear and uncertain what technology capabilities were to be delivered when. For example, the scope and timing of planned SBInet deployments and capabilities had continued to change since the program began and remained unclear. Further, the SPO did not have an approved integrated master schedule to guide the execution of the program, and our assimilation of available information indicated that key milestones continued to slip. This schedule-related risk was exacerbated by the continuous change in and the absence of a clear definition of the approach used to define, develop, acquire, test, and deploy SBInet. Accordingly, we concluded that the absence of clarity and stability in these key aspects of SBInet impaired the ability of Congress to oversee the program and hold DHS accountable for results, and it hampered DHS’s ability to measure the program’s progress. SBInet requirements had not been effectively defined and managed. While the SPO had issued guidance that defined key practices associated with effectively developing and managing requirements, the guidance was developed after several key activities had been completed. In the absence of this guidance, the SPO had not effectively performed key requirements development and management practices, such as ensuring that different levels of requirements were properly aligned. As a result, we concluded that the risk of SBInet not meeting mission needs and performing as intended was increased, as were the chances of the system needing expensive and time-consuming rework. SBInet testing was not being effectively managed.