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).
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.