Intelligence

Segment Upgrade Program

The merger of many operations of the Air Force and the CIA into one unified mission organization inevitably clashed two dissimilar cultures and ways of doing business, a dynamic that persists today. Also during this period, Congress mandated the establishment of the Enhanced Imagery System, coupled with a directive that the NRO become more efficient and effective. Of the eight major subsystems in the segment upgrade program, only one, the Control and Status Subsystem, is software-oriented. The remaining hardware subsystems are complex and contain extensive embedded firmware, particularly in the Wideband Data Subsystem.

Segment 1

Given its pivotal role in system management, the Development Systems Division (the systems integrator) -Segment 1- has been actively involved in risk management and related activities. This division became owners of the tailoring and redesign of the Risk Management tool for system-level application. Also, the division coordinated a team of project managers, one or two from each division, who were known as the risk cadre and who were originally slated to serve as divisional trainers in Risk Management. For a short time, the cadre evolved to consider the impact of system-level approaches to Risk Management.

Eventually, they provided valuable input to development of the Risk Management tool for system-level use, ensuring that the tool would be usable by each division. Segment 1 has been subsumed by the reorganization, which has generated a systems-engineering organization under the leadership of former Program Director Al Krum. As a result, the division itself is no longer a player in system Risk Management. However, members of the former Segment 1 staff continue to play an active role in completing the system-level development and installation of the system Risk Management tool and in supporting Risk Management in various system-level meetings and forums.

Segment 2

Segment 2 and Segment 32 also created stronger Risk Management partnerships with their contractors. With clear leadership by the Segment 2 division chief, this division strengthened its own Risk Management process, and then expanded that to its contractors. Segment 2 project managers provided knowledge transfer from their segment's Risk Management workshop and Risk Clinic to their contractors. Gradually, those contractors aligned their Risk Management processes with the Segment 2 process, and strengthened their Risk Management discipline to become more proactive in the identification and mitigation of risks.

Segment 32

Segment 32 engaged its contractors in a collaborative process of earlier definition of schedule delays and appropriate mitigations. The Segment 32 division chief retained insight into the Risk Management efforts of contractors. Based on the growing maturity of Risk Management in Segment 32, the division chief moved forward an expanded discussion with contractors on risk analysis and mitigation strategies. The result was that the government/contractor relationship changed over a period of several months from one of parallel risk information and management, to a closer Risk Management partnership with greatly expanded shared information.

Segment 32 has no money to cover unexpected events at this point. There is no trade space possible for performance either, because all of this work has been completed. Therefore, the only arena where there is control is scheduling. Over the long term, Segment 32 had experienced a low level of confidence in the contractor's scheduling projections, which had repeatedly proven to be inaccurate (and were extended).

There was a system risk from the interface of Segments 5 and 32 and The Ground Station to produce high-quality images. Discussions of this risk eventually resulted in an interface test that will mitigate the risk and improve the ability to produce good imagery at IOC. Segment 32 has had success with the contractor in recognizing earlier that it could not meet payload because of bottlenecks and acknowledging that an "impossible schedule needed to be worked" resulting in more realistic scheduling. As of 1999, Segment 32 was headed by Lt. Col. Mike Rhodes (the only Air Force officer who had been in divisional leadership throughout the two-year rollout and installation process, though Col. Steve Wojcicki was acting chief for Segment 5 for a few months in 1999).

Segment 3

Segment 3 primarily involves a hardware development effort.

Segment 4

The Segment 4 Command and Control Segment provides the infrastructure that manages the interfaces between the NRO's ground- and space-based resources. The segment is the latest in a series of C&C architectures and has the responsibility for managing not only the next generation of resources, but also the legacy components. As such, the segment is highly dependent on changes that are being flowed into the existing systems and for ensuring that current capabilities are not "deplenished" (i.e., the user will not see existing capabilities disappear that were not planned to disappear). In general a rigid configuration management (CM) process mitigates this "deplenishment" risk.

Unfortunately, experience has shown that below a certain level of CM control, changes can be made to a "derived requirement" or an "imple-mentation" that will not necessarily drive a higher-level RFC (request for change) that would be assessed for impact. But these lower CM-level changes could significantly affect end-user satisfaction if they are not incorporated into follow-on systems. This risk was much more difficult for the developers to mitigate because the drivers for this risk were deemed to be outside the span of control of the development segment. Therefore this risk was assigned to a "watch" category at the segment level, but some proactive steps were initiated to help support the mitigation of this risk. A key mitigation initiative was to more fully integrate the development team into the operational environment where team members would gain first-hand knowledge of most of the changes that had the potential to impact the follow-on developments. Although this effort did not capture all the lower level changes, nor changes that had been incorporated before the mitigation plan was instantiated, it did capture a majority of the potential impacts. Perhaps more importantly, the identification and quantification of the risk alerted senior management to the fact that changes that they were not privy to, because of the CM level of change, were being incorporated and presented as a significant risk to future users and complaints could ripple through the most senior levels of the NRO.

The Segment 4 Command and Control Segment's performance is highly dependent on very sophisticated algorithms. In all instances the parameters that drive these algorithms are provided to Segment 4 by the interfacing segments. In some unique instances the interfacing segment also provides the models and equations. These data deliveries are typically provided by periodic database deliveries to Segment 4. As the interfacing segments mature through their development effort the definition and granularity of their knowledge of their design also changes, which causes the data, models, and/or equations to further perturbate. These "as-built" changes also ripple into the C&C architecture in the form of data drive changes. As these changes occur later in the development cycles their impact can be many fold more significant to the receiving segment.

