Background Human spaceflight at NASA began in the 1960s with the Mercury and  Gemini programs leading up to the Apollo moon landings. After the last  lunar landing, Apollo 17, in 1972, NASA shifted its attention to low earth  orbit operations with human spaceflight efforts that included the Space  Shuttle and International Space Station programs through the remainder  of the 20th century. In the early 2000s, NASA once again turned its  attention to cislunar and deep space destinations, and in 2005 initiated  the Constellation program, a human exploration program that was  intended to be the successor to the Space Shuttle. The Constellation  program was canceled, however, in 2010 due to factors that included cost  and schedule growth and funding gaps. Following Constellation, the National Aeronautics and Space  Administration Authorization Act of 2010 directed NASA to develop a  Space Launch System, to continue development of a crew vehicle, and  prepare infrastructure at Kennedy Space Center to enable processing  and launch of the launch system. To fulfill this direction, NASA formally  established the SLS program in 2011. Then, in 2012, the Orion project  transitioned from its development under the Constellation program to a  new development program aligned with SLS. To transition Orion from  Constellation, NASA adapted the requirements from the former Orion  plan with those of the newly created SLS and the associated ground  systems programs. In addition, NASA and the European Space Agency  agreed that it would provide a portion of the service module for Orion.  Figure 1 provides details about the heritage of each SLS hardware  element and its source as well as identifies the major portions of the  Orion crew vehicle. The EGS program was established to modernize the Kennedy Space  Center to prepare for integrating hardware from the three programs as  well as processing and launching SLS and Orion and recovery of the  Orion crew capsule. EGS is made up of nine major components,  including: the Vehicle Assembly Building, Mobile Launcher, Launch  Control Center and software, Launch Pad 39B, Crawler-Transporter,  Launch Equipment Test Facility, Spacecraft Offline Processing, Launch  Vehicle Offline Processing, and Landing and Recovery. See figure 2 for  pictures of the Mobile Launcher, Vehicle Assembly Building, Launch Pad  39B, and Crawler-Transporter. NASA’s Exploration Systems Development (ESD) organization is  responsible for directing development of the three individual human  spaceflight programs—SLS, Orion, and EGS—into a human space  exploration system. The integration of these programs is key because all  three systems must work together for a successful launch. The integration  activities for ESD’s portfolio occur at two levels in parallel throughout the  life of the programs: as individual efforts to integrate the various elements  managed within the separate programs and as a joint effort to integrate  the three programs into an exploration system. The three ESD programs support NASA’s long term goal of sending  humans to distant destinations, including Mars. NASA’s approach to  developing and demonstrating the technologies and capabilities to  support their long term plans for a crewed mission to Mars includes three  general stages of activities—Earth Reliant, Proving Ground, and Earth  Independent. Earth Reliant: From 2016 to 2024, NASA’s planned exploration is  focused on research aboard the International Space Station. On the  International Space Station, NASA is testing technologies and  advancing human health and performance research that will enable  deep space, long duration missions. Proving Ground: From the mid-2020s to early-2030s, NASA plans to  learn to conduct complex operations in a deep space environment  that allows crews to return to Earth in a matter of days. Primarily  operating in cislunar space—the volume of space around the moon  featuring multiple possible stable staging orbits for future deep space  missions—NASA will advance and validate capabilities required for  humans to live and work at distances much farther away from our  home planet, such as on Mars. Earth Independent: From the early-2030s to the mid-2040s, planned  activities will build on what NASA learns on the space station and in  deep space to enable human missions to the vicinity of Mars, possibly  to low-Mars orbit or one of the Martian moons, and eventually the  Martian surface. The first launch of the integrated ESD systems, EM-1, is a Proving  Ground mission. EM-1 is planned as an uncrewed test flight currently  planned for no earlier than October 2019 that will fly about 70,000  kilometers beyond the moon. The second launch, Exploration Mission 2  (EM-2), which will utilize an evolved SLS variant with a more capable  upper stage, is also a Proving Ground mission planned for no later than  April 2023. EM-2 is expected to be a 10- to 14-day crewed flight with up  to four astronauts that will orbit the moon and return to Earth to  demonstrate the baseline Orion vehicle capability. NASA eventually plans  to develop larger and more capable versions of the SLS to support  Proving Ground and Earth Independent missions after EM-2. As noted above, in April 2017 we found that given the combined effects of  ongoing technical challenges in conjunction with limited cost and  schedule reserves, it was unlikely that the ESD programs would achieve  the November 2018 launch readiness date. We recommended that NASA  confirm whether the EM-1 launch readiness date of November 2018 was  achievable, as soon as practicable but no later than as part of its fiscal  year 2018 budget submission process. We also recommended that NASA  propose a new, more realistic EM-1 date if warranted. NASA agreed with  both recommendations and stated that it was no longer in its best interest  to pursue the November 2018 launch readiness date. Further, NASA  stated that, in fall 2017, it planned to establish a new launch readiness  date. Subsequently, in June 2017, NASA sent notification to Congress  that EM-1’s recommended launch date would be no earlier than October  2019. The life cycle for NASA space flight projects consists of two phases— formulation, which takes a project from concept to preliminary design, and  implementation, which includes building, launching, and operating the  system, among other activities. NASA further divides formulation and  implementation into pre-phase A through phase F. Major projects must  get approval from senior NASA officials at key decision points before they  can enter each new phase. The three ESD programs are completing  design and fabrication efforts prior to beginning Phase D system  assembly, integration and test, launch and checkout. Figure 3 depicts  NASA’s life cycle for space flight projects. NASA’s Integration  Approach Offers  Some Benefits but  Complicates  Oversight and Impairs  Independence NASA’s approach for integrating and assessing programmatic and  technical readiness, executed by ESD, differs from prior NASA human  spaceflight programs. This new approach offers some cost and potential  efficiency benefits. However, it also brings challenges specific to its  structure. In particular, there are oversight challenges because only one  of the three programs, Orion, has a cost and schedule estimate for EM-2.  NASA is already contractually obligating money on SLS and EGS for EM- 2, but the lack of cost and schedule baselines for these programs will  make it difficult to assess progress over time. Additionally, the approach  creates an environment of competing interests because it relies on dual- hatted staff to manage technical and safety aspects on behalf of ESD  while also serving as independent oversight of those same areas. Integration Approach  Differs from Past Human  Spaceflight Programs NASA is managing the human spaceflight effort differently than it has in  the past. Historically, NASA used a central management structure to  manage human spaceflight efforts for the Space Shuttle and the  Constellation programs. For example, both the Shuttle and Constellation  programs were organized under a single program manager and used a  contractor to support integration efforts. Additionally, the Constellation  program was part of a three-level organization—the Exploration Systems  Mission Directorate within NASA headquarters, the Constellation  program, and then projects, including the launch vehicle, crew capsule,  ground systems, and other lunar-focused projects, managed under the  umbrella of Constellation. Figure 4 illustrates the three-level structure  used in the Constellation program. In the Constellation program, the programmatic workforce was distributed  within the program and projects. For example, systems engineering and  integration organizations—those offices responsible for making separate  technical designs, analyses, organizations and hardware come together  to deliver a complete functioning system—were embedded within both the  Constellation program and within each of the projects. NASA’s current approach is organized with ESD, rather than a contractor,  as the overarching integrator for the three separate human spaceflight  programs—SLS, Orion, and EGS. ESD manages both the programmatic  and technical cross-program integration, and primarily relies on personnel  within each program to implement its integration efforts. Exploration  Systems Integration, an office within ESD, leads the integration effort  from NASA headquarters. ESD officials stated that this approach is  similar to that used by the Apollo program, wherein the program was also  managed out of NASA headquarters. Within Exploration Systems  Integration, the Cross-Program Systems Integration sub-office is  responsible for technical integration and the Programmatic and Strategic  Integration sub-office is responsible for integrating the financial, schedule,  risk management, and other programmatic activities of the three  programs. The three programs themselves perform the hardware and  software integration activities. This organizational structure that consists  of two levels is shown in figure 5. ESD is executing a series of six unique integration-focused programmatic  and technical reviews at key points within NASA’s acquisition life cycle,  as shown in figure 6, to assess whether NASA cost, schedule, and  technical commitments are being met for the three-program enterprise. These reviews cover the life cycle of the integrated programs to EM-1,  from formulation to readiness to launch. Some of these reviews are  unique to ESD’s role as integration manager, For example, ESD  established two checkpoints—Design to Sync in 2015 and Build to Sync  in 2016. The purpose of Design to Sync was to assess the ability of the  integrated preliminary design to meet system requirements, similar to a  preliminary design review and the purpose of Build to Sync was to assess  the maturity of the integrated design in readiness for assembly,  integration, and test, similar to a critical design review (CDR). At both  events, NASA assessed the designs as ready to proceed. Key  participants in these integration reviews include ESD program personnel  and the Cross-Program Systems Integration and Programmatic and  Strategic Integration staff that are responsible for producing and  managing the integration activities. ESD’s Integration  Approach Offers Some  Cost Avoidance and  Potential Efficiency Gains ESD’s integration approach offers some benefits in terms of cost  avoidance relative to NASA’s most recent human spaceflight effort, the  Constellation program. NASA estimated it would need $190 million per  year for the Constellation program integration budget. By comparison,  between fiscal years 2012 and 2017, NASA requested an average of  about $84 million per year for the combined integration budgets of the  Orion, SLS, EGS, and ESD. This combined average of about $84 million  per year represents a significant decrease from the expected integration  budget of $190 million per year under the Constellation program. In  addition, as figure 7 shows, NASA’s initial estimates for ESD’s required  budget for integration are close to the actuals for fiscal years 2012-2017.  NASA originally estimated that ESD’s budget for integration would require  approximately $30 million per year. ESD’s integration budget was less  than $30 million in fiscal years 2012 and 2013 and increased to about $40  million in fiscal year 2017—an average of about $30 million a year. According to NASA officials, some of the cost avoidance can be attributed  to the difference in workforce size. The Constellation program’s systems  engineering and integration workforce was about 800 people in 2009, the  last full year of the program; whereas ESD’s total systems engineering  and integration workforce in 2017 was about 500 people, including staff  resident in the individual programs. ESD officials also stated that, in addition to cost avoidance, their  approach provides greater efficiency. For example, ESD officials said that  decision making is much more efficient in the two-level ESD organization  than Constellation’s three-level organization because the chain of  command required to make decisions is shorter and more direct. ESD  officials also indicated that the post-Constellation elimination of redundant  systems engineering and integration staff at program and project levels  contributed to efficiency. Additionally, they stated that program staff are  invested in both their respective programs and the integrated system  because they work on behalf of the programs and on integration issues  for ESD. Finally, they said another contribution to increased efficiency  was NASA’s decision to establish SLS, Orion, and EGS as separate  programs, which allowed each program to proceed at its own pace. One caveat to this benefit, however, is that ESD’s leaner organization is  likely to face challenges to its efficiency in the integration and test phases  of the SLS, Orion, and EGS programs. We analyzed the rate at which  ESD has reviewed and approved the different types of launch operations  and ground processing configuration management records for integrated  SLS, Orion, and EGS operations, and found that the process is  proceeding more slowly than ESD anticipated. For example, as figure 8  illustrates, ESD approved 403 fewer configuration management records  than originally planned in the period from March 2016 through June 2017.  According to an ESD official, the lower-than-planned approval rate  resulted from the time necessary to establish and implement a new  review process as well as final records being slower to arrive from the  programs for review than ESD anticipated. Additionally, the official stated  that the records required differing review timelines because they varied in  size and scope. As figure 8 shows, ESD originally expected the number of items that  needed review and approval to increase and create a “bow wave” during  2017 and 2018. In spring 2017, ESD re-planned its review and approval  process and flattened the bow wave. The final date for review completion  is now aligned with the new planned launch readiness date of no earlier  than October 2019, which added an extra year to ESD’s timeframe to  complete the record reviews. While the bow wave is not as steep as it  was under the original plan, ESD will continue to have a large number of  records that require approval in order to support the launch readiness  date. An ESD official stated that NASA had gained experience managing  such a bow wave as it prepared for Orion’s 2014 exploration flight test  launch aboard a Delta IV rocket and as part of the Constellation  program’s prototype Ares launch in 2009, but acknowledged that ESD will  need to be cautious that its leaner staff is not overwhelmed with  documentation, which could slow down the review process. ESD’s Approach  Complicates Oversight  Because There Is No  Mechanism to Assess  Affordability beyond First  Mission ESD is responsible for overall affordability for SLS, Orion, and EGS, while  each of the programs develops and maintains an individual cost and  schedule baseline. The baseline is created at the point when a program  receives NASA management approval to proceed into final design and  production. In their respective baselines, as shown in table 1, SLS and  EGS cost and schedule are baselined to EM-1, and Orion’s are baselined  to EM-2. NASA documentation indicates that Orion’s baselines are tied to  EM-2 because that is the first point at which it will fulfill its purpose of  carrying crew. Should NASA determine it is likely to exceed its cost  estimate baseline by 15 percent or miss a milestone by 6 months or  more, NASA is required to report those increases and delays—along with  their impacts—to Congress. In June 2017, NASA sent notification to  Congress that the schedule for EM-1 has slipped beyond the allowed 6- month threshold, but stated that cost is expected to remain within the 15  percent threshold. NASA has not established EM-2 cost baselines or expected total life- cycle costs for SLS and EGS, including costs related to the larger and  more capable versions of SLS needed to implement the agency’s plans to  send crewed missions to Mars. GAO’s Cost Estimating and Assessment  Guide, a guidebook of cost estimating best practices developed in concert  with the public and private sectors, identifies baselines as a critical means  for measuring program performance over time and addresses how a  baseline backed by a realistic cost estimate increases the probability of a  program’s success. In addition, prior GAO work offers insight into the  benefits of how baselines enhance a program’s transparency. For  example, we found in 2009 that costs for the Missile Defense Agency’s  (MDA) ballistic missile defense system had grown by at least $1 billion,  and that lack of baselines for each block of capability hampered efforts to  measure progress and limited congressional oversight of MDA’s work.  MDA responded to our recommendation to establish these baselines and,  in 2011, we reported that MDA had a new process for setting detailed  baselines, which had resulted in a progress report to Congress more  comprehensive than the one it provided in 2009. To that end, we have made recommendations in the past on the need for  NASA to baseline the programs’ costs for capabilities beyond EM-1;  however, a significant amount of time has passed without NASA taking  steps to fully implement these recommendations. Specifically, in May  2014, we recommended that, to provide Congress with the necessary  insight into program affordability, ensure its ability to effectively monitor  total program costs and execution, and to facilitate investment decisions,  NASA’s Administrator should direct the Human Exploration and  Operations Mission Directorate to: Establish a separate cost and schedule baseline for work required to  support the SLS for EM-2 and report this information to the Congress  through NASA’s annual budget submission. If NASA decides to fly the  SLS configuration used in EM-2 beyond EM-2, establish separate life  cycle cost and schedule baseline estimates for those efforts, to  include funding for operations and sustainment, and report this  information annually to Congress via the agency’s budget submission;  and Establish separate cost and schedule baselines for each additional  capability that encompass all life cycle costs, to include operations  and sustainment, because NASA intends to use the increased  capabilities of the SLS, Orion, and ground support efforts well into the  future and has chosen to estimate costs associated with achieving the  capabilities. As part of the latter recommendation, we stated that, when NASA could  not fully specify costs due to lack of well-defined missions or flight  manifests, the agency instead should forecast a cost estimate range— including life cycle costs—having minimum and maximum boundaries and  report these baselines or ranges annually to Congress via the agency’s  budget submission. In its comments on our 2014 report, NASA partially concurred with these  two recommendations, noting that much of what it had already done or  expected to do would address them. For example, the agency stated that  establishing the three programs as separate efforts with individual cost  and schedule commitments met GAO’s intent as would its plans to track  and report development, operations, and sustainment costs in its budget  to Congress as the capabilities evolved. In our response, we stated that  while NASA’s prior establishment of three separate programs lends some  insight into expected costs and schedule at the broader program level, it  does not meet the intent of the two recommendations because cost and  schedule identified at that level is unlikely to provide the detail necessary  to monitor the progress of each block against a baseline. Further,  reporting the costs via the budget process alone will not provide  information about potential costs over the long term because budget  requests neither offer all the same information as life-cycle cost estimates  nor serve the same purpose. Life-cycle cost estimates establish a full  accounting of all program costs for planning, procurement, operations and  maintenance, and disposal and provide a long-term means to measure  progress over a program’s life span. In 2016, NASA requested closure of these recommendations, citing,  among other factors, changes to the programs’ requirements, design,  architecture, and concept of operations. However, NASA’s request did not  identify any steps taken to meet the intent of these two recommendations,  such as establishing cost and schedule baselines for EM-2, baselines for  each increment of SLS, Orion, or ground systems capability, or  documentation of life cycle cost estimates with minimum and maximum  boundaries. Further, a senior level ESD official told us that NASA does  not intend to establish a baseline for EM-2 because it is not required to do  so. The limited scope that NASA has chosen to use as the basis for  formulating the programs’ cost baselines does not provide the  transparency necessary to assess long-term affordability. Plainly,  progress cannot be assessed without a baseline that serves as a means  to compare current costs against expected costs; consequently, it  becomes difficult to assess program affordability and for Congress to  make informed budgetary decisions. NASA’s lack of action in regards to our 2014 recommendations means  that it is now contractually obligating NASA to spend billions of dollars in  potential costs for EM-2 and beyond without a baseline against which to  assess progress. For example:  in fiscal year 2016, the SLS program awarded two contracts to Aerojet  Rocketdyne: a $175 million contract for RL-10 engines to power the  exploration upper stage during EM-2 and EM-3 and a $1.2 billion  contract to restart the RS-25 production line required for engines for  use beyond EM-4, and to produce at least 4 additional RS-25  engines;  in 2017, SLS modified the existing Boeing contract upwards by $962  million for work on the exploration upper stage that SLS will use  during EM-2 and future flights; and on a smaller scale, in fiscal year 2016 the EGS program obligated  $4.8 million to support the exploration upper stage and EM-2. As illustrated by these contracting activities, the SLS program is  obligating more funds for activities beyond EM-1 than Congress directed.  Specifically, of approximately $2 billion appropriated for the SLS program,  the Consolidated Appropriations Act, 2016 directed that NASA spend not  less than $85 million for enhanced upper stage development for EM-2.  NASA has chosen to allocate about $360 million of its fiscal year 2016  SLS appropriations towards EM-2, including enhanced upper stage  development, additional performance upgrades, and payload adapters,  without a baseline to measure progress and ensure transparency. The  NASA Inspector General (IG) also recently reported that NASA is  spending funds on EM-2 efforts without a baseline in place and  expressed concerns about the need for EM-2 cost estimates. Because  NASA has not implemented our recommendations, it may now be  appropriate for Congress to take action to require EM-2 cost and  schedule baselines for SLS and EGS, and separate cost and schedule  baselines for additional capabilities developed for Orion, SLS, and EGS  for missions beyond EM-2. These baselines would be important tools for  Congress to make informed, long-term budgetary decisions with respect  to NASA’s future exploration missions, including Mars. Organizational Structure  Impairs Independence of  Engineering and Safety  Technical Oversight NASA’s governance model prescribes a management structure that  employs checks and balances among key organizations to ensure that  decisions have the benefit of different points of view and are not made in  isolation. As part of this structure, NASA established the technical  authority process as a system of checks and balances to provide  independent oversight of programs and projects in support of safety and  mission success through the selection of specific individuals with  delegated levels of authority. The technical authority process has been  used in other parts of the government for acquisitions, including the  Department of Defense and Department of Homeland Security. ESD is  organizationally connected to three technical authorities within NASA. The Office of the Chief Engineer technical authority is responsible for  ensuring from an independent standpoint that the ESD engineering  work meets NASA standards, The Office of Safety and Mission Assurance technical authority is  responsible for ensuring from an independent standpoint that ESD  products and processes satisfy NASA’s safety, reliability, and mission  assurance policies, and The Office of Chief Health and Medical technical authority is  responsible for ensuring from an independent standpoint that ESD  programs meet NASA’s health and medical standards. These NASA technical authorities have delegated responsibility for their  respective technical authority functions directly to ESD staff. According  to NASA’s project management requirements, the program or project  manager is ultimately responsible for the safe conduct and successful  outcome of the program or project in conformance with governing  requirements and those responsibilities are not diminished by the  implementation of technical authority. ESD has established an organizational structure in which the technical  authorities for engineering and safety and mission assurance (S&MA) are  dual hatted to also serve simultaneously in programmatic positions. The  chief engineer technical authority also serves as the Director of ESD’s  Cross Program System Integration Office and the S&MA technical  authority also serves as the ESD Safety and Mission Assurance  Manager. In their programmatic roles for ESD, the individuals manage  resources, including budget and schedule, to address engineering and  safety issues. In their technical authority roles, these same individuals are  to provide independent oversight of programs and projects in support of  safety and mission success. Having the same individual simultaneously  fill both a technical authority role and a program role creates an  environment of competing interests where the technical authority may be  subject to impairments in their ability to impartially and objectively assess  the programs while at the same time acting on behalf of ESD in  programmatic capacities. This duality makes them more subject to  program pressures of cost and schedule in their technical authority roles.  Figure 9 describes some of the conflicting roles and responsibilities of  these officials in their two different positions. The concurrency of duties leaves the positions open to conflicting goals of  safety, cost, and schedule and increases the potential for the technical  authorities to become subject to cost and schedule pressures. For  example:  the dual-hatted engineering and S&MA technical authorities serve on  decision-making boards both in technical authority and programmatic  capacities, making them responsible for providing input on technical  and safety decisions while also keeping an eye on the bottom line for  ESD’s cost and schedule; and  the technical authorities are positioned such that they have been the  reviewers of the ESD programmatic areas they manage—in essence,  “grading their own homework.” For example, at ESD’s Build to Sync  review in 2016, the engineering and S&MA technical authorities  evaluated the areas that they manage in their respective capacities as  ESD Director of Cross Program System Integration and ESD Safety  and Mission Assurance Manager. This process relied on their abilities  as individuals to completely separate the two hats—using one hand to  put on the ESD hat and manage technical and safety issues within  programmatic cost and schedule constraints and using the other hand  to take off that hat and assess the same issues with an independent  eye. NASA officials identified several reasons why the dual-hat structure works  for their purposes. Agency officials stated that one critical factor to  successful dual-hatting is having the “right” people in those dual-hat  positions—that is, personnel with the appropriate technical knowledge to  do the work and the ability to act both on behalf of ESD and independent  of it. Officials also indicated that technical authorities retain independence  because their technical authority reporting paths and performance  reviews are all within their technical authority chain of command rather  than under the purview of the ESD chain of command. Additionally, agency officials said that dual-hat roles are a commonplace  practice at NASA and cited other factors in support of the approach,  including that:  it would not be an efficient use of resources to have an independent  technical authority with no program responsibilities because that  person would be unlikely to have sufficient program knowledge to  provide useful insight and could slow the program’s progress; a technical authority that does not consider cost and schedule is not  helpful to the program because it is unrealistic to disregard those  aspects of program management; a strong dissenting opinion process is in place and allows for issues to  be raised through various levels to the Administrator level within  NASA; and ESD receives additional independent oversight through three NASA  internal organizations—the independent review teams that provide  independent assessments of a program’s technical and programmatic  status and health at key points in its life cycle; the NASA Engineering  and Safety Center that conducts independent safety and mission  success-related testing, analysis, and assessments of NASA’s high- risk projects; and the Aerospace Safety Advisory Panel (ASAP) that  independently oversees NASA’s safety performance. These factors that NASA officials cite in support of the dual-hat approach  minimize the importance of having independent oversight and place ESD  at risk of fostering an environment in which there is no longer a balance  between preserving safety with the demands of maintaining cost and  schedule. The Columbia Accident Investigation Board (CAIB) report—the  result of an in-depth assessment of the technical and organizational  causes of the Columbia accident—concluded that NASA’s organization  for the Shuttle program combined, among other things, all authority and  responsibility for schedule, cost, safety, and technical requirements and  that this was not an effective check and balance. The CAIB report  recommended that NASA establish a technical authority to serve  independently of the Space Shuttle program so that employees would not  feel hampered to bring forward safety concerns or disagreements with  programmatic decisions. The Board’s findings that led to this  recommendation included a broken safety culture in which it was difficult  for minority and dissenting opinions to percolate up through the hierarchy;  dual Center and programmatic roles vested in one person that had  confused lines of authority, responsibility, and accountability and made  the oversight process susceptible to conflicts of interest; and oversight  personnel in positions within the program, increasing the risk that these  staffs’ perspectives would be hindered by too much familiarity with the  programs they were overseeing. ESD officials stated that they had carefully and thoughtfully implemented  the intent of the CAIB; they said they had not disregarded its finding and  recommendations but instead established a technical authority in such a  way that it best fit the context of ESD’s efforts. These officials did  acknowledge, though, that the dual hat approach does not align with the  CAIB report’s recommendation to separate programmatic and technical  authority or with NASA’s governance framework. Further, over the course  of our review, we spoke with various high-ranking officials outside and  within NASA who expressed some reservations about ESD’s dual hat  approach. For example: The former Chairman of the CAIB stated that, even though the ESD  programs are still in development, he believes the technical authority  should be institutionally protected against the pressures of cost and  schedule and added that NASA should never be lulled into dispensing  of engineering and safety independence because human spaceflight  is an extremely risky enterprise. Both NASA’s Chief Engineer and Chief of S&MA acknowledged there  is inherent conflict in the concurrent roles of the dual hats, while also  expressing great confidence in the ESD staff now in the dual roles. NASA’s Chief of S&MA indicated that the dual-hat S&MA structure is  working well within ESD, but he believes these dual-hatted roles may  not necessarily meet the intent of the CAIB’s recommendation  because the Board envisioned an independent safety organization  completely outside the programs. NASA’s Chief Engineer stated that he believes technical authority  should become a separate responsibility and position as ESD moves  forward with integration of the three programs and into their operation  as a system. As these individuals made clear, ensuring the ESD engineering and  S&MA technical authorities remain independent of cost and schedule  conflicts is key to human spaceflight success and safety. Along these  lines, the ASAP previously conveyed concerns about NASA’s  implementation of technical authority that continue to be valid today. In  particular, the ASAP stated in a 2013 report that NASA’s technical  authority was working at that time in large measure due to the well- qualified, strong personnel that had been assigned to the process. The  panel noted, however, that should there be a conflict or weakening of the  placement of strong individuals in the technical authority position, this  could introduce greater risk into a program. Although a current ASAP  official stated she had no concerns with ESD’s present approach to  technical authority, the panel’s prior caution remains applicable, and the  risk that the ASAP identified earlier could be realized if not mitigated by  eliminating the potential for competing interests within the ESD  engineering and S&MA positions. NASA is currently concluding an assessment of the implementation of the  technical authority role to determine how well that function is working  across the agency. According to the official responsible for leading the  study, the assessment includes examining the evolution of the technical  authority role over the years and whether NASA is spending the right  amount of funds for those positions. NASA expects to have  recommendations in 2017 on how to improve the technical authority  function, but does not expect to address the dual hat construct. A  principle of federal internal controls is that an agency should design  control activities to achieve objectives and respond to risks, which  includes segregation of key duties and responsibilities to reduce the risk  of error, misuse, or fraud. By overlapping technical authority and  programmatic responsibilities, NASA will continue to run the risk of  creating an environment of competing interests for the ESD engineering  and S&MA technical authorities. ESD Risk Posture  Has Improved, but  Key Risk Areas  Remain for the  Integration Effort Despite the development and integration challenges associated with a  new human spaceflight capability, ESD has improved its overall cross- program risk posture over the past 2 years. Nonetheless, it still faces key  integration risk areas within software development and verification and  validation (V&V). Both are critical to readiness for EM-1 because software  acts as the “brain” that ties SLS, Orion, and EGS together in a functioning  body, while V&V ensures the integrated body works as expected. The  success of these efforts forms the foundation for a launch, no matter the  date of EM-1. ESD’s Cross-Program  Risk Posture Has  Improved We have previously reported on individual SLS, Orion, and EGS program  risks that were contributing to potential delays within each program. For  example, in July 2016, we found that delays with the European Service  Module—which will provide services to the Orion crew module in the form  of propulsion, consumables storage, and heat rejection and power—could  potentially affect the Orion program’s schedule. Subsequently, in April  2017, we found that those delays had worsened and were contributing to  the program likely not making a November 2018 launch readiness date.  All three programs continue to manage such individual program risks,  which is to be expected of programs of this size and complexity. The  programs may choose to retain these risks in their own risk databases or  elevate them to ESD to track mitigation steps. A program would elevate a  risk to ESD when decisions are needed by ESD management, such as a  need for additional resources or requirement changes. Risks with the  greatest potential for negative impacts are categorized as top ESD risks.  In addition to these individual programs risks that are elevated to ESD,  ESD is also responsible for overseeing cross-program risks that affect  multiple programs. An example of a cross-program risk is the potential for  delayed delivery of data from SLS and Orion to affect the EGS software  development schedule. ESD has made progress reducing risks over the last 2 years, from the  point of the Design to Sync preliminary design review equivalent for the  integrated programs to the Build to Sync critical design review equivalent.  As figure 10 illustrates, ESD has reduced its combined total of ESD and  cross program risks from 39 to 25 over this period, and reduced the  number of high risks from about 49 percent of the total to about 36  percent of the total. The ESD risk system is dynamic, with risks coming into and dropping out  of the system over time as development proceeds and risk mitigation is  completed. A total of 29 of the 39 risks within the ESD risk portfolio were  removed from the register and 15 risks were added to the register  between November 2014, prior to Design to Sync, and March 2017, after  Build to Sync. Examples of risks removed over this time period include  risks associated with late delivery of Orion and SLS ground support  equipment hardware to EGS and establishing a management process to  identify risks stemming from the programs being at differing points in  development. Nine risks remained active in the system over the 2-year period we  analyzed, and NASA experienced delays in the length of time it  anticipated it would take to complete mitigation of the majority of these  nine risks. Three of these nine risks that have remained active in the risk  system since before Design to Sync are still classified as high risk; the  remaining six are classified as medium risk. Mitigation is an action taken  to eliminate or reduce the potential severity of a risk, either by reducing  the probability of it occurring, by reducing the level of impact if it does  occur, or both. ESD officials indicated a number of reasons why risks  could take longer to mitigate. For instance, risks with long-term mitigation  strategies may go for extended periods of time without score changes. In  addition, ESD may conduct additional risk assessments and determine  that certain risks need to be reprioritized over time and that resources  should be focused towards higher risks. In addition, some risk mitigation  steps are tied to hardware delivery and launch dates, and as those delay,  the risk mitigation steps will as well. As illustrated in table 2, we found that  six of these nine risks were related to software and V&V and represented  some of the primary causes in terms of estimated completion delays. On  average, the estimated completion dates for these six risks were delayed  about 16 months. In addition, the two V&V risks that have remained  active since before Design to Sync were still considered top ESD risks as  of March 2017 when we completed this analysis. Software Development Is  a Key Risk Area Facing  the Integration Effort Software development is one of the top cross-program technical issues  facing ESD as the programs approach EM-1. Software is a key enabling  technology required to tie the human spaceflight systems together.  Specifically, for ESD to achieve EM-1 launch readiness, software  developed within each of the programs has to be able to link and  communicate with software developed in other programs in order to  enable a successful launch. Furthermore, software development  continues after hardware development and is often used to help resolve  hardware deficiencies discovered during systems integration and test. ESD has defined six critical paths—the path of longest duration through  the sequence of activities that determines the program’s earliest  completion date—for its programs to reach EM-1, and three are related to  software development. These three software critical paths support  interaction and communication between the systems the individual  programs are developing—SLS to EGS software, Orion to EGS software,  and the Integrated Test Laboratory (ITL) facility that supports Orion  software and avionics testing as well as some SLS and EGS testing. The  other critical paths are development of the Orion crew service module,  SLS core stage, and the EGS Mobile Launcher. Because of software’s  importance to EM-1 launch readiness, ESD is putting a new method in  place to measure how well these software efforts are progressing along  their respective critical paths. To that end, it is currently developing a set  of “Key Progress Indicators” milestones that will include baseline and  forecast dates. Officials indicated that these metrics will allow ESD to  better track progress of the critical path software efforts toward EM-1  during the remainder of the system integration and test phase. ESD  officials have indicated, however, that identifying and establishing  appropriate indicators is taking longer than expected and proving more  difficult than anticipated. One of the software testing critical paths, the ITL, has already  experienced delays that slipped completion of planned software testing  from September 2018 until March 2019, a delay of 6 months. Officials told  us that this delay was primarily due to a series of late avionics and  software deliveries by the European Space Agency for Orion’s European  Service Module. The delay in the Orion testing in turn affects SLS and  EGS software testing and integration because those activities are  informed by the completion of the Orion software testing. Furthermore,  some EGS and SLS software testing scheduled to be conducted within  the ITL has been re-planned as a result of the Orion delays. The Orion program indicates that it has taken action to mitigate ITL issues  as they arise. For example, the European Service Module avionics and  software delivery delay opened a 125-day gap between completion of  crew module testing and service module testing. Orion officials indicated  that the program had planned to proceed directly into testing of the  integrated crew module and service module software and systems, but  the integrated testing cannot be conducted until the service module  testing is complete. As illustrated by figure 11, to mitigate the impact of the delay, Orion  officials indicated that the program filled this gap by rescheduling other  activities at the ITL such as software integration testing and dry runs for  the three programs. These adjustments narrowed the ITL schedule gap  from 125 days to 24 days. The officials stated that they will continue to  adjust the schedule to eliminate gaps. The other two software critical paths—SLS to EGS and Orion to EGS  software development—are also experiencing software development  issues. In July 2016, for example, we found that delays in SLS and Orion  requirements development, as well as the programs’ decisions to defer  software content to later in development, were delaying EGS’s efforts to  develop ground command and control software and increasing cost and  schedule. Furthermore, ESD reports show that delays and content deferral in the  Orion and SLS software development continue to affect EGS software  development and could delay launch readiness. For example, the EGS  data throughput risk that both ESD and EGS are tracking is that the  ground control system software is currently not designed to process the  amount of telemetry it will receive and provide commands to SLS and  ground equipment as required during launch operations. EGS officials  stated that, if not addressed, the risk is that if there is a SLS or Orion  failure, the ground control system software may not display the necessary  data to launch operations technicians. EGS officials told us that the  reason for the mismatch between the data throughput being sent to the  ground control software and how much is it designed to process is that no  program was constrained in identifying its data throughput. These officials  stated that retrospectively, they should have established an interface  control document to manage the process. The officials also stated that  the program is taking steps to mitigate this risk, including defining or  constraining the data parameters and buying more hardware to increase  the amount of data throughput that can be managed, but will not know if  the risk is fully mitigated until additional data are received and analyzed  during upcoming tests. For example, EGS officials stated that the green  run test will provide additional data to help determine if the steps they are  taking address this throughput risk. If the program determines the risk is  not fully mitigated and additional software redesign is required, it could  lead to schedule delays. ESD officials overseeing software development acknowledged that  software development for the integrated systems is a difficult task and  said they expect to continue to encounter and resolve software  development issues during cross-program integration and testing. As we  have found in past reviews of NASA and Department of Defense  systems, software development is a key risk area during system  integration and testing. For example, we found in April 2017 that software  delivery delays and development problems with the U.S. Air Force’s F-35  program experienced during system integration and testing were likely to  extend that program’s development by 12 months and increase its costs  by more than $1.7 billion. Verification and Validation  Will Remain Key Risk Area  to Monitor as NASA  Establishes and Works  towards New Launch  Readiness Date Verification and validation (V&V) is acknowledged by ESD as a top cross- program integration risk that NASA must monitor as it establishes and  works toward a new EM-1 launch readiness date. V&V is a culminating  development activity prior to launch for determining whether integrated  hardware and software will perform as expected. V&V consists of two  equally important aspects:  verification is the process for determining whether or not a product  fulfills the requirements or specifications established for it at the start  of the development phase; and  validation is the assessment of a planned or delivered system ability  to meet the sponsor’s operational need in the most realistic  environment achievable during the course of development or at the  end of development. Like software development and testing, V&V is typically complex and  made even more so by the need to verify and validate how SLS, Orion,  and EGS work together as an integrated system. ESD’s V&V plans for the integrated system have been slow to mature. In  March 2016, leading up to ESD’s Build to Sync review, ESD performed  an audit of V&V-related documentation for the program CDRs and ESD  Build to Sync. The audit found that 54 of 257 auditable areas (21 percent)  were not mature enough to meet NASA engineering policy guidance for  that point in development. According to ESD documentation, there were  several causes of this immaturity, including incomplete documentation  and inconsistent requirements across the three programs. NASA officials  told us that our review prompted ESD to conduct a follow-up and track the  status of these areas. As of June 2017, 53 of the 54 auditable areas were  closed, which means these areas are at or have exceeded CDR level of  maturity—6 months after Build to Sync was completed. NASA officials  indicated that the remaining one auditable area, which is related to the  test plan for the integrated communication network, was closed in August  2017. Nevertheless, other potential V&V issues still remain. According to ESD  officials, distributing responsibility for V&V across the three programs has  created an increased potential for gaps in testing. If gaps are discovered  during testing, or if integrated systems do not perform as planned, money  and time for modifications to hardware and/or software may be  necessary, as well as time for retesting. This could result in delayed  launch readiness. As a result, mature V&V plans are needed to ensure  there are no gaps in planned testing. ESD officials indicated that a NASA  Engineering and Safety Center review of their V&V plans, requested by  ESD’s Chief Engineer to address concerns about V&V planning, would  help define the path forward for maturing V&V plans. V&V issues add to  cost and schedule risk for the program because they may take more time  and money to resolve than ESD anticipates. In some cases, they may  have a safety impact as well. For example, if the structural models are not  sufficiently verified, it increases flight safety risks. Each of the programs  bases its individual analyses on the models of the other programs. As a  result, any deficiencies discovered in one can have cascading effects  through the other systems and programs. We will continue to monitor  ESD’s progress mitigating risks as NASA approaches EM-1. Conclusions NASA is at the beginning of the path leading to human exploration of  Mars. The first phase along that path, the integration of SLS, Orion, and  EGS, is likely to set the stage for the success or failure of the rest of the  endeavor. Establishing a cost and schedule baseline for NASA’s second  mission is an important initial step in understanding and gaining support  for the costs of SLS, Orion, and EGS, not just for that one mission but for  the Mars plan overall. NASA’s ongoing refusal to establish this baseline is  short-sighted, because EM-2 is part of a larger conversation about the  affordability of a crewed mission to Mars. While later stages of the Mars  mission are well in the future, getting to that point in time will require a  funding commitment from the Congress and other stakeholders. Much of  their willingness to make that commitment is likely to be based on the  ability to assess the extent to which NASA has met prior goals within  predicted cost and schedule targets. Furthermore, as ESD moves SLS, Orion, and EGS from development to  integrated operations, its efforts will reach the point when human lives will  be placed at risk. Space is a severe and unforgiving environment; the  Columbia accident showed the disastrous consequences of mistakes. As  the Columbia Accident Investigation Board report made clear, a  program’s management approach is an integral part of ensuring that  human spaceflight is as safe and successful as possible. The report also  characterized independence as key to achieving that safety and success.  ESD’s approach, however, tethers independent oversight to program  management by vesting key individuals to wear both hats at the same  time. As a result, NASA is relying heavily on the personality and capability  of those individuals to maintain independence rather than on an  institutional process, which diminishes lessons learned from the Columbia  accident. Matter for  Congressional  Consideration We are making the following matter for congressional consideration. Congress should consider requiring the NASA Administrator to direct the  Exploration Systems Development organization within the Human  Exploration and Operations Mission Directorate to establish separate cost  and schedule baselines for work required to support SLS and EGS for  Exploration Mission 2 and establish separate cost and schedule baselines  for each additional capability that encompass all life cycle costs, to  include operations and sustainment. (Matter for Consideration 1) Recommendation for  Executive Action We are making the following recommendation to the Exploration Systems  Development organization. Exploration Systems Development should no longer dual-hat individuals  with both programmatic and technical authority responsibilities.  Specifically, the technical authority structure within Exploration Systems  Development should be restructured to ensure that technical authorities  for the Offices of the Chief Engineer and Safety and Mission Assurance  are not fettered with programmatic responsibilities that create an  environment of competing interests that may impair their independence.  (Recommendation 1) Agency Comments  and Our Evaluation NASA provided written comments on a draft of this report. These  comments are reprinted in appendix II. NASA also provided technical  comments, which were incorporated as appropriate. In responding to a draft of our report, NASA partially concurred with our  recommendation that the Exploration Systems Development (ESD)  organization should no longer dual-hat individuals with both programmatic  and technical authority responsibilities. Specifically, we recommended  that the technical authority structure within ESD should be restructured to  ensure that technical authorities for the Offices of Chief Engineer and  Safety and Mission Assurance are not fettered with programmatic  responsibilities that create an environment of competing interests that  may impair their independence. In response to this recommendation,  NASA stated that it created the technical authority governance structure  after the Columbia Accident Investigation Board report and that the dual- hat technical authority structure has been understood and successfully  implemented within ESD. NASA recognized, however, that as the  program moves from the design and development phase into the  integration and test phase, it anticipates that the ESD environment will  encounter more technical issues that will, by necessity, need to be quickly  evaluated and resolved. NASA asserted that within this changed  environment it would be beneficial for the Engineering Technical Authority  role to be performed by the Human Exploration and Operations Chief  Engineer (who reports to the Office of the Chief Engineer). NASA stated  that over the next year or so, it would solicit detailed input from these  organizations and determine how to best support the program while  managing the transition to integration and test and anticipated closing this  recommendation by September 30, 2018. We agree that NASA should solicit detailed input from key organizations  within the agency as it transitions away from the dual hat technical  authority structure to help ensure successful implementation of a new  structure. In order to implement this recommendation, however, NASA  needs to assign the technical authority role to a person who does not  have programmatic responsibilities to ensure they are independent of  responsibilities related to cost and schedule performance. To fulfill this,  this person may need to reside outside of the Human Exploration and  Operations Mission Directorate and NASA should solicit input from the  Office of the Chief Engineer when making this decision to ensure that  there are no competing interests for the technical authority. Moreover, in  its response, NASA does not address the dual-hat technical authority role  for Safety and Mission Assurance. We continue to believe that similar  changes for this role would be appropriate as well. Further, in response to this recommendation, NASA makes two  statements that require additional context.  First, NASA stated that GAO’s  recommendation was focused on overall Agency technical authority  management. While this review involved meeting with the heads of the  Office of Chief Engineer and the Office of Safety and Mission Assurance,  the scope of this review and the associated recommendation are limited  to ESD. Second, NASA stated “As you found, we agree that having the  right personnel in senior leadership positions is essential for a Technical  Authority to be successful regardless of how the Technical Authority is  implemented.” To clarify, this perspective is attributed to NASA officials in  our report and does not represent GAO’s position. We are sending copies of this report to NASA’s Administrator and to  appropriate congressional committees. In addition, the report is available  at no charge on the GAO website at http://www.gao.gov. If you or your staff have any questions about this report, please contact  me at (202) 512-4841 or chaplainc@gao.gov. Contact points for our  Offices of Congressional Relations and Public Affairs may be found on  the last page of this report. GAO staff who made key contributions to this  report are listed in appendix III. Appendix I: Objectives, Scope, and  Methodology This report assesses (1) the benefits and challenges of the National  Aeronautics and Space Administration’s (NASA) approach for integrating  and assessing the programmatic and technical readiness of Orion, SLS,  and EGS; and (2) the extent to which the Exploration Systems  Development (ESD) organization is managing cross-program risks that  could affect launch readiness. To assess the benefits and challenges of NASA’s approach for integrating  and assessing the programmatic and technical readiness of its current  human spaceflight programs relative to other selected programs, we  reviewed and analyzed NASA policies governing program and technical  integration, including cost, schedule, and risk. We obtained and analyzed  ESD implementation plans to assess the role of ESD in cross program  integration of the three programs. We reviewed the 2003 Columbia  Accident Investigation Board’s Report’s findings and recommendations  related to culture and organizational management of human spaceflight  programs as well as the Constellation program’s lessons learned report.  We reviewed detailed briefings and documentation from Cross-Program  Systems Integration and Programmatic and Strategic Integration teams  explaining ESD’s approach to programmatic and technical integration,  including implementation of systems engineering and integration. We  interviewed NASA officials to discuss the benefits and challenges of  NASA’s integration approach and their roles and responsibilities in  managing and overseeing the integration process. We met with the  technical authorities and other representatives from the NASA Office of  the Chief Engineer, Office of Safety and Mission Assurance, Crew Health  and Safety, addressed cost and budgeting issues with the Chief Financial  Officer and discussed and documented their roles in executing and  overseeing the ESD programs. We also interviewed outside subject  matter experts to gain their insight of ESD’s implementation of NASA’s  program management policies on the independent technical authority  structure. Additionally, we compared historical budget data from the now- cancelled Constellation program to ESD budget data and quantified  systems engineering and integration budget savings through preliminary  design review, the point at which the Constellation program was  cancelled. In addition, we assessed the scope of NASA’s funding  estimates for the second exploration mission and beyond against best  practices criteria outlined in GAO’s cost estimating guidebook. We  assessed the reliability of the budget data obtained using GAO reliability  standards as appropriate. We compared the benefits and challenges of  NASA’s integration approach to that of other complex, large-scale  government programs, including NASA’s Constellation and the  Department of Defense’s Missile Defense Agency programs. To determine the extent to which ESD is managing cross-program risks  that could affect launch readiness, we obtained and reviewed NASA and  ESD risk management policies; detailed monthly and quarterly briefings;  and documentation from Cross-Program Systems Integration and  Programmatic and Strategic Integration teams explaining ESD’s approach  to identifying, tracking, and mitigating cross-program risks. We reviewed  Cross-Program Systems Integration systems engineering and systems  integration areas as well as Programmatic and Strategic Integration risks,  cost, and schedule to determine what efforts presented the highest risk to  cross program cost and schedule. We conducted an analysis of ESD’s  risk dataset and the programs’ detailed risk reports, which list program  risks and their potential schedule impacts, including mitigation efforts to  date. We examined risk report data from Design to Sync to Build to Sync  and focused our analyses to identify risks with current mitigation plans to  determine if risk mitigation plans are proceeding on schedule. We did not  analyze risks that were categorized under “Accept,” “Candidate,”  “Research,” “Unknown,” or “Watch” because these risks were not  assigned an active mitigation plan by ESD. To assess the reliability of the  data, we reviewed related documentation and interviewed knowledgeable  agency officials. We determined the data was sufficiently reliable for  identifying risks and schedule delays associated with those risks. We  examined ESD integrated testing facility schedules to determine the  extent to which they can accommodate deviation in ESD’s planned  integrated test schedule. We also interviewed program and contractor  officials on technical risks, potential impacts, and risk mitigation efforts  underway and planned. We conducted this performance audit from August 2016 to October 2017  in accordance with generally accepted government auditing standards.  Those standards require that we plan and perform the audit to obtain  sufficient, appropriate evidence to provide a reasonable basis for our  findings and conclusions based on our audit objectives. We believe that  the evidence obtained provides a reasonable basis for our findings and  conclusions based on our audit objectives. Appendix II: Comments from the National  Aeronautics and Space Administration Appendix III: GAO Contact and Staff  Acknowledgments GAO Contact Staff  Acknowledgments In addition to the contact name above, Molly Traci (Assistant Director),  LaTonya Miller, John S. Warren Jr., Tana Davis, Laura Greifner, Roxanna  T. Sun, Samuel Woo, Marie P. Ahearn, and Lorraine Ettaro made key  contributions to this report.
NASA is undertaking a trio of closely related programs to continue human space exploration beyond low-Earth orbit. All three programs (SLS, Orion, and EGS) are working toward a launch readiness date of no earlier than October 2019 for the first test flight. Each program is a complex technical and programmatic endeavor. Because all three programs must work together for launch, NASA must integrate the hardware and software from the separate programs into a working system capable of meeting its goals for deep space exploration. The House Committee on Appropriations report accompanying H.R. 2578 included a provision for GAO to assess the progress of NASA's human space exploration programs. This report assesses (1) the benefits and challenges of NASA's approach for integrating these three programs and (2) the extent to which cross-program risks could affect launch readiness. GAO examined NASA policies, the results of design reviews, risk data, and other program documentation and interviewed NASA and other officials. The approach that the National Aeronautics and Space Administration (NASA) is using to integrate its three human spaceflight programs into one system ready for launch offers some benefits, but it also introduces oversight challenges. To manage and integrate the three programs—the Space Launch System (SLS) vehicle; the Orion crew capsule; and supporting ground systems (EGS)—NASA's Exploration Systems Development (ESD) organization is using a more streamlined approach than has been used with other programs, and officials GAO spoke with believe that this approach provides cost savings and greater efficiency. However, GAO found two key challenges to the approach: The approach makes it difficult to assess progress against cost and schedule baselines. SLS and EGS are baselined only to the first test flight. In May 2014, GAO recommended that NASA baseline the programs' cost and schedule beyond the first test flight. NASA has not implemented these recommendations nor does it plan to; hence, it is contractually obligating billions of dollars for capabilities for the second flight and beyond without establishing baselines necessary to measure program performance. The approach has dual-hatted positions, with individuals in two programmatic engineering and safety roles also performing oversight of those areas. As the image below shows, this presents an environment of competing interests. These dual roles subject the technical authorities to cost and schedule pressures that potentially impair their independence. The Columbia Accident Investigation Board found in 2003 that this type of tenuous balance between programmatic and technical pressures was a contributing factor to that Space Shuttle accident. NASA has lowered its overall cross-program risk posture over the past 2 years, but risk areas—related to software development and verification and validation, which are critical to ensuring the integrated body works as expected—remain. For example, delays and content deferral in Orion and SLS software development continue to affect ground systems software development and could delay launch readiness. GAO will continue to monitor these risks.