The U.S. Air Force has experienced many acquisition program failures—cost overruns, schedule delays, system performance problems, and sustainability concerns—over program lifetimes. A key contributing factor is the lack of sufficient technical knowledge within the Air Force concerning the systems being acquired to ensure success. This workshop was charged with examining this issue.
In addressing Task 1 of the terms of reference (see the Overview), the committee recognized early on that it would be important to clearly define the term “technical baseline,” because it appears to mean different things to different people and programs. According to Richard Roca, director emeritus of the Johns Hopkins University Applied Physics Laboratory, the technical baseline has many individual elements, including system designs, interface controls, system models, development and operational data, architecture, cost data, performance data, risk analyses, operational processes, and training requirements. However, rather than focus on the individual elements, for purposes of this workshop the committee chose to focus on the uses to which the information could be put, defining the technical baseline and, similarly, defining “owning the technical baseline.”
Technical baseline: Data and information that provides the program office knowledge to establish, trade-off, verify, change, accept, and sustain functional capabilities, design characteristics, affordability, schedule, and quantified performance parameters at the chosen level of the system hierarchy.
Owning the technical baseline: Air Force program managers and personnel have sufficient technical knowledge of their engineering development programs to ensure program success by making informed, timely, and independent decisions to manage cost, schedule, and performance risk while ensuring disciplined program execution. Owning the technical baseline allows the Air Force to respond knowledgeably and have minimal disruption to mission success.
In this sense, “owning” does not necessarily mean buying the technical data or other necessary information. According to Claude Bolton, Jr., executive-in-residence at the Defense Acquisition University, the term does
mean, in part, having ready access to the data and information necessary for engaging in critical assessments and analyses, and the government being smart enough to understand the baseline completely and know what parts of the baseline it needs to validate the contractors’ product. In the opinion of Michael Griffin, former administrator of the National Aeronautics and Space Administration, it is critical that the government have sufficient technical information about—and the competence to understand—the critical cost, schedule, and performance trade-offs that were made in the course of establishing the technical baseline; that the government understands what the alternative approaches were and why they were not selected; and that the government agrees with the decisions that have been made.
In the opinion of Gary Kyle, former Air Force contracting executive and president of Persistent Agility, the “government team” is a part of the “acquisition team,” as defined in Federal Acquisition Regulation 1.102(c):
The Acquisition Team consists of all participants in Government acquisition including not only representatives of the technical, supply, and procurement communities but also the customers they serve, and the contractors who provide the products and services.
By “government team,” the committee means a team of experts who may be government employees, either civil service or military, or who may be employees of federally funded research and development centers (FFRDCs) (and similar entities such as university affiliated research centers) or independent contractors (but not the prime on the contract).
According to Jon Ogg, former chief engineer at Air Force Materiel Command (AFMC), the composition of the government team may vary from program to program, but the key is that they are all trusted to put the government’s interests first in acquisition program decisions. Thus, the committee treated “owning the technical baseline” as a euphemism for having competent and informed government program office personnel and contracted technical support that possess the knowledge, skills, and abilities to effectively execute their programs.
Beginning in the mid-1990s, there was a series of initiatives within the Department of Defense (DoD), and the Air Force in particular, to reform acquisition processes with the intention to improve efficiency and speed the delivery of weapon systems to the warfighter. The general thrust was to reduce government hands-on oversight of acquisition programs, reduce or remove the government’s role as system integrator, and give industry contractors more flexibility and responsibility for program execution. Secretary of Defense William Perry began the process with a shift away from reliance on military specifications and standards in the mid-1990s, prompted by the defense industry campaigning on the platform that onerous military specifications and standards were adding 20-30 percent additional cost to programs but added little to the effectiveness of the final system. In the opinion of one of the participants, Jon Ogg, many of the best practices that served to guide the way that both the government and industry engineers operated were discarded during this time, and now, when there are no comparable commercial specifications or standards available, industry and government engineers are forced to relearn them—through costly trial and error in many cases.
At the same time, an acquisition approach known as total system performance responsibility (TSPR) was initiated to reduce non-value-added government involvement and transfer government tasks to the contractor (with minimal government oversight) in order to gain efficiencies. The idea was that by properly specifying end-item performance requirements, the desired outcome could be attained without imposing particular design approaches or detailed process requirements on contractors. The TSPR approach was used by the Air Force to justify downsizing its acquisition workforce and reducing the number of core functions—in particular, engineering functions—within its program offices by shifting responsibility to industry.
The Principal Deputy Under Secretary of the Air Force for Acquisition’s “Lightning Bolts” of the late 1990s and early 2000s, a series of initiatives created to reform the Air Force acquisition and sustainment processes, also worked against sustaining and strengthening key acquisition functions, particularly engineering. System program offices (SPOs) were instructed to reduce personnel to a maximum of 150 personnel, with the notion that the
appropriate role of the government program office personnel was to maintain “insight” on contracts rather than “oversight.” This led to a major downsizing of the acquisition workforce, with engineering taking the brunt of the reductions, due in part to the belief that if a competent government team, proper insight, correct metrics, adequate funding, and appropriate contract incentives were in place, the contractor team would successfully execute the program.
Many program managers (PMs) of that era viewed government engineering’s role as generating the system requirements (Systems Requirements Document or Performance Specification) from the User’s Operational Requirements Document. These would then be placed on the development contract, and the government would step back and let industry’s engineering workforce deliver. In many quarters, this was interpreted as directing government functional experts to take a “hands-off” approach to managing the technical aspects of the program. In the view of Ogg, the position espoused by senior leadership was that the government should not insert itself into the day-to-day execution of the contract but instead monitor the contractor’s performance and reward or penalize the contractor accordingly to ensure that DoD receives the execution performance and product required. In Gary Kyle’s experience, the proper definition of “insight” included in the contract was essential to establishing the proper framework for programs that allowed for proper government team engagement and successful TSPR implementation.
Principal Deputy Under Secretary of the Air Force for Acquisition Darleen Druyun testified to Congress on March 17, 1999:
The USAF is making great strides in decreasing our acquisition workforce. TSPR served to allow the USAF the opportunity to downsize. In 1997, the Air Force re-evaluated its core functions governing systems engineering, reducing the core functions from 20 to 10. Re: under TSPR we have reduced POs from 242 to 20 (ref F117). The new Program Office functions include Requirements, Direction, Budgeting, Contracting, Product Acceptance, and Security. Giving contractors total system performance responsibility, using performance-based requirements, eliminating military specs and standards, and relying on contractor data and metrics are all examples of reforms that have resulted from a change in philosophy from government oversight [involvement] to government insight [monitoring].1
Another change to the Air Force engineering workforce came in the mid-2000s with the reorganization of AFMC into wings, groups, squadrons, and flights (W/G/S/F), in the process doing away with SPOs and moving the “ownership” of the program office functional staffs (most notably engineers) to the PMs in charge. In the opinion of one senior Air Force leader who attended the first session, this significantly hampered the functional leads across AFMC’s three acquisition centers within the Command—that is, the Aeronautical Systems Center, the Air Armament Center, and the Electronic Systems Center—from performing their role to train, organize, and equip.2
Prior to this W/G/S/F reorganization and personnel realignment, AFMC’s engineering leads could move engineers across programs as needed, working collaboratively with the program office PMs to provide engineers with the breadth of experience required to function effectively as subject-matter experts or lead/chief engineers. The functional leads could also decide what additional training or education was required for each individual to better prepare him/her for assignments of higher responsibility or to sharpen or augment competencies to effectively function in his/her current role. This organize-and-equip function by the AFMC’s three acquisition center engineering staffs came to a halt under the W/G/S/F construct as PMs now owned the positions and could make reassignments independent of approval or input from the home offices. The effect was, in Ogg’s view, that movement of personnel by these respective center engineering leads across programs became stalled.
Jon Ogg submits that these “streamlining initiatives” of the mid-1990s through the turn of the century contributed to the atrophy of the technical workforce at AFMC. Furthermore, another participant, Michael Griffin,
1 Summary of prepared statement of Darleen A. Druyun, Principal Deputy Assistant Secretary of the Air Force for Acquisition and Management, before the Senate Armed Services Committee Readiness and Management Support Subcommittee, Subject: Air Force Acquisition Reform, March 17, 1999.
2 During this time period, Air Force Materiel Command (AFMC) had three separate acquisition centers: the Aeronautical Systems Center, the Air Armament Center, and the Electronic Systems Center. The AFMC subsequently reorganized again in 2012, and all three acquisition centers were consolidated into a single Air Force Life Cycle Management Center under AFMC. A separate acquisition center for space—called the Space and Missile Center—remained outside of AFMC under the Air Force Space Command.
argued that even PMs came to not understand the technical problems in their programs. Griffin also believes that systems engineering came to be viewed by the Air Force strictly in terms of process. The result, in his estimation, was that the larger issues concerning what the system design should be—and why it should be that way—no longer received the level of attention that had been required in prior generations.
The weakening of the technical workforce was acknowledged by Air Force senior leadership, and in the past 10-15 years, efforts have been under way across the Air Force to “shore up engineering,” beginning with Secretary of the Air Force Roche’s revitalization of systems engineering in 2002 and continuing with initiatives such as Operational Safety, Suitability, and Effectiveness; Life Cycle Systems Engineering; and the Systems Engineering Assessment Model. In addition, according to Ogg, DoD has restarted the use of selective military specifications and standards to help guide industry and its own engineering workforce with proven practices and processes. David Walker, Deputy Assistant Secretary of the Air Force for Science, Technology, and Engineering, noted that within the past year the Chief of Staff of the Air Force and the Secretary of the Air Force have signed off on a policy3 to rebuild technical capability, establish standards, and understand core competencies and gaps. However, despite these recent efforts, according to several participants Jorge Gonzales at AFLCMC, who has the responsibility for the career development of Air Force engineers, also has to negotiate with PEOs to move engineers to support programs. Basically, they argued, he does not have complete authority. Bolton noted that there is both a structural concern and a workforce concern that ultimately will need to be addressed. In commenting on this, Bud Boulter, from SAF/AQR, described to the workshop participants a recent CSAF and SECAF directive that attempts to clarify this topic.
A few workshop participants commented after the discussion with Dr. Walker that past policies have resulted in a situation where the Air Force in many cases does not retain enough technical information about its acquisition programs (and, even with outside help from FFRDCs and independent systems engineering and technical assistance contractors, does not have enough qualified people who understand the technical information) to control costs and make smart acquisition choices through the program life cycle. The question is, what is the appropriate balance between the notion of government as system integrator on one extreme and the TSPR approach, in which government’s role in the management of the system is minimized, on the other?
As Col Robert Strasser, system program manager, B-2 Division, believes, the Air Force must own the technical baseline for long-term continuity of operations. Over the past two decades, he argued, the Air Force has gone from oversight, to insight, to out-of-sight with its lack of program ownership. Col Strasser also noted that the government should own the technical baseline because contractor experts die, retire, and move to other programs (or refuse to relocate if the prime contractor moves a facility).
Task 2 in the terms of reference implies that challenges inherent in owning the technical baseline are not just engineering issues but extend to larger aspects of acquisition. In Chapter 2, the observations from several participants are presented about the status of owning the technical baseline in the Air Force in the following categories: programs, leadership and culture, workforce, funding, contracting, and policies and processes. Finally, suggested terms of reference for a potential follow-on study (Task 3 in the terms of reference) are provided in Appendix C.
3 U.S. Air Force, Air Force Engineering Enterprise Strategic Plan 2014-2024, May 2014.