The attention to detail needed to assure that the data-base deliveries adequate to support Segment 4 development and testing was not consistent across the numerous delivering segments. A number of risks were opened to address each of the delivering segments, but is discussed here as one generic risk. Initially there was an attempt to manage this risk at the segment level because the resources required to ensure the quality of the delivered data resided with numerous other program managers. The segment put this risk on a "watch" list, but also took some proactive mitigation steps by working with the delivering segments to help audit and quality-check the data prior to delivery.

In 1997, the program embarked on a path to change the methodology by which it would manage its Operations and Maintenance (O&M) process. Up to this point the O&M activities and the development activities were separated into different organizational elements under different contracts.

Due in part to this segregation, the processes were inherently expensive and provided an easy avenue for "deplenishments" to occur. To address the concern over diverging baselines, an Integrated Development and Maintenance Organization (IDMO) was developed. The IDMO would adsorb the maintenance functions traditionally managed by the operational site and integrate them into the development organization. The intent was to gain the synergy available through a single reduced staff that would manage a consolidated maintenance and development effort.

The advent of an IDMO was not readily embraced by the O&M organization, whose members believed that it took away some of their flexibility to utilize level-of-effort (LOE) resources to address the "good idea du jour" and required a scheduling discipline that was contrary to their existing business practices. In addition, their maintenance budget would be turned over to development.

It was the availability of budget that resulted in the identification of the first IDMO risk. The risk was that the original O&M program might not have budgeted for sufficient resources to support the new architecture that was being delivered. If the financial resources were inadequate then the probability of retaining critical skills and achieving the segment's required availability was problematic.

As the details of the risk were developed it turned out that there was indeed a significant budget shortfall. By providing this early identification the management team was able to provide a budget wedge and secure the funding needed to acquire the key resource and meet the availability requirements.

Circa March 1998, the Segment 4 Command and Control Segment Program suffered a major setback when it failed to successfully meet its pre-ship review (PSR) milestone. The PSR was the control gate that signified that the segment had successfully completed its development efforts at the factory and was ready to make the transition to an integration, checkout, and test (IC&T) environment at the operational facility.

The development efforts leading up to the PSR had been tracked as one of first segment risks since August 1997 when the pilot Risk Management program was initiated. Mitigation plans had been put in place that included enhanced metrics collection and reporting as well as focus teams to concentrate on key technical drivers. In spite of the increased emphasis and attention placed on this effort and repeated warnings by the government team, the contractor's program manager neglected to adhere to or enforce the requisite programmatic rigor; the PSR failed.

The PSR failure resulted in a significant replan of the program and the development of a more detailed risk mitigation plan. Key aspects of the mitigation plan were the replacement of critical management personnel, the adoption of a more rigorous and insightful scheduling methodology, the conduct of CAIV (cost as an independent variable) trades to regain cost and schedule margin, the development of phased delivery schedules, incremental operability/functionality sell-off, and increased emphasis on early and informal interface testing.

Many of the functions of the Segment 4 Command and Control Segment are accomplished by the use of what is called engineering software (ES/W) code that supports specific engineering or analytical functions. Although any engineering code is suppose to be non-mission-critical in nature, over time the legacy operational systems have become dependent upon ES/W to conduct day-to-day operations and have elevated it to criticality. One of the earliest risks identified by the segment was the potential that there was some ES/W in use that the current development effort was not going to re-deliver as CM controlled development code-or worse yet it would not be available as ES/W that the users of the follow-on systems would need based on their dependence of the same ES/W functionality in the legacy systems.

Segment 5

While Segment 5 continued with a primary focus on contractor Risk Management efforts, the division chief and other Segment 5 members collected and brought to the attention of the ESRT Segment 5 risks, involving monthly government/contractor discussions on the status of their risks from a government perspective. The Segment 5 contractor caused a major schedule slip. This event required the program director to apply for additional funds and time to remedy the slip, and led him to announce to all his division chiefs that he "wanted everyone to put their cards on the table," that he "only wanted to go once for resourcing support," and that he really needed "full information now." However, still having not engaged in its own government Risk Management process, less than a year later Segment 5 encountered yet another major schedule slip. Since that time, division leadership has changed. Segment 5 joined Segments 3 and 4 under the newly reorganized IDS program.

Segments

• ALS - Airborne Link Segment
• CGS - Common Ground Segment
• COS - Communication Operations Segment
• CCS - Communications Support Segment
• ESS - Exploitation Support Segment
• EPS - Enhanced Processing Segment
• GSIL - Ground Segment Integration Lab
• HES - Hardcopy Exploitation Segment
• MPS - Mission Planning Segment
• MIS - Mission Intelligence Segment
• NIS - National Input Segment
• RS - Receive Segment
• SES - Softcopy Exploitation Segment
• SIS - SCI Isolation Segment
• SBS - Senior Blade Segment
• SJS - Senior Jade Segment
• SSM - Senior Span Segment
• SSS - Senior Span Segment
• SSS - System Support Segment
• TIS - Tactical Input Segment