[NASA Logo]

NASA Procedures and Guidelines

This Document is Obsolete and Is No Longer Used.
Check the NODIS Library to access the current version:
http://nodis3.gsfc.nasa.gov


NPR 7120.5C
Effective Date: March 22, 2005
Cancellation Date: November 03, 2008
Responsible Office: KA

NASA Program and Project Management Processes and Requirements


SPECIAL NOTICE:

Chapter 6 of this NPR has been cancelled by NPR 7120.5D, March 6, 2007.
Chapter 4 & 5 of this NPR has been cancelled by NPR 7120.8.
The remaining portions of this NPR are still in effect for Non-Space Flight programs and projects.
.

Table of Contents

NASA Interim Directive to NPR 7120.5C, NASA Program and Project Management Processes and Requirements, NM 7120-40 - NM 7120-40 Superseded by the NASA FAR Supplement (48 CFR 1834,Earned Value Management System) 11/13/2006; NPR 7120.5D 03/06/2007; and active sections from 7120.5C

Change Log

Preface

P.1 Purpose
P.2 Applicability
P.3 Authority
P.4 References
P.5 Cancellation

Chapter 1. Overview of the NASA Environment

1.1 Introduction
1.2 NASA's Strategic Framework
1.3 Defining Programs and Projects
1.4 NASA's Investment Areas
1.5 Categorization of NASA Projects
1.6 Roles and Responsibilities
1.7 Overview of Management Process
1.8 Document Structure

Figure 1-1: The Flow from Strategy to Implementation
Figure 1-2: Program and Project Oversight Structure
Figure 1-3: Chapter Structure with Detail for Formulation Section

Table 1-1: Project Categorization Schema
Table 1-2: Governing PMCs and Review Team Leads

Chapter 2. Program Management Requirements

SPECIAL NOTICE: Use Chapter 2 for Non-Space Flight and Non-Research and Technology Program Management. Use NPR 7120.5D for Space Flight and use NPR 7120.8 for Research and Technology

2.1 Four-Part Program Management Process
2.2 Program Formulation
2.3 Program Approval
2.4 Program Implementation
2.5 Program Evaluation

Figure 2-1: The NASA Continuous Risk Management Process

Table 2-1: Program Decision Reviews
Table 2-2: Key Program Documents and Product Maturity by Decision Review

Chapter 3. Common Project Management Requirements

SPECIAL NOTICE: Use Chapter 3 for Non-Space Flight and Non-Research and Technology Program Management. Use NPR 7120.5D for Space Flight and use NPR 7120.8 for Research and Technology

3.1 Four-Part Project Management Process
3.2 Project Formulation
3.3 Project Approval
3.4 Project Implementation
3.5 Project Evaluation

Figure 3-1. Systems Analysis and Trade Study Activities During Formulation
Figure 3-2: The Continuous Risk Management Process Steps

Table 3-1. Key Project Documents and Product Maturity by Decision Review

Chapter 4. Basic and Applied Research Portfolios

SPECIAL NOTICE: Chapter 4 of this NPR has been cancelled by NPR 7120.8, February 5, 2008. 4.1 Four-Part Portfolio Management Process
4.2 Portfolio Formulation
4.3 Portfolio Approval
4.4 Portfolio Implementation
4.5 Portfolio Evaluation

Figure 4-1 Basic and Applied Research Portfolio Lifecycle

Chapter 5. Advanced Technology Development Projects

SPECIAL NOTICE: Chapter 5 of this NPR has been cancelled by NPR 7120.8, February 5, 2008. 5.1 Four-Part Project Management Process
5.2 Project Formulation
5.3 Project Approval
5.4 Project Implementation
5.5 Project Evaluation

Figure 5-1. Advanced Technology Development project lifecycle

CHAPTER 6. Flight Systems and Ground Support Projects

SPECIAL NOTICE: Chapter 6 of this NPR has been cancelled by NPR 7120.5D, March 6, 2007.

6.1 Four-Part Project Management Process
6.2 Project Formulation
6.3 Project Approval
6.4 Project Implementation
6.5 Project Evaluation

Table 6-1. Project Decision Reviews
Table 6-2. Key Project Documents and Product Maturity by Decision Review

Chapter 7. Institutional Projects

7.1 Four-Part Project Management Process
7.2 Project Formulation
7.3 Project Approval
7.4 Project Implementation
7.5 Project Evaluation

Figure 7-1: Capital Assets Project Life Cycle for Institutional Projects
Figure 7-2: Non-Capital Assets Project Life Cycle for Institutional Projects

Table 7-1 Institutional Projects Management Requirements Summary

Appendix A. Formulation Authorization Document Template

A.1 Program FAD Title Page
A.2 Project FAD Title Page
A.3 Template

Appendix B. Program Commitment Agreement Template

B.1 Title Page
B.2 Template

Appendix C. Program Plan Template

C.1 Title Page

Appendix D. Project Plan Template

D.1 Instructions
D.2 Title Page
D.3 Template

Appendix E. CADRe Data Requirement Description

Appendix F. Technology Readiness Levels

Appendix G. Program and Project Products Maturity Matrix

Appendix H. Reviews

H.1 Independent Reviews
H.2 Project Milestone Reviews (PMR)
H.3 Engineering Peer Reviews (EPR)

Table H-1 Assessment Criteria
Table H-2 Program (Chapter 2)
Table H-3 Common Project (Chapter 3)
Table H-4 Flight Systems and Ground Support Projects (Chapter 6)

Appendix I. Index

Appendix J. Flight Systems and Ground Support Project WBS

Appendix K. Compliance Matrix

Appendix L. References

Appendix M. Definitions

Appendix N. Acronyms

Appendix O. NPR 7120.5C Requirements Deviations and Waivers


Preface


P.1 Purpose

This document establishes the management system for implementing NASA Policy Directive (NPD) 7120.4, Program/Project Management. This management system governs the formulation, approval, implementation, and evaluation of all Agency programs and projects.

P.2 Applicability

  1. This NPR applies to NASA Headquarters and NASA Centers, including Component Facilities, the Jet Propulsion Laboratory, and service providers to the extent specified in their contracts with NASA.
  2. This NPR shall apply to all NASA programs; and to projects identified by programs, including basic and applied research, advanced technology development, flight systems and ground support, and institutional investments. It is recognized that these projects contain lower level project activities managed by designated responsible organizations. The cognizant Mission Directorates, Mission Support Offices, programs, projects, or Centers shall flow down the requirements of this document as appropriate.
  3. The requirements of this document are applicable to all Programs and Projects currently in formulation as of the effective date. Programs and Projects in Implementation Phase at the time of approval of NPR 7120.5C can request permission from the appropriate Governing Program Management Committee (PMC) to be allowed to continue operating under NPR 7120.5B. However, for programs or projects in Implementation Phase, all or portions of this document can be levied on the program or project at the discretion of the Mission Directorate, Mission Support Office, or Center.

P.3 Authority

  1. 42 U.S.C. 2473(c)(1), Section 203(c) (1) of the National Aeronautics and Space Act of 1958, as amended.

P.4 References

  1. NPD 1000.1, NASA Strategic Plan
  2. NPR 1000.2, NASA Strategic Management Handbook
  3. NPD 1000.3, NASA Organization
  4. NPD 7120.4, Program/Project Management

P.5 Cancellation

NPR 7120.5B, NASA Program and Project Management Processes and Requirements, dated November 21, 2002.

/s/ Rex Geveden
NASA Chief Engineer


Change History

Change #
Date
Description
1
03/06/2007
Chapter 6 of this NPR has been cancelled by NPR 7120.5D, March 6, 2007


Chapter 1. Overview of the NASA Environment

1.1 Introduction

1.1.1 This document defines the management requirements for formulating, approving, implementing, and evaluating NASA programs and projects1. Because NASA is a diverse organization whose mission was established for multiple scientific and engineering purposes under the National Aeronautics and Space Act of 1958 (the "Space Act"), this document is intended to reflect the flexibility needed to serve the many types of NASA programs and projects. At the same time, it is intended to build a cohesive management approach, while retaining the creative freedom to innovate techniques that improve safety and quality, and reduce the cost of expanded knowledge and of delivered products and services.


1 For basic and applied research, the project-equivalent level of management is portfolio management.

1.1.2 NASA is an agency in the process of transforming itself. This transformation is largely being driven by the new, unifying Vision for Space Exploration, but it is also a response to the recognition of the need to manage more efficiently, and with greater management responsibility and accountability2. Not forgotten too, are the Columbia Accident Investigation Board (CAIB) recommendations for improving responsibility and accountability in the area of safety. The establishment of an Independent Technical Authority (ITA) represents a direct response to the CAIB recommendations3, and a critical shift in NASA's program and project management strategy relating to safe and reliable operations. This document implements NASA's revised management strategy by defining responsibilities, accountabilities, and efficiency-enhancing measures in the form of program and project management requirements.


2 Specific recommendations in this area are described in the Report of the Roles, Responsibilities, and Structures ("Clarity") Team.
3 Specifically, Columbia Accident Investigation Board (CAIB) recommendation R7.5-1.

1.1.3 This chapter provides an introduction to NASA's strategic framework for managing programs and projects, NASA's investment areas, manager roles and responsibilities, and management strategies. Subsequent chapters deal with program management requirements, project management requirements common to all projects, and investment area-specific management requirements.

1.1.4 In this document, a requirement is identified by "shall," a good practice by "should," permission by "may," or "can," expectation by "will," and descriptive material by "is."

1.2 NASA's Strategic Framework

1.2.1 NASA's Strategic Management System, described in detail in the NASA Strategic Management Handbook (NPR 1000.2), consists of integrated activities that enable the Agency to establish and execute strategy, make decisions, allocate resources, formulate and implement programs and projects, and measure its performance. There are four parts in the strategic management process: Strategic and Performance Planning, Budget Formulation and Implementation, Implementing Strategies and Execution, and Performance Evaluation and Reporting. These activities involve all levels of the Agency, from the individual employee's performance and evaluation plans to Agency-level strategic planning and evaluation activities.

1.2.2 National priorities broadly dictate NASA's strategic direction. At the Agency level, strategic planning is documented in the NASA Strategic Plan (NPD 1000.1) and the associated Mission Directorate Strategies and Mission Support Office Functional Leadership Plans. The Strategic Plan specifies Agency-level goals derived from these priorities, objectives supporting each goal, and the themes responsible for achieving each of the objectives. The Mission Directorates and Mission Support Offices provide the details of how each organization will help achieve Agency mission and goals. Other top-level plans address Agency supporting capabilities that require a strategic approach-- for example; the Integrated Space Plan describes NASA's long-term strategy for space, while other Agency-level plans address human capital, information technology, and facilities. NASA also produces an Annual Performance Plan containing performance measures as part of the Integrated Budget and Performance Document (IBPD).

1.2.3 The NASA Strategic Plan is designed to find a balance between the constantly evolving state of space and aeronautical science, exploration, and current space operations on the one hand, with the stability needed to successfully accomplish the Agency's broad portfolio of programs and projects on the other. The Strategic Plan links broad national priorities with specific themes, programs, and projects. This simple flow down is more complicated in practice. Programs and projects can, for example, support multiple themes. The general flow of NASA's strategy is, however, reflected in the left side of Figure 1-1.

Figure 1-1: The Flow from Strategy to Implementation

1.2.4 The Agency's budget framework is derived from the strategic framework. NASA's budget planning process is a vehicle for integrating programs and projects among the themes and Mission Directorates. It also allows financial control of Agency investments and visibility into program and project execution. The budget framework, shown in the right side of Figure 1-1, is built into NASA's integrated financial management system and leads inextricably down to project work breakdown structures (WBS). Some placeholders are provided in the budget framework to allow managers the flexibility in creating operational financial structures that best match the nature of the work being performed. New knowledge and technological capabilities influence national priorities. Over a shorter timeframe, new scientific knowledge and engineering capability may require adjustments in projects, and over the longer term, in programs, themes, strategic goals, and national priorities for NASA investments.

1.2.5 The Strategic Plan's themes are addressed by a portfolio of programs and projects. As with any portfolio, the portfolio holder tasked with selecting how best to invest must choose an allocation of cost (resources) so as to balance expected performance and risk. The NASA budget is closely linked to the Strategic Plan, and both are constructed in a manner that allows the policymaker to understand the costs, performance, and risks associated with the various thematic portfolios. This integrated picture of Agency investments is documented in the annual Integrated Budget and Performance Document.

1.2.6 Although a broad corporate strategy and the creation of theme-based collections of programs and projects are important Agency planning practices, they do not replace the critical importance of superior program and project management. Further, program and project management philosophy at NASA must reflect NASA values. Accordingly, NASA does the following:

  1. Emphasizes the safety of the public, its flight crews, workforce, and critical assets.
  2. Emphasizes the protection of the environment of Earth, other planets, and space.
  3. Relies upon individual and organizational commitment to responsibility and accountability for doing the job right the first time.
  4. Invests in and empowers an extraordinarily talented workforce to successfully execute programs and projects.
  5. Encourages innovation in program and project management to foster greater efficiency consistent with safety and sound engineering and management practices.
  6. Continually learns and implements valuable lessons from previous programs and projects.
  7. Strives to achieve maximum reasonable safety and reliability in the design and operation of NASA systems and missions.
  8. Fosters an environment that is supportive and conducive for individuals to raise and address issues of technical conscience.
  9. Integrates the principles and practices of a model diversity and equal opportunity workplace, including fairness, equity, integrity, excellence, and a respect for diversity of ideas and perspectives.

1.3 Defining Programs and Projects

1.3.1 Programs and projects are different, and require different skills and professional resources. The following definitions are used to distinguish the two:

  1. Program - a strategic investment by a Mission Directorate or Mission Support Office that has defined goals, objectives, architecture, funding level, and a management structure that supports one or more projects. A program has the following five attributes that help distinguish it from a project:
  1. Output - a program initiates projects that deliver discrete products and services to its stakeholders. A program integrates and manages these projects over time, and provides ongoing enabling systems, activities, methods, cross-cutting technologies, and feedback to projects and stakeholders.
  2. Size - a program usually contains several projects. 4 Basic and applied research programs usually contain several portfolios of investigations.
  3. Synergy - generally, projects within a program enjoy some form of synergy that relates to the program's scientific or technical goals. Synergy can also flow from similar implementing strategies. 5
  4. Longevity - programs are generally created with a long, indefinite time horizon in mind. NASA must occasionally rebaseline programs or combine related programs to increase effectiveness, but usually the original reason for creating the program survives. Contrarily, projects have a definitive beginning and end.
  5. Composition - a program is often composed of multiple project types, referred to in this document as investments areas or product lines (see the next section). A program could be designed with elements of basic and applied research portfolios, flight systems and ground support projects, and institutional elements. 6
  1. Project - a specific investment identified in a Program Plan having defined goals, objectives, requirements, lifecycle cost, a beginning, and an end. A project yields new or revised products or services that directly address NASA's strategic needs.7 They may be performed wholly in-house, by government, industry, academia partnerships, or through contracts with private industry.

4 The single-project program construct is used in special situations usually associated with long development and/or operations periods, with a very significant investment level, and where extensive interaction and integration with many contributors is required. In such cases, the manager may perform a dual role, and is responsible for completing both program and project activities.
5 The Discovery Program, for example, aims to build a discrete series of modest spacecraft with fast development times, each managed under a cost cap.
6 The Explorer Program is a good example of an especially long-lived investment with many components. Explorer Program funds have supported basic research in astronomy and space physics, the development of evolutionary technologies in support of the Explorer series of spacecraft, as well as the Explorer spacecraft development projects.
7 Project-equivalent basic and applied research portfolios are level-of-effort investments in investigations. While portfolios continue, funding for specific investigations within the portfolio may be limited to a specific number of years.

1.3.2 The Office of the Chief Engineer (OCE) and Office of the Chief Financial Officer (OCFO) maintain the official database of NASA programs and projects (including basic and applied research portfolios) known as the Master Management Mapping (M3). This list includes the designated project category as defined in Section 1.5. The database forms the structure for program and project status reporting across all Mission Directorates, Mission Support Offices, and the NASA Office of Education. (See paragraph 1.7.7.)

1.4 NASA's Investment Areas

1.4.1 Although NASA's Mission Directorates and Mission Support Offices operate under a single Strategic Plan, management practices must be designed to match the various types of NASA investments. This document distinguishes four investment areas or product lines:

  1. Basic and Applied Research - NASA's basic and applied research is funded using competitively awarded grants to universities, in-house NASA researchers, and other research institutions. When NASA funds basic and applied research intended to directly support a project, it uses cooperative agreements and contracts, or appropriate funding mechanisms for in-house NASA researchers. NASA scientists also perform research for others under the Space Act and other similar agreements. This product line is also the source of fundamental breakthroughs in our knowledge and understanding of science, and many new technologies that are used in space systems, aeronautics, and terrestrial applications, and in meeting NASA's own operational and infrastructure requirements. Basic and applied research is generally funded on a level-of-effort basis with periodic progress reviews. Results are typically peer-reviewed and reported in journals and technical reports.
  2. Advanced Technology Development - Across NASA, a substantial amount of work is done to translate new ideas generated in the laboratory into new systems that can be used to improve the performance of aircraft and spacecraft. Managers in this area typically employ spiral development or rapid prototyping practices to mature new technology in a stepwise fashion. Some of the work associated with this product line may be performed in-house with contractor support; some portion may be accomplished through grants and contracts.
  3. Flight Systems and Ground Support - This product line results in a variety of advanced aircraft, atmospheric vehicles, spacecraft, suborbital vehicles, launch vehicles, space networks, ground networks, deep space networks and ground systems in direct support of a theme or program. NASA Program and Project Managers lead the development of these flight and ground products 8, and sometimes this means working with unprecedented designs, unknown environments, and new technologies. 9 These flight and ground products are often developed via contracts with industry. Following a successful flight system and ground support investment, a spacecraft may enter a protracted period of operations and sustainment. Some of NASA's largest investments are made in this area. 10 During operations and sustainment, managers are sometimes required to oversee the work of a large number of government and contractor professionals. Flight systems and ground support projects are extremely important from a strategic point-of-view because they typically lay the foundation for future investments and desired capabilities. With the substantial opportunity for human impact, this product line most often requires an Independent Technical Authority for technical requirements to ensure safe and reliable operations.
  4. Institutional Infrastructure- To support its diverse activities, NASA invests in a complex set of supporting infrastructure developments and enhancement efforts. For example, NASA personnel manage the construction and renovation of buildings, the development of advanced communication systems, and the creation of new institutional control systems. 11 NASA personnel also manage efforts to improve the public's understanding and appreciation of science, technology, engineering, and mathematics (STEM). Institutional projects are planned, executed, and managed by NASA's Mission Support Offices. Institutional projects can be funded directly by mission programs, or indirectly through mission support budget accounts (overhead). Program and Project Managers must account for directly funded institutional projects in the estimation of life-cycle funding requirements.

8 In some cases, Principal Investigators from industry and academia act as Project Managers for development efforts with NASA personnel providing oversight.
9 Within large programs, sophisticated ground systems such as a new launch complex may be developed. These ground systems should be considered part of this product line. To meet mission goals, the delivery of a new flight product in many instances, also relies on other product lines, such as the timely maturation of an advanced technology.
10 Specific examples are Space Shuttle and International Space Station operations
11 The new Integrated Financial Management System (IFMS) is an excellent example of a major mission support investment. The effort to renovate the Vehicle Assembly Building at the Kennedy Space Center is an example of a major facility project that occurs over a long period of time.

1.4.2 Accurately placing a project in the correct investment area is important when using this document because different management requirements and oversight techniques will apply according to product line. Investment area-specific management requirements are found in subsequent chapters. The cognizant Program Manager is responsible for identifying the appropriate product line for each project.

1.5 Categorization of NASA Projects

1.5.1 NASA strives to execute all projects with excellence, but management requirements and Agency attention and oversight should track with the investment's magnitude and Agency priority.

1.5.2 Project categorization will be used extensively in the chapters that follow. 12 Most importantly, categorization defines Agency expectations of Project Managers by determining both the oversight committee and the level of detail that must be present in Program and Project Plans. This document provides a simple schema, shown in Table 1-1, to assist the Program Manager in determining the project's category from the magnitude of project's financial investment and priority. 13 In connection with the project category determination, the Project Manager is responsible for providing defensible estimates of the project's life-cycle cost and priority levels, whereas the Program Manager is responsible for concurrence. The Mission Directorate Associate Administrator (MDAA) or Mission Support Office Director (MSOD) approves the categorization of projects. Independent review teams will later confirm these estimates as the project reaches initial progress milestones.


12 In this document, the term project should be taken to mean project or portfolio, the latter label being preferred for the basic and applied research product line.
13 There is a separate NASA-wide definition of software classes within projects that complements the project categories described in this section. Software cuts across a number of systems and subsystems of varying criticality, so a project may contain one or more software classes. The requirements for the classification of NASA software are described in NPR 7150.2.

1.5.3 For purposes of project categorization, project cost is measured in real-year (i.e., budget) dollars.14 For flight systems and ground support projects, project life-cycle cost includes launch vehicle costs. Project priority depends on a number of factors:

  1. Importance of the activity (project in-line with the critical paths of the Strategic and Capability Roadmaps).
  2. Extent of international participation or joint effort with other government agencies.
  3. Uncertainty surrounding the application of new and untested technologies.
  4. Presence of nuclear materials on board.
  5. Systems being developed for human spaceflight.
  6. Spacecraft development classification (see NPR 8705.4, Risk Classification for NASA Payloads).
  7. Criticality in terms of human safety, mission success visibility, and critical NASA assets.

Table 1-1. Project Categorization Schema


14 For (level-of-effort) basic and applied research, portfolio cost is measured from two years prior to five years from the current year.

1.6 Roles and Responsibilities

1.6.1 The roles and responsibilities of senior management are defined in NPR 1000.2, the NASA Strategic Management Handbook, and NPD 1000.3, The NASA Organization. This document, along with NPD 7120.4, Program/Project Management, define the responsibilities for all program and project managers, except if in conflict with statutory or regulatory requirements. Other NASA-wide policy directives (NPDs) and procedural requirements (NPRs) have been developed for specific management, science, and engineering disciplines. Similarly, Mission Directorates, Mission Support Offices, and Centers have developed lower-level management and discipline-specific policies and procedural requirements. Program and Project Managers are responsible for reviewing these and ensuring that subordinate managers and engineers are in compliance with applicable documents.

1.6.2 As part of the strategic management process, NASA Program Managers are appointed by the Mission Directorate Associate Administrator (MDAA)15 or Mission Support Office Director (MSOD) in consultation with the Center Director if applicable.16 The Program Manager may report to the MDAA (or MSOD) or to a Center Director, but in either case must work with the Mission Directorate or Mission Support Office staff in performing assigned responsibilities. It is the responsibility of the Program Manager to develop an accurate and complete Program Plan to ensure agreement among participants on program requirements, and technical, budget, and management commitments. The Program Manager is then responsible for implementing the program.


15 Sometimes Program Manager appointments can be made by a Theme Director with the concurrence of the MDAA. Both Theme Directors and Program Managers may be assigned to Centers or to NASA Headquarters at the discretion of the MDAA.
16 For programs dedicated solely to basic and applied research, this position usually carries the title "Program Scientist."

1.6.3 Project Managers and Project Scientists are appointed by the Mission Directorate, Mission Support Office, or Center Director in consultation with the applicable Program Manager and Program Scientist. The Project Manager is responsible for developing an accurate and complete Project Plan, and then for implementing the project. The Project Scientist (or Technologist) is responsible for developing and implementing the Science and Technical Science Requirements Document.

1.6.4 The Headquarters Office of the Chief Engineer (OCE) is responsible for conducting independent reviews and for leadership of the Agency's independent assessment (IA) activities, including leadership of the Independent Program Assessment Office (IPAO) and the coordination of policy development and implementation with Center Systems Management Offices (SMOs), all of which conduct reviews. The OCE will work in coordination with the appropriate MDAA or MSOD to establish and execute independent review within the Mission Directorate or Mission Support Office. These reviews are expressly designed to provide Program and Project Managers with a source of unbiased examination and plainly articulated feedback. Review teams have a responsibility to provide Program and Project Managers with candid results, and to provide senior managers with a fair assessment of a program's or project's planning and execution. The OCE is available to answer program and project management questions, and training is available to ensure that NASA's procedures are thoroughly communicated and the necessary management skills are developed.

1.6.5 The NASA Chief Engineer, per NPD 1000.3, The NASA Organization, is the Technical Authority for the Agency, and is responsible for leading and implementing Independent Technical Authority (ITA) policies and practices per NPD 1240.4, NASA Technical Authority, and NPR 1240.1, NASA Technical Warrant System. The NASA Chief Engineer implements ITA through experts, called Technical Warrant Holders (TWHs), who are issued warrants delegating the technical responsibility, accountability, and authority to establish technical requirements so as to ensure safe and reliable operations. The purpose of ITA is to establish the technical baseline, once the high-level requirements have been defined by the Mission Directorate (or Mission Support Office). Accordingly, the TWH approves technical requirements and any variances thereto. For matters involving safe and reliable operations as related to human safety, the ITA has final decision authority. The Program or Project Manager, Independent Technical Authority, and Safety and Mission Assurance all have important roles with respect to safety, reliability, and quality of the products generated by a program or project. The individual perspectives that these three parties provide throughout a program or project establish a balance that ensures that all aspects of safety and reliability are adequately addressed.

1.7 Overview of Management Process

1.7.1 The management of programs and projects is a four-part process consisting of:

  1. Formulation - the assessment of feasibility, review, and analysis of concepts, initial risk reduction activities, assembly of teams, development of operational concepts and acquisition strategies, establishment of high-level requirements and success criteria, selection of an ITA (if applicable), and preparation of detailed plans, budgets, and schedules that are essential to the success of a program or project.
  2. Approval - the ongoing effort by responsible officials above the program and project management level to review plans and performance at key milestones and authorize continuation of the effort and progression to the next phase.
  3. Implementation - the execution of approved plans for the development and operation of products and services, and the establishment of required control systems to ensure performance to plan.
  4. Evaluation - the ongoing independent (i.e., outside the advocacy chain of the program or project) evaluation of the performance of a program or project, and incorporation of the evaluation findings to ensure adequacy of planning and execution according to plan.

1.7.2 To initiate individual programs, a responsible manager, usually designated by the MDAA or MSOD, must first prepare a program Formulation Authorization Document (FAD). A MDAA (or MSOD) has the authority to invest resources in the preparation of a program FAD. The FAD authorizes a Program Manager to initiate the planning of a new program and to perform the analyses required to formulate a sound Program Plan that contains project elements, schedules, risk assessments, and budgets. Because the creation of a new program represents a major commitment of the Agency, the FAD requires the approval of the MDAA (or MSOD). The program FAD does the following:

  1. Contains a statement of purpose for the proposed program.
  2. Defines the relationship between the program and the Agency's strategic goals and objective.
  3. Establishes the scope of work to be accomplished, including identification of all planned products and services to be delivered, highlighting those elements that are critical to achieving the stated purpose of the program.
  4. Provides an initial estimate of required resources and associated high-level schedule that includes a description of reviews required during formulation.
  5. Identifies program participants (with special emphasis on relationships with organizations external to NASA, including proposed international partnerships).

1.7.3 Another key management document is the Program Commitment Agreement (PCA). The PCA is the agreement (essentially a contract) between the MDAA (or MSOD) and the NASA Deputy Administrator that documents the program's objectives, technical performance, schedule, cost, safety, and risk factors, internal and external agreements, and independent reviews. The PCA can be considered an executive summary of the Program Plan. Project implementation within a program is not authorized until a signed PCA is on file within the OCE. A Project Manager developing a new Project Plan is acting within the structure of the Program Plan and under the authority of the PCA.

1.7.4 To ensure the appropriate level of management oversight, NASA has established a hierarchy of Program Management Committees (PMCs). One of these committees, referred to as the Governing PMC (GPMC), is assigned primary responsibility for evaluating the cost, schedule, safety, and technical content of a particular program or project to ensure that it is meeting the commitments specified in the key management documents described above. The Agency PMC is responsible for evaluating proposed programs, assessing the performance of approved programs and projects, and providing recommendations to the Deputy Administrator. The Agency PMC convenes two types of meetings: (1) decision review meetings, in which recommendations are made to the Deputy Administrator regarding whether a proposed program or project will be authorized to proceed, and (2) Quarterly Status Reports (QSRs), in which the Agency PMC is updated by each Mission Directorate (and Mission Support Offices for designated programs and projects).

1.7.5 Other PMCs are established and executed by Mission Directorates, Mission Support Offices, and Centers. As programs and projects are approved and move into implementation, the Agency PMC may delegate evaluation authority/responsibility to one of these PMCs. That decision is documented in the PCA and Program Plan. Regardless of where the GPMC resides (e.g., Agency, Mission Directorate, Mission Support Office, or Center), it is responsible for evaluating the program or project, and for providing recommendations and direction to the Program or Project Manager and, as applicable, the Center Director. For projects, the GPMC is determined by the established project category. This relationship is shown in Table 1-2.

Table 1-2 Governing PMCs and Review Team Leads

1.7.6 A NASA-led independent review process has been designed to help assure mission success and the continued ability of programs and projects to meet commitments. This review process is described in more detail in Section 2.5 for programs and in Section 3.5 for projects. Results of these independent reviews are reported to the Agency, Mission Directorates, Mission Support Offices, Center PMCs and, where appropriate, the NASA Science Council, the Mission Directorate Science Management Council (SMC), and the Institutional Committee (IC). Table 1-2 establishes the lead Independent Assessment (IA) organization based on project category. Figure 1-2 depicts the relationship of mission and mission support investments, and the oversight of these programs and projects. Programs can contain some or all of the product lines defined in Section 1.4.

Figure 1-2. Program and Project Oversight Structure

1.7.7 Another step to improve direct interaction between Program and Project Managers and senior Agency managers is the use of an Agency wide electronic "dashboard" (currently Erasmus) to report program and project status in terms of cost, technical, schedule, management, safety, and performance parameters. This ensures that consistent status information is communicated across management interfaces. 17


17 Anyone within NASA can access the system to review the status of any Theme or program, and that of many projects.

1.8 Document Structure

1.8.1 Requirements for programs organized into the four-part management process of paragraph 1.7.1 are detailed in Chapter 2. Some institutional programs have modified program management requirements identified in Chapter 7.

1.8.2 Common requirements for projects organized into the four-part management process of paragraph 1.7.1 are detailed in Chapter 3. Project Managers must also refer to their respective investment area chapter for product line-specific requirements. Flight systems and ground support Project Managers, for example, will use Chapters 3 and 6. Basic and applied research projects and some institutional projects have modified project management requirements identified in Chapters 4 and 7, respectively.

1.8.3 Each of the following chapters has the same structure and each discusses the context for the four-part management process: formulation, approval, implementation, and evaluation. In the larger chapters, both formulation and implementation are broken into major activities, for example, systems engineering. These major activities have separate subsections that convey the purpose of the activity and the activity requirements. (See Figure 1-3.) This document recognizes that many of the major activities, like systems engineering, are undeniably lifecycle processes. It also recognizes that these major activities have detailed process requirements that are fulfilled at different stages of the project cycle--that is, the tasks and focus of the activity may shift through the project cycle. Consequently, for expositional purposes, this document identifies the activity requirements under the more applicable section.

Figure 1-3. Chapter Structure with Detail for Formulation Section

1.8.4 Applicable controlling legislation, circulars, policy directives, and procedural requirements relevant to program and project management activities are cited in Appendix L.1. Although the applicable documents may not be specifically cited in the text of this document, they are provided as the authoritative sources of policy and requirements on the relevant subject. Other references are provided in Appendix L.2 for information only.


Chapter 2. Program Management Requirements

SPECIAL NOTICE: Use Chapter 2 for Non-Space Flight and Non-Research and Technology Program Management. Use NPR 7120.5D for Space Flight and use NPR 7120.8 for Research and Technology

2.1 Four-Part Program Management Process

2.1.a As a strategic management structure, the program construct is extremely important within NASA. Programs provide the critically important linkage between the Agency's ambitious goals and the projects that are the instruments for achieving them. Programs vary significantly in scope, complexity, cost, and criticality; however, a properly designed and executed program structure inevitably contributes to sound project management being embraced and practiced at lower levels. To initiate individual programs, a Mission Directorate (or Mission Support Office) shall prepare a program Formulation Authorization Document (FAD).

2.1.b The Program Manager is responsible for ensuring that program goals address the Mission Directorate Strategies and Mission Support Office Functional Leadership Plans and that the program's content, which may contain multiple product lines, addresses those program goals. The Program Manager shall be responsible for recommending to the MDAA (or MSOD) the appropriate product line for each project in his/her program. The Program Manager coordinates program content with the Mission Directorate (or Mission Support Office), provides leadership, and is responsible for the successful accomplishment of the program that meets the needs of the customer. This chapter further delineates the management requirements for programs as described in terms of the four-part management process of paragraph 1.7.1. Program Managers shall meet all requirements outlined in this chapter irrespective of the size of the program.

2.1.c The Program Manager is responsible for integration, oversight, and assistance to the program's constituent projects.18 The program management integration role varies as a function of the level of interdependence of the projects within the program. The following examples illustrate several types of programs. A single-project program (e.g., Cassini) delivers a major capability through completion of one project; in this program type, the Program Manager may also serve in the role of Project Manager and must meet the requirements applicable to both programs and projects. For a program which accomplishes its goals and objectives through completion of multiple, synergistic projects wherein each project individually provides a unique product (e.g., the Mars Program), the Program Manager ensures that the projects collectively contribute to an integrated program objective. For programs that deliver an integrated system-of-systems composed of multiple interdependent projects (e.g., International Space Station), end-to-end system integration and delivery is performed at the program level (i.e., the sum of the project deliveries does not produce the system in the absence of program integration). The program management integration role is more limited in other types of programs where the degree of interdependence is less. Examples are Discovery, in which each project stands alone in contributing to a very broad program objective; New Millennium, in which the projects are interdependent in contributing to technology validation but are not synergistically integrated; and technology programs, which can provide new capabilities for many missions. For basic and applied research programs, the integration occurs through the infusion of new knowledge, data applications, and technological advances. The Program Manager ensures that such advances influence multiple programs.


18 In this document, the term project should be taken to mean project or portfolio, the latter label being preferred for the basic and applied research product line.

2.1.d The Program Manager is responsible for the program safety, security, cost, schedule, technical performance, risk, and other management requirements contained in this chapter. The Program Manager should integrate these areas and utilize the experts from line or functional organizations to assist in program formulation and implementation.

2.1.e The Program Manager should develop a cooperative and performance-oriented team that includes the Project Managers. It is imperative that team members be mutually supporting and empower each other to do their functions with full and open communication.

2.2 Program Formulation

2.2.1 Purpose: The purpose of program formulation activities is to establish a cost-effective program that is demonstrably capable of meeting Agency and Mission Directorate (or Mission Support Office) goals and objectives. The program Formulation Authorization Document (FAD) authorizes a Program Manager to initiate the planning of a new program, and to perform the analyses required to formulate a sound Program Plan. A FAD template is found in Appendix A. The PCA is the agreement between the MDAA (or MSOD) and the NASA Deputy Administrator that authorizes transition from formulation to implementation. A PCA can be considered an executive summary of the Program Plan. A PCA template is found in Appendix B.

2.2.2 Requirements: During program formulation, the Program Manager, once selected, shall:

2.2.2.a Prepare a Program Plan.

  1. In the Program Plan, the Program Manager shall define and document an affordable program architecture along with the success criteria and performance metrics. (A Program Plan template is provided in Appendix C.) Specifically, the Program Manager shall:
  1. Ensure that top-level requirements, including success criteria, for each constituent project are defined in coordination with the Mission Directorate (or Mission Support Office) and documented in the Program Plan.
  2. Ensure the validated high-level requirements and program success criteria flow down to projects or portfolios. Program Managers are required to demonstrate this linkage (traceability) while formulating and implementing a program, and this linkage will be closely monitored when the Program Plan is reviewed.
  3. Prepare estimates of yearly New Obligational Authority (NOA) consistent with top-level program requirements, and identify the civil service workforce so as to enable full cost estimates.
  4. Prepare an overall program timeline with key milestones related to the accomplishment of program goals and objectives. When applicable, the timeline should provide guidance and a schedule for the announcement of new project (or research) opportunities.
  5. Document synergistic activities with other NASA, industry, academia, and international programs.
  6. Prepare and implement a comprehensive Safety and Mission Assurance (SMA) Plan early in program formulation to ensure program compliance with all regulatory safety requirements from OSHA and all NASA Safety and Mission Assurance requirements such as mishap reporting and investigation, range safety, software safety and assurance, and human rating requirements. The importance of up-front safety, reliability, maintainability, and quality assurance requirements should be emphasized in all program activities.
  1. Beginning early in program formulation, the Program Manager shall work with the Office of External Relations, the Deputy Chief Acquisition Officer and the MDAA (or MSOD) to identify potential non-NASA partners and necessary agreements for international or interagency cooperation.
  1. All activities and documentation shall be consistent with policy directives and with Mission Directorate (or Mission Support Office) and Agency-level agreements with the partners.
  2. All program-enabling commitments shall be obtained prior to program approval for implementation.
  1. The Program Manager shall evaluate lessons learned from existing and previously executed programs and projects to identify applicable lessons for use in program planning and execution.
  2. Early in program formulation, the Program Manager, in consultation with the MDAA (or MSOD), shall recommend a Technical Warrant Holder (TWH). The NASA Chief Engineer selects the TWH.

2.2.2.b Create a program organizational and financial structure.

  1. The Program Manager shall build a program organizational structure that assigns clear lines of responsibility, authority, and accountability to specific Centers, Project Managers, partners, advisory groups, and oversight boards.
  2. Working in close cooperation with the OCFO, the Program Manager shall be responsible for creating financial management structures that comply with budget and accounting standards established by that Office.

2.2.2.c Develop a program technical approach.

  1. As applicable, the Program Manager shall identify scientific and engineering research and development strategies, develop constituent project (systems and operations) concepts, acquisition strategies, technology strategies, commercialization plans, agreements (e.g., space operations service agreements, launch services agreements, safety and mission assurance agreements), and logistics concepts and incorporate them into the Program Plan. The most important aspect of this formulation activity is conducting a thorough analysis of alternatives (AoA), relying on architecture frameworks, program-level systems engineering, design reference mission analysis, and other formal techniques.
  2. The Program Manager shall establish the program's methods for advanced technology insertion and validation, safety and mission assurance, environmental impact assessment, records and data management and distribution, physical and information security and program protection, and risk management and incorporate them into the Program Plan.
  3. The Program Manager shall incorporate the security considerations in NIST Special Publication 800-64, "Security Considerations in the Information System Development Life Cycle," in the lifecycle of all Information Technology related Programs.

2.2.2.d Develop a continuous risk management process

  1. The Program Manager shall develop and implement a continuous risk management process (that includes integrated risk management planning for all risks associated with program safety, cost, schedule, and technical performance) and document it in a program Risk Management Plan.
  1. The Program Manager shall begin the process with risk identification and an assessment of program constraints, which defines the acceptable risks. Areas of potential program risks include, but are not limited to: mission success criteria; development schedule; budget limits; launch window and vehicle availability; international partner participation; critical single source suppliers; security; environmental concerns; human space flight safety issues; fail ops/fail safe requirements; safe and reliable operations; and the amount and type of testing.
  2. The Program Manager shall follow the NASA Continuous Risk Management (CRM) Process, shown as Figure 2-1 and Figure 3-2 in Chapter 3.
  3. The program Risk Management Plan shall describe periodic risk reviews, system safety, quantitative risk assessments, operations risk management, risk-based acquisition management, and information management systems for problem reporting, surveillance reporting, supportability data, and trends analyses.
  1. All risks shall be documented and communicated throughout the program's life cycle.
  2. The results of the risk management process shall be incorporated into the final technical products.

Figure 2-1. The NASA Continuous Risk Management Process

2.2.2.e Develop a closed-loop problem tracking process that includes problem or anomaly reporting, problem analysis, and corrective action.

  1. The Program Manager shall develop a protocol to review past performance to determine the incidence of identical or related anomalies.
  2. The Program Manager shall develop an escalation procedure (to inform higher levels of management) based on mission criticality.
  3. The Program Manager shall develop a closeout process for root cause determination, anomaly mitigation, and recurrence control.
  4. The Program Manager shall evaluate and disposition Government-Industry Data Exchange Program (GIDEP) Alerts, Safe-Alerts, Problem Advisories, Agency Action Notices and NASA Advisories, and shall exchange significant problem and nonconforming item data with other activities and with GIDEP.

2.2.2.f Present the Program Plan for approval by the MDAA (or MSOD).

  1. Prior to the program Non-Advocate Review (NAR), the Program Manager shall secure Program Plan concurrence by the cognizant MDAA (or MSOD) and from those Center Directors committing support to the program.
  2. For single-project programs, the Program Manager shall either prepare both a Program Plan and a Project Plan, or integrate key elements of the Program Plan with all required elements of the Project Plan. The resultant Program Plan should fully meet the requirements described for both the program and project plans, including adequate linkage to the Agency Vision, goals, and objectives.
  1. For the purposes of compliance with this document, formulation and implementation activities for single-project programs shall follow the requirements outlined for projects.
  2. A Formulation Authorization Document (FAD) and a Program Commitment Agreement (PCA) shall be required for a single-project program.

2.2.2.g Support the Mission Directorate or the (Mission Support Office) in the preparation of a Program Commitment Agreement, based on the content of the Program Plan.

2.3 Program Approval

2.3.1 Purpose: The program approval process is an ongoing effort by senior NASA management to determine the program's readiness (at key milestones) to continue with formulation, or to proceed to or continue with implementation.19 To secure program approval, the Program Manager must prepare (or revise) key program management documents (PCA, Program Plan, etc.) and submit them to the Agency PMC at a decision review meeting.


19 For existing programs, re-approval may be required during implementation as a result of proposed changes to the PCA and Program Plan based on budgetary, technical, or institutional considerations.

2.3.2 The term "ongoing" is used in paragraph 2.3.1 because the number of key milestones at which decision reviews are required varies from program to program. The number and focus of decision reviews depends on the program's predominant product line and development strategy. Non-flight programs will have at most one decision review--the NAR--occurring between formulation and implementation. Programs dominated by flight systems and ground support projects will have at least two decision reviews--the preliminary NAR occurring during formulation and the NAR. To avoid unnecessary duplication of review events, these decision review meetings are generally timed to coincide with the program's first project preliminary NAR and NAR. For all programs that use evolutionary acquisition there are two additional decision reviews--the Concept Decision Review, occurring before formal formulation activities start, and the Production Review, occurring during implementation before significant production activities start. Table 2-1 shows the required program decision reviews.

2.3.3 NASA will adapt its program evaluations and management accountability hierarchy to accommodate programs that are an evolving system-of-systems. Specifically, when a Mission Directorate uses an evolutionary acquisition approach, decision reviews held by the Agency PMC will occur at the "spiral level," will include the major program elements (i.e., projects), and will be conducted concurrently with the spiral decision reviews. Because this is a new approach to program approval, NASA senior management plans to revisit the number of decision review meetings after some experience has been gained.

Table 2-1. Program Decision Reviews

2.3.4 Requirements: In support of Agency PMC decision review meetings during program approval:

2.3.4.a The Program Manager shall support evaluation by IPAO in accordance with the program evaluation process. (See paragraph 2.5.8 for more detailed requirements.)

2.3.4.b The Program Manager shall prepare a program readiness overview briefing for presentation at the Agency PMC milestone decision review meeting that includes a summary of the program, the status of program documentation and products, concurrence of the TWH on technical requirements (including all variances), and significant risks, all appropriate to the level of program maturity.

2.3.4.c The Program Manager shall prepare (and/or submit) the program documents and products described in Table 2-2. For programs that have a preliminary NAR, an updated FAD is not needed for the NAR.

2.3.4.d At that meeting, the IPAO results and findings, including an Independent Cost Analysis (ICA), are also presented. The Program Manager shall then follow with a presentation of responses to the IPAO findings.

2.3.5 When all presentations are concluded, the Agency PMC convenes an executive session to discuss the material presented and determines whether to recommend approval to the Deputy Administrator. A positive recommendation may be unconditional, or conditional on the Program Manager completing assigned action items, some of which address IPAO findings from the NAR. A negative recommendation by the Agency PMC results in direction to the Program Manager to either address the deficiencies or to terminate the program. When the Deputy Administrator signs the PCA, the program is approved for implementation, and the program's NAR Baseline is formally established.

Table 2-2. Key Program Documents and Product Maturity by Decision Review

2.4 Program Implementation

2.4.1 Implementation of programs requires many actions from the Program Manager. The Program Manager should work closely with Mission Directorate (or MSOD) personnel and with the OCFO to coordinate plans, budgets and schedules. During program implementation, the Program Manager performs and orchestrates the following activities:

  1. Program control.
  2. Program advocacy.
  3. Program integration.

2.4.2 Program Control

2.4.2.1 Purpose: Through this activity the Program Manager provides direction and exercises control over the program. The purpose of this activity is to ensure that program implementation is conducted in an effective manner, considering safety, risk, performance, cost, schedule, and quality commitments in the Program Plan. This activity provides management oversight of all aspects of the program, especially oversight and review of the constituent projects. This activity ensures the collection, tracking, reporting, and management of the program according to agreed-upon metrics.

2.4.2.2 Requirements: During implementation, the Program Manager shall:

2.4.2.2.a Have a signed PCA before conducting activities associated with program or program element (project or portfolio) implementation.

2.4.2.2.b Demonstrate a comprehensive program control function.

  1. The program control function shall operate to ensure that cost, schedule, safety, and performance commitments made at the program and project levels are demonstrable in terms of agreed-upon metrics.
  2. The Program Manager shall focus attention on assuring that projects are operating within the framework of the approved Program Plan.
  3. The Program Manager shall monitor any program element reserves held at the program level and distribute them, as needed, to meet program goals and objectives.

2.4.2.2.c Prepare and maintain detailed budgets, work authorizations, plans, and schedules.

  1. The Program Manager shall provide a copy of the signed PCA to the OCE and OCFO.
  2. The Program Manager shall support the Mission Directorate (or Mission Support Office) in updating the PCA through a revision when new content is added to the program (e.g., the creation of a new project). The revision shall be noted in the PCA change log.
  3. The Program Manager shall evaluate the need for modifications of the Program Plan and the PCA due to changes in projects and activities within the program. Programs are usually long-lived constructs and should not require extensive modification during implementation. However, external funding changes or strategic shifts within the Agency can generate modifications to the PCA. Specifically, for ongoing programs:
  1. The Program Manager shall support the Mission Directorate (or Mission Support Office) in updating the PCA through a modification when budget changes greater than 20 percent (20%) in a given year, or ten percent (10%) within a five-year horizon occur.
  2. The Program Manager shall support the Mission Directorate or (Mission Support Office) in preparing the PCA modifications and documenting them in the PCA change log. The Mission Directorate will approve the modifications and take the modified PCA to the Agency PMC for an approval recommendation to the Deputy Administrator.
  3. The Program Manager shall support the Mission Directorate (or Mission Support Office) in preparing a briefing for the Agency PMC that describes factors driving the modification and shall support the briefing if requested. When the Deputy Administrator signs the modified PCA, the program modification is approved.
  1. Budget data shall reflect, at all times, the full cost of implementing all aspects of the program. (For more information on full cost and practices, see Volume 7 of the NASA Financial Management Requirements.)
  2. The Program Manager shall prepare and maintain a detailed schedule of program milestones and major planned events. Program Managers are encouraged to identify alternative development paths in order to maximize the probability of success.
  3. The Program Manager shall review and approve constituent Project Plans.

2.4.2.2.d Oversee acquisition efforts.

  1. The Program Manager shall ensure that all acquisition efforts20 and other transactions are implemented in accordance with Federal law and regulations (including the FAR or OMB Circulars, as applicable), and the NASA FAR Supplement, NASA directives, and the Program Plan.
  2. The Program Manager shall ensure that standards and requirements flow down to external parties (i.e., contractors, grantees, and non-NASA parties to Space Act and other agreements and non-procurement instruments).

20 This includes contracts, grants, cooperative agreements, interagency agreements, Space Act Agreements, and any effort not performed by NASA installation employees.

2.4.2.2.e Conduct an integrated continuum of reviews. The Program Manager shall conduct the internal program reviews during implementation as specified in the Program Plan.

2.4.2.2.f Disposition all risks before delivery to operations (or the equivalent for a technology program).

2.4.2.2.g Support the Mission Directorate (or MSO) in preparing material for Quarterly Status Reviews (QSRs) to the Agency PMC.

2.4.2.2.h Periodically evaluate the performance of Project Managers and their teams.

2.4.3 Program Advocacy

2.4.3.1 Purpose: The purpose of this activity is to proactively consult and involve customers in program decision forums during implementation to ensure customer satisfaction with delivered products and services within budget and schedule commitments. Program advocacy also includes external outreach to the wider set of stakeholders. The Program Manager works with the Mission Directorate (or Mission Support Office) to advocate for the totality of the program, including advocacy for constituent projects. The MDAA (or MSOD) and Program Manager should ensure an effective interface across Government agencies and international partners, and with the political stakeholders. In completing the education and public outreach plan, the Program Manager ensures integration with the Agency education strategic goals.

2.4.3.2 Requirements: During implementation, the Program Manager shall:

2.4.3.2.a Advocate and promote customer involvement in the implementation of the program to assess progress against commitments.

2.4.3.2.b Produce and execute a plan for education and public outreach by working with Mission Directorate education leads and the NASA Office of Education.

2.4.4 Program Integration

2.4.4.1 Purpose: This activity develops and integrates the overall implementation approach and provides management oversight of all aspects of the program.

2.4.4.2 Requirements: During implementation, the Program Manager shall:

2.4.4.2.a Maintain the continuity of requirements by ensuring that requirements are fully traceable from Agency vision and goals down through program requirements and top-level project requirements.

2.4.4.2.b Ensure that the program is being implemented in a cost-effective manner by continuing to conduct architecture trades, technology assessments, mission analyses, and infrastructure and operational analyses that help structure program-level investments for maximum return.

2.4.4.2.c Ensure that all investment areas (product lines) associated with the program are being managed in an integrated manner so that changes in one program investment area are reflected in all other related investment areas.

2.4.4.2.d Ensure that all cross-cutting management elements of the program (e.g., safety, technology strategy, risk management) are being implemented in constituent projects in accordance with the Program Plan.

2.4.4.2.e Identify and secure facilities, infrastructure, equipment (including GFE), materials, supporting personnel, and services that are required to support multiple projects within the program.

  1. The Program Manager shall negotiate agreements with support providers, as needed.
  2. For those products requiring transfer of custodial responsibility, the Program Manager shall ensure that acceptance/turnover activities, licensing, and documentation are addressed.
  3. The Program Manager , shall e , nsure that Project Plans account for the disposition of assets (orbital and other) after the end of their useful life.
  4. The Program Manager shall manage all salvageable assets (e.g., spares) remaining at the end of a constituent project's life cycle.

2.5 Program Evaluation

2.5.1 NASA's leadership places a high value on independent review of programs and projects as an unbiased quality check of the engineering and management efforts.

2.5.2 Purpose: The evaluation process utilizes independent review teams composed of knowledgeable, independent experts from outside the advocacy chain of the program. Evaluation supports the approval process by providing findings and supporting data needed to help the Agency PMC decide whether to proceed to the next program phase. Evaluation during formulation assesses whether a program supports the Agency Vision and strategic goals, and whether that program can be successfully conducted within available resources and applicable constraints. Evaluation during implementation assesses whether a program is contributing to the Agency Vision and goals, and is being successfully executed according to the Program Plan. Evaluation also provides findings to enhance the program's technical and programmatic performance.

2.5.3 These evaluations are generally planned to minimize disruptions to the program and avoid unnecessary duplication of review events. In keeping with that policy, NASA will adjust its program evaluations to accommodate programs that are an evolving system-of-systems.

2.5.4 Requests for external audits and assessments of programs may come from the Congress, the NASA Inspector General, the Government Accountability Office (GAO), advisory groups such as Science Advisory Committees, and other similar sources. When requested, the OCE will coordinate responses to external review requests, work in concert with the MDAA (or MSOD) to disposition such requests, and coordinate the scheduling of such activities with the Program Manager and Agency PMC.

2.5.5 Special-purpose independent reviews (e.g., Termination Review) will be conducted when directed by the Agency PMC or Mission Directorate. Requests for special purpose reviews may come to the Agency PMC from customers, line organizations, or others. Elements such as the anticipated inability of a program to meet its commitments, an unanticipated change in Agency strategic planning, or an unanticipated change in the NASA budget may initiate such reviews.

2.5.6 For basic and applied research programs, a Program Implementation Review (PIR) will be held every three years, and conducted consistent with NPR 1080.1, NASA Science Management. All other programs will have a biennial (nominally every two years) PIR by the IPAO throughout implementation at a time designed to minimize disruptions to the program (e.g., at scheduled program milestone reviews). The IPAO PIR is designed to ensure that the program's scope and content remain tightly linked to the Agency Vision and goals, that the program's implementation follows the intent of the Program Plan and that the program is meeting the NAR Baseline performance, cost, and schedule commitments. The IPAO reports the results of such periodic PIRs to the Agency PMC. For basic and applied research programs, the results of the PIRs are also reported to the Mission Directorate Science Management Council (SMC) or equivalent.

2.5.7 For all programs, the general process flow leading to each Agency PMC decision review and PIR is as follows. The Program Manager schedules program site field review events with the IPAO. During the IPAO site field review, the Program Manager presents a detailed program briefing, which demonstrates the program's readiness to continue. This briefing includes a program cost estimate and documentation/data required to conduct an Independent Cost Analysis (ICA). At the end of the IPAO site field review, the IPAO provides a preliminary verbal outbrief to the Program Manager. The IPAO prepares an initial briefing, which includes an Independent Cost Analysis (ICA), and briefs the Program Manager. The Program Manager reviews the facts, assumptions, and findings of the initial IPAO briefing, and provides a formal response to the IPAO. The IPAO and Program Manager brief the cognizant Center management (if applicable) and the Mission Directorate on the findings and program responses. The IPAO prepares a final briefing and issues it to the Program Manager, the Directorate, and to the Agency PMC members. After the final briefing is issued, the Program Manager and the IPAO brief the Agency PMC.

2.5.8 Requirements: To accomplish the ongoing program evaluation process, the Program Manager shall:

2.5.8.a Plan program team and schedule resources to support Independent Assessment (IA) for all required program decision reviews and Program Implementation Reviews (PIRs) (nominally every two years after the NAR approval21). For initial planning purposes, the Program Manager should consult Table H-2 in Appendix H. The program's planning schedule may be modified through negotiation with the IPAO.


21 For basic and applied research programs, Program Implementation Reviews occur every three years.

2.5.8.b Comply with the evaluation Terms of Reference (ToR) for all independent reviews.

  1. The ToR is prepared by the IPAO through negotiation with the MD (or MSO) point-of-contact. The ToR is approved by the OCE and the MDAA (or MSOD). The ToR specifies the details of conducting site field review events, including the schedule, deliverable items, and areas of program risk. If the MD (or MSO) point-of-contact and the IPAO cannot agree on the ToR scope and content, the OCE shall be the final decision authority.
  2. The final schedule shall be documented in the evaluation ToR.

2.5.8.c Prepare program briefings and material demonstrating the program's readiness to continue, and present them at the IPAO site field review. These briefings shall include a program cost estimate. (PIRs are designed to measure program performance and compare that performance against the Program Plan. Consequently, the biennial PIR focuses on program activities and generally does not delve into project operations. The Program Manager should, however, plan for some level of project-level analysis in order to assess the delivery of products and services according to the agreed-upon metrics in the Program Plan.) The Program Manager should consult Table H-1 in Appendix H for other assessment criteria.

2.5.8.d Review facts, assumptions, and findings of the initial IPAO briefing, and provide a formal response to the IPAO.

2.5.8.e Comply with external requests for evaluation and audit (e.g., Congress, OMB, NASA Inspector General, GAO, etc.).

2.5.8.f Support any additional independent reviews or technical assessments that may be required during formulation and implementation as directed by the Administrator, Agency PMC, MDAA, MSOD, the OCE (including the NESC), or the Office of Safety and Mission Assurance. The Program Manager shall provide formal responses to action items/recommendations from these reviews for closure.

2.5.8.g Ensure that program engineering data related to failures, anomalies, evaluations, problems, incidents, and Requests for Action (RFAs) are captured, retained, and made available to the TWH and NESC upon request.

2.5.8.h Provide support for a Safety and Mission Assurance Readiness Review (SMARR) prior to any launch or safety critical event or other activity selected by the Chief SMA Officer.


Chapter 3. Common Project Management Requirements

SPECIAL NOTICE: Use Chapter 2 for Non-Space Flight and Non-Research and Technology Program Management. Use NPR 7120.5D for Space Flight and use NPR 7120.8 for Research and Technology

3.1 Four-Part Project Management Process

3.1.a NASA projects are elements of a program and are investments that have defined goals objectives, requirements, LCC, a beginning, and an end. Projects vary significantly in their complexity, cost, and criticality. The Project Manager is responsible for the successful accomplishment of his/her project from formulation through implementation, and for customer satisfaction with the products and services delivered. The Project Manager is accountable to his/her Program Manager and to the Center Director for assigned projects. Project Managers are key members of the program management team, providing information and assisting the Program Manager in the execution of the integrated program.

3.1.b This chapter delineates the common requirements for the management of projects, described in terms of the four-part management process of paragraph 1.7.1. The requirements of the chapter apply specifically to projects identified in Program Plans. It is recognized that these projects contain lower-level project activities managed by designated responsible organizations. The cognizant Mission Directorates, Mission Support Offices, programs, projects, or Centers shall flow down the requirements of this document. The Project Manager should also review all Mission Directorate, Mission Support Office, program, and Center-level documents that might include requirements beyond those in this document.

3.1.c Managers of projects identified in a Program Plan shall meet all requirements outlined in this chapter irrespective of the size of the project and the program of which it is an element. Requests for deviations or waivers to NPR 7120.5C requirements shall be documented and submitted for approval to the Center Director, the Program Manager, Mission Directorate (or Mission Support Office), and the appropriate GPMC. The Project Manager should receive written authorization from the Office of Security and Program Protection for waiver of activities related to security. Prior to the NAR, these requests shall be documented in the NPR 7120.5C compliance matrix attached to a single deviation or waiver to assure proper routing and control.22 Deviations or waivers impacting formulation or requiring long lead-time shall be submitted individually early in formulation. Following the NAR, deviations or waivers shall be submitted individually to the approving authority described above. The compliance matrix, with approved deviations and waivers, shall be included as an appendix to the Project Plan.


22 The Compliance Matrix is provided as Appendix K.

3.1.d Project IT investments shall be separately planned for, evaluated in terms of Return on Investment (ROI), budgeted, and managed. Refer to Chapter 7 for requirements related to IT investments made by all projects, regardless of type.

3.1.e Program management and project management are inextricably linked and the relationship between the two levels of management is critical to achieving mission success. Project management is different, however, from program management when it comes to timing and composition. The Project Manager works in concert with the Program Manager, but focuses on the day-to-day execution of the project by industrial contractors, universities, NASA personnel, and other agencies, foreign and domestic. There is also considerable breadth needed to address the safety, cost, schedule, technical performance, team building, human resource, and institutional issues associated with managing a project. The Project Manager should be knowledgeable in all these areas and utilize the experts from line or functional organizations to assist in project formulation and implementation.

3.2 Project Formulation

3.2.a Working through a program office, a MDAA (or MSOD) will usually provide a small amount of discretionary resources for pre-formulation activities (i.e., activities before a project formally enters formulation). These pre-formulation activities involve mission analysis, advanced concept studies, and analyses of alternatives that should be performed before a specific project concept emerges. These trade studies are not considered part of formal project planning since there is no certainty that a specific project proposal will emerge. In programs that use an Announcement of Opportunity (AO) process, program resources are invested (following Step 1 selections) to bring certain mission concepts to a state in which their science content, cost, schedule, technical performance, project implementation strategies, safety and mission assurance implementation strategies, and management approach can be better judged.23

3.2.b The MDAA (or MSOD) has the authority to initiate a project and begin formulation activities. To effect a project's official entry into formulation, the Program Manager prepares a draft project FAD or equivalent (such as a Program Plan section, MDAA letter selecting a specific AO proposal, or a Program Directive that is used in the Space Station and Shuttle Programs). The draft project FAD is forwarded to the MDAA (or MSOD) for final signature. Once the MDAA (or MSOD) signs the project FAD, a project formally enters formulation. In a new program, formulation of the first project can only begin after the program FAD has been signed and a Program Manager is formally selected by the MDAA (or MSOD).

3.2.c Once selected, the Project Manager is responsible for the evolution of the project concept and ultimate mission success. If requested by the Mission Directorate, Mission Support Office, or Program Manager, the Project Manager assists in revising the PCA.

3.2.d NASA places a good deal of emphasis on project formulation because adequate preparation of project concepts and plans is vital to success. During formulation, the project establishes the success criteria, explores the full range of implementation options, defines an affordable project concept to meet mission objectives specified in the Program Plan, and develops and documents the Project Plan. A key part of the Project Plan describes the Project Baseline, against which the project will be measured. Formulation is an iterative set of activities24 rather than discrete linear steps. Formulation continues with interactive execution of its activities, normally concurrently, until formulation output products have matured and are acceptable to the Program Manager and the MDAA (or MSOD).

3.2.e During project formulation, the Project Manager25 with the project team performs the following activities:

  1. Project planning.
  2. Cost estimation.
  3. Systems engineering.
  4. Independent technical authority.
  5. Project assessment and control.

23 From the point-of-view of the selected AO-driven project, the winning team is clearly doing formal project formulation (putting together a detailed WBS, schedules, cost estimates, implementation plans, etc.) during the preparation of the Step 2 proposal. From the point-of-view of the program, no specific project has been chosen, so project Level 1 requirements are unknown, costs can encompass a wide range, and a FAD cannot be executed. Consequently, formal project formulation cannot begin. This document recognizes the existence of both views.
24 Activities include flowing down agreed-to success criteria to the system/subsystem level; establishing the internal management control functions that will be used throughout the life of the project; assessing the technology requirements and developing the plans for achieving them; identifying options for partnering and commercialization; performing life-cycle cost (LCC) and mission effectiveness analyses for concepts deemed to have a high degree of technical and operational feasibility; and identifying margins and reserves consistent with project risk.
25 For single project programs, the term Project Manager is usually taken to mean Program/Project Manager.

3.2.1 Project Planning

3.2.1.1 Purpose: This activity develops the project's objectives, requirements, success criteria and concomitant implementation approaches and technology strategy, establishes the Project Plan, and creates project control structures such as the Work Breakdown Structure (WBS) and Integrated Master Schedule (IMS).

3.2.1.2 Requirements: The Project Manager and the project team shall:

3.2.1.2.a Prepare the Project Plan.

  1. At a minimum, the Project Plan shall contain all elements of the template provided in Appendix D. If the Project Manager chooses to write separate plans for some elements of the template, then the Project Plan shall summarize the salient points of the separate plans.
  2. Sections of the Project Plan that are replaced by alternative approaches through an approved waiver or deviation shall be clearly identified in the Project Plan.
  3. The Project Manager shall have the initial version of the Project Plan completed and ready for review by the Program Manager within the relevant milestone in the Appendix G.
  4. The Project Manager shall secure approval of the Project Plan within the relevant milestone as identified in Appendix G. As a minimum, the cognizant Center Director and the Program Manager shall sign the Project Plan.
  5. The Project Manager shall evaluate lessons learned from existing and previously executed projects to identify applicable lessons for use in project planning and execution.

3.2.1.2.b Define a Work Breakdown Structure (WBS).

  1. The WBS for the project shall encompass all the work required in the project, including both in-house and contractor efforts, over the project life cycle.
  2. The WBS for the project shall be based on the appropriate product line template.
  3. The WBS shall have a companion WBS dictionary that narratively describes the overall structure and content of each individual element of the WBS, and a WBS index linked to reference individual elements to the dictionary.

3.2.1.2.c Prepare a project Integrated Master Schedule (IMS) as part of the Project Baseline.

  1. The project IMS shall show all tasks necessary to accomplish the total scope of work derived from authorizing documents (e.g., FAD, PCA, Program Plan, Contract) and defined in the approved project WBS.
  1. Activity durations shall identify the realistic number of work periods required to accomplish each activity in the IMS.
  2. Resource requirements, capacity, and availability shall be considered.
  3. Schedule reserve, based on risks and historical norms, shall be clearly identified.
  1. The project IMS shall show all critical project milestones, logical relationships (interdependencies) for all tasks and milestones, and include critical paths, when required, based on both project category and product line type. (See product line chapters).
  2. The project IMS shall have traceability to both lower-level detailed schedules and higher-level management summary schedules controlled by the approval authority (e.g., Program Manager, MDAA).

3.2.1.2.d Create a team structure designed to assure mission success.

  1. The Project Manager shall develop a team organization compatible with the WBS and the implementation strategies selected for the project. The project's organizational structure shall be documented in the Project Plan, Part 1, Project Management.
  2. Project teams can be composed of civil service personnel, contractors, academia, partners, and customers. It is important that project teams have full and open communication. Clear lines of authority and communication must be demonstrated in the project organization chart. Therefore:
  1. The Project Manager shall develop a project Communications Plan so as to foster effective (upward and downward) communication of critical management, technical, risk, and safety information.
  2. The Communications Plan shall specifically define the relationships among various project elements, and unambiguously identify responsibilities for problem reporting and subsequent decision making, during normal and contingency events.
  3. The Communications Plan shall define relationships and interactions with all stakeholders, team members, and supporting organizations.
  4. The Project Manager shall develop a plan to meet the program requirements for a closed loop problem tracking process, described in paragraph 2.2.2.e.
  1. The balance of required skills, experience, and the size of the team will likely change through the project life cycle. Therefore, the Project Manager shall develop staffing plans consistent with the needs of the project over its life cycle, staff with personnel with the appropriate skills, abilities, and experience, and provide integrated team training to successfully execute the project.
  2. The Project Manager shall negotiate required resources with applicable service pool managers.
  3. In their supervisory capacity, Project Managers shall provide for the individual development of personnel that report directly to them. In addition, Project Managers should collaborate with line managers on the individual development needs of other members of the team. Project Managers should identify meritorious performance and create a strategy for using the NASA Awards and Recognition program to acknowledge successful, high-performing individuals and teams. Project Managers should take quick action to remedy unsatisfactory performance, whether through provision of additional guidance or training or, if necessary, changes in personnel.

3.2.1.2.e Examine and manage requirements for advanced technology.

  1. The Project Manager shall analyze technology requirements for feasibility, availability, technology readiness, and opportunities for leveraging ongoing research. Specifically:
  1. The Project Manager shall evaluate sources of technology from other NASA Centers. One resource for accomplishing this is the NASA Technology Inventory Database at http://inventory.gsfc.nasa.gov.
  2. The Project Manager shall also identify commercial, academic, and other government agency sources of technology.
  3. Full cost assessments and risk assessments shall be performed to identify preferred sources of technology.
  1. The Project Manager shall develop an integrated technology strategy to enable the project to meet its mission objectives. This strategy shall be documented in the Project Plan, Part 3, Technology Strategy:
  1. The Technology Plan shall describe how the project will remove remaining technology gaps, including maturation, validation, and insertion plans, quantifiable milestones, decision gates, and resources required.
  2. Sources of technology shall be clearly identified in the Technology Plan.
  3. Distribution restrictions on the software, hardware, or data shall be clearly identified in the Technology Plan.
  1. The Project Manager shall work with Center legal and commercialization personnel to establish how project-developed intellectual property (technologies, discoveries, innovations, tools, processes, or software) can be licensed or appropriately transferred to U.S. industry in other ways.
  2. The Project Manager shall ensure that all planned technology exchanges, contracts, and partnership agreements comply with all laws and regulations regarding export control and the transfer of sensitive and proprietary information.

3.2.1.2.f Analyze project infrastructure needs.

  1. Working with the real property and industrial property offices, the Project Manager shall ensure that a comprehensive analysis of project infrastructure (real property/facilities, aircraft, personal property, and information technology IT) needs is performed. This analysis should include infrastructure required for: staff office space, test (including ground and flight facilities) and integration functions, research facilities, data systems, logistics and maintenance facilities, aircraft, and personal property and equipment.
  2. The Project Manager, in coordination with the cognizant Center functional office, shall assess existing Agency wide capabilities to meet infrastructure needs, and also assess whether facilities in other Government agencies, industry, academia, and international organizations can be utilized to reduce project LCC and risk. The Project Manager should work with the Program Manager, the MDAA, OCE, CIO, the Office of Infrastructure, Management, and Headquarters Operations, and other Headquarters offices to identify means of meeting infrastructure requirements through synergy with other programs and projects, thus avoiding costly duplication of supporting infrastructure.
  3. A business case justification shall be performed for any proposed acquisition or major modification of infrastructure (e.g., facilities, IT).
  1. The business case shall include full life cycle cost (including operations, sustainment, and disposal), benefit estimates, alternatives and sensitivity analyses, and risk assessments. (For more information on full cost and practices, see Volume 7 of the NASA Financial Management Requirements.)
  2. The business case shall be approved by the cognizant MDAA and by the cognizant NASA Headquarters functional office, or their designee(s).
  1. First in coordination with the cognizant Center functional office, and then with the Headquarters Office of Infrastructure, Management, and Headquarters Operations, and/or the CIO, as appropriate, the Project Manager shall develop plans for any necessary upgrades or new developments, including those needed for environmental compliance (see paragraph 3.2.1.2j), and then document them in the Project Plan, Part 2, Resources.
  2. The Project Manager shall comply with the provisions of NPD 7900.4 and NPR 7900.3, Aircraft Management Operations, before entering into agreements to procure or operate aircraft that might be necessary to the success of the project. The Project Manager shall directly coordinate with Center Chief of Flight Operations or the Headquarters Aircraft Management Office during the planning stage.
  3. The Project Manager shall work with the respective offices at NASA Headquarters and Centers to assure that requisite spectrum allocations and airspace access are available and, if not, to obtain the necessary approval and permits.
  4. The Project Manager shall comply with the provisions of current space transportation laws and policies, and NPD 8610.7, Launch Services Risk Mitigation Policy for NASA-Owned or NASA-Sponsored Payloads, and NPD 8610.12, Office of Space Operations (OSO) Space Transportation Services for NASA and NASA-Sponsored Payloads, involving launch assignment and acquisition before entering into agreements to procure launch services or launch vehicles. The Project Manager shall coordinate with the Space Operations Mission Directorate (SOMD) during planning and formulation for any project requiring launch.

3.2.1.2.g Manage agreements.

  1. Any use of interagency, industry, academic, and/or international cooperation agreements needs to be addressed early in project formulation. When these agreements are considered for a project, the Project Manager shall work with the appropriate Headquarters offices and, where necessary, have the agreements approved by them. All activities and documentation should be consistent with policy guidelines and with program, Mission Directorate (or Mission Support Office), and Agency-level agreements.
  2. All agreements, memoranda of understanding, barters, in-kind contributions, and other arrangements for collaborative and/or cooperative relationships shall be identified in the Project Plan, Part 3, Cooperation and Commercialization, and the Project Manager shall maintain signed copies of all such agreements.

3.2.1.2.h Complete an Acquisition Plan.

  1. The Project Manager shall develop an integrated acquisition strategy that enables the project to meet its mission objectives, provides best value to NASA, and complies with the FAR and the NASA FAR Supplement. The Project Manager shall ensure that applicable laws, regulations, requirements, and standards are flowed down from NASA to the prime and sub-contractors. This strategy shall be documented in the Project Plan, Part 2, Acquisition Management.
  1. The Acquisition Plan shall identify all major proposed acquisitions in relation to the project WBS.
  2. The Acquisition Plan shall consider the utilization of NASA in-house capabilities and the maintenance of NASA's core competencies when making make or buy decisions.
  3. The Acquisition Plan shall identify the project's approach to creating contractor incentives that strengthen safety and mission assurance.
  4. The Acquisition Plan shall identify significant ($1 million or more) equipment requirements expected to be acquired or fabricated by contractors in support of the project objectives.
  1. If systems contain software, the Project Manager shall ensure that software developed internally within NASA or acquired complies with NPR 7150.2, NASA Software Engineering Requirements, and NASA Standard 8739.8, Software Assurance Standard.
  2. The Acquisition Plan shall establish a continuous Risk-Based Acquisition Management (RBAM) process:
  1. The project acquisition planning team shall obtain input from Center personnel responsible for safety and mission assurance, health, environmental protection, information technology, export control, and security. The goal of this involvement is to ensure that the acquisition is structured to address appropriately the concerns of these disciplines as they relate to the requirement. (See NFS 1807.104.)
  2. During the solicitation process, any exchanges with industry prior to receipt of offers should include requests for any perceived safety, occupational health, security (including information technology), environmental, export control, and/or other programmatic risk issues associated with performance of the work. Similarly, when technical proposals are required as part of requests for proposals for supplies or services, offerors shall be instructed to identify and discuss risk factors and their approach for managing those risk factors (see NFS 1815.201 and NFS 1815.203-72). Where the solicitation requires submission of a Safety and Health Plan (see NFS 1823.7001(c)), safety and health shall be a consideration in the evaluation process (also see NFS 1815.305).
  3. Quality assurance surveillance plans shall be prepared with the statement of work for all performance-based contracts and, as necessary, for other contracts. The Project Manager shall follow NPR 8735.2, Management of Government Safety and Mission Assurance Surveillance Functions for NASA Contracts.
  4. Working with SMA, the Project Manager shall ensure that the plans reflect NASA's surveillance approach relative to the perceived programmatic risk. The plans are general at the outset, but after contract award, the Contracting Officer shall ensure that the plans are revised to reflect the risks associated with the successful proposal (see NFS 1846.401 and Procurement Information Circular 02-17).
  1. The Acquisition Plan shall be reviewed and approved by the Program Manager prior to initiating any major procurement actions as established in Section 3.2.4.

3.2.1.2.i Complete a Safety and Mission Success Plan.

  1. The Project Manager shall complete a Safety and Mission Success Plan and ensure close integration with the appropriate Safety and Mission Assurance (SMA) organization. The resulting plan can be incorporated into the Project Plan, Part 3, Safety and Mission Assurance.
  2. The Project Manager shall perform activities to provide for the early identification, analysis, reduction, and/or elimination of hazards that might cause the following:
  1. Loss of life or injury/illness to personnel;
  2. Damage to or loss of equipment or property (including software);
  3. Unexpected or collateral damage as a result of test;
  4. Failure of mission;
  5. Loss of system availability; and/or
  6. Damage to the environment.
  1. Project Managers shall establish safety and mission success activities as a part of the continuous risk management process early in the project formulation process. Specifically, the Project Manager shall:
  1. Incorporate health and safety principles in all planning.
  2. Perform formal assessment and documentation of each hazard.
  3. Control each hazard in accordance with the reduction protocol in NPR 8715.3, NASA Safety Manual.
  4. Perform a safety assessment or readiness for flight or other operations, explicitly noting any exceptions arising from safety issues and concerns.
  5. Utilize a quality management system in compliance with NPD 1280.1, NASA Management Systems, and with appropriate supplier assessment and surveillance.
  6. Provide a reliability, maintainability, and parts assurance program appropriate to the needs of the project.
  1. Each project that uses radioactive materials must have an internal NASA process in place for effective intra-Agency and interagency coordination in obtaining launch approval. Therefore:
  1. Each project shall ensure that system designs that use radioactive materials reduce public and worker exposure to radiation and radioactive materials to levels that are as low as reasonably achievable.
  2. Radiological contingency plans, commensurate with the potential health risk to the public, shall be developed for missions carrying radioactive materials in accordance with NPD 1820.1, NASA Environmental Health Program, and NPR 8715.3, NASA Safety Manual.
  3. Each project proposing to launch radioactive materials shall fully adhere to the NASA and Executive branch interagency coordination processes for nuclear launch safety approval in accordance with NPD 1820.1, NASA Environmental Health Program, and NPR 8715.3, NASA Safety Manual.
  4. The Project Manager shall support the NASA Headquarters Office of Safety and Mission Assurance (OSMA) and the Office of Security and Program Protectio , n in ob , ta , , ining nuclear launch safety approval.

3.2.1.2.j Complete the Education and Public Outreach Plan. The Project Manager shall develop a plan that document linkages between science, engineering, technology, and mathematics (STEM), and the unique project content. Specifically, the plan shall incorporate elements that:

  1. Demonstrate a compelling benefit to the public.
  2. Show how each project demonstrat , es contributions to developing a pipeline promoting STEM careers and/or cultivating a workforce in science and technology.
  3. Are designed to respond to a need identified by the education community, a customer, or a customer group (customer focus).
  4. Demonstrate the connection to NASA missions and other activities that inspire and motivate the Nation's students and teachers, to educate the public, and to advance scientific and technological capabilities of the Nation.

3.2.1.2.k Complete the Environmental Management Plan.

  1. With the support of the cognizant Environmental Management Office (EMO), and in accordance with NPR 8580.1, Implementing the National Environmental Policy Act and Executive Order 12114, the Project Manager shall complete the Environmental Management Plan and incorporate it into the Project Plan, Part 3, Environmental Management.
  1. The development of the Environmental Management Plan shall be integrated with the installation Environmental Management System so as to ensure appropriate approvals, permits, and consultations are made, and mission delay impacts are avoided or minimized.
  2. The Project Manager shall integrate public, intergovernmental, and interagency involvement with the Education and Public Outreach Plan.
  1. Environmental planning needs to be integrated into project planning efforts early in formulation, as environmental protection compliance processes can be lengthy. These efforts are accomplished with the support of the cognizant EMO. Specifically:
  1. The Project Manager shall support the Mission Directorate (or Mission Support Office) to ensure the completion of the NEPA process prior to taking any action which would either (1) have an adverse environmental impact; or (2) limit the choice of reasonable alternatives. In all cases, the Project Manager shall ensure the NEPA process, as explained in NPR 8580.1, Implementing the NEPA and Executive Order 12114, is completed prior to project implementation. The Project Manager should allow 6 to 18 months to complete the required NEPA documentation.
  2. The project schedule shall include specific milestones for the completion of other documentation required by nuclear launch safety, and other pertinent NASA regulations, environmental statutes and regulations, and Executive Orders.
  3. This documentation shall include an orbital debris assessment, if applicable.
  4. The Project Manager shall, with the EMO, ensure that all required permits, waivers, documents, approvals or concurrences are obtained to ensure compliance with all applicable Federal, State, Tribal government, and local environmental regulations.
  1. The Project Manager shall comply with the applicable provisions of directives implementing NASA's planetary protection policy in NPD 8020.7, Biological Contamination Control for Outbound and inbound Planetary Spacecraft, and NPR 8020.12, Planetary Protection Provisions for Robotic Extraterrestrial Missions.

3.2.1.2.l Ensure the security of personnel and physical resources under the control of the project.

  1. The Project Manager shall work with the Chief of Center Security to identify and control threats to personnel, monitor the level of security-cleared personnel, and employ access control devices and other safeguards.
  2. The Project Manager shall employ the recommendations of the Chiefs of Center Security that address physical security and loss-prevention measures within program and project facilities.
  3. The Project Manager shall ensure that emergency response, mitigation, and recovery plans have been established for the project, in accordance with NPD 8710.1, Emergency Preparedness Program. These plans should be coordinated with the local Emergency Preparedness Office.
  4. Each project shall complete preparations and ensure that response capabilities (to include restoration of program-unique resources and capabilities) are available when needed.
  5. Each project shall ensure that contingency plans are in place to properly secure a mishap site, impound evidence, and provide necessary notification within the program and to designated Agency notification contacts.

3.2.1.2.m Provide for information technology security.

  1. The Project Manager shall take actions (appropriate to the level of sensitivity) to protect the integrity, availability, and confidentiality of project information systems, software applications, data, and information generated within their projects. This includes classified or sensitive information, export-controlled information, industry proprietary data, command, control and communications (C3) information and systems, websites, applications, and information and systems that support NASA's daily business activities (e.g., e-mail management reporting).
  2. Project technical requirements shall include information technology security requirements, in accordance with NPR 1620.1, Security Procedures and Guidelines, NPR 2810.1, Security of Information Technology, and NASA Information Technology Requirements (NITR). Specifically, the Project Manager shall:
  1. Conduct risk assessments, determine and implement risk-mitigating technologies or procedures, and manage residual accepted risks.
  2. Coordinate project security measures with established Center and Headquarters Boards governing NASA-wide infrastructure security measures.
  3. Address specific requirements for security of C3 systems and those systems containing or processing export controlled, proprietary, classified or other sensitive information.
  4. Address requirements for affording or limiting access by citizens of foreign countries involved in the project.

3.2.1.2.n Provide for export control and foreign involvement.

  1. The Project Manager shall comply with the requirements of NPR 2190.1, NASA Export Control Program.
  2. All NASA international agreements contain a clause on transfers of controlled hardware, software technology, and data both from NASA to foreign partners and from foreign partners to NASA. The Project Manager shall comply with the clause when transfers are made from NASA to a partner or a contractor of a foreign country.
  3. The Project Manager shall transfer only technical data, hardware, and software necessary to fulfill NASA responsibilities under international agreements. Specifically:
  1. If foreign contracts are anticipated, the Project Manager shall assure that there is appropriate Headquarters review when required, and that such contracts are prepared with appropriate export control provisions.
  2. Applicable contracts with U.S. industry that support an international project shall also include appropriate provisions related to export control requirements.
  1. Export control requirements and milestones shall be included in project plans.
  2. When foreign nationals are involved, the Project Manager shall plan for internal technology transfer controls.
  3. The Project Manager shall identify export license requirements and shall obtain any required export licenses prior to exporting.
  4. As applicable, the Project Manager shall instruct contractors and partners of NASA obligations under international agreements, and of their responsibility for obtaining proper authority for any contractor and partner exports.
  5. The Project Manager shall advise foreign partners of the sensitive nature of export controlled hardware, software, and data prior to transfer.

3.2.2 Cost Estimation

3.2.2.1 Purpose: This activity develops credible cost estimates to support a variety of systems engineering trade studies, affordability analyses, strategic planning, capital investment decision making, and budget preparation. It also provides information for independent assessment, as may be required. Good cost estimation is a critical capability needed to ensure the credibility of the project's resource and financial decision-making, and in the larger view, of NASA's financial management system. Cost estimating should be consistent with the NASA Cost Estimating Handbook.

3.2.2.2 Requirements: The Project Manager and the project team shall:

3.2.2.2.a Develop an initial Life Cycle Cost Estimate (LCCE).

  1. The Project Manager shall develop an initial LCCE consistent with the project WBS, schedule, and performance parameters to form the project estimate (to be included in the initial Project Plan, Part 2, Resources.)
  1. All cost and workforce estimates shall be summarized according to the NASA standard product line WBS and time phased by Government Fiscal Year (GFY).
  2. The project estimate shall always use the latest available full cost accounting initiative guidance and practices.
  1. The project estimate shall include reserves, along with the level of confidence provided by the reserves.
  2. (3) Upon completion of the initial LCCE, the Project Manager shall provide it to the Program Manager.

3.2.2.2.b Prior to the NAR, update the project estimate.

  1. The Project Manager shall ensure that all elements of the project LCCE are internally consistent and have been updated in time for the NAR (at which time it is designated the NAR estimate).
  2. In the event that the (Category I and II) project LCCE and ICE do not agree and cannot be reconciled, the OCFO Cost Analysis Division will provide a recommended cost position to the MDAA (or MSOD), Chief Financial Officer, and Chief Engineer, who together will make a recommendation to the Agency or Mission Directorate PMC. The Project Manager shall defer to their decision.

3.2.3 Systems Engineering

3.2.3.1 Purpose: The purpose of systems engineering is to ensure that the project accomplishes its goals in the most technically robust and cost-effective way possible. Systems engineering provides the integrating technical processes to define, develop, produce and operate the project's systems. As such, the processes involved in systems engineering span the project life cycle and the total technical effort. During formulation, the focus of systems engineering is on planning the systems engineering effort, obtaining and validating a set of system requirements, performing systems analysis to ensure that effective choices are made, defining the preferred system solution through a preliminary design, and planning system verifications and validations. During formulation, these activities lead to the project's NAR Baseline for which implementation approval is sought. (See Figure 3-1.)

3.2.3.2 Overall the flow of the detailed systems engineering processes described below is iterative with any one phase of the system/product lifecycle and is recursive at lower and lower levels of the system structure. Any or all of the processes may need to be repeatedly used in the orderly progression of the project baseline. As an example of the iterative nature, during the course of trade studies, specific requirements, interfaces, or design solutions may be identified as non-optimal and changed to increase system-wide performance, achieve cost savings, or meet scheduling deadlines. As an example of the recursive nature, requirements definition occurs at the system level and also at the subsystem and component levels. Even though it occurs at different times in the system/product lifecycle, the same process is applied.

3.2.3.3 Requirements: The Project Manager and the project team shall:

3.2.3.3.a Plan systems engineering tasks.

  1. The Project Manager shall establish the project's overall systems engineering scope and approach, and document it in the Project Plan, Part 3, Systems Engineering.
  1. The Systems Engineering Plan shall comply with an Agency-approved systems engineering standard.
  2. The Systems Engineering Plan shall describe how the standard's systems engineering processes will be instantiated by the project, including metrics, and shall identify any deviations and waivers from the standard.
  1. The Project Manager shall identify and plan a series of cost-performance trade studies.26
  1. These trade studies shall, as a minimum, consider safety, performance, life cycle costs, project risks, technology alternatives, schedule, environmental concerns, operations and logistics, and infrastructure issues.
  2. In performing these trade studies, the Project Manager shall evaluate the advantages and risks of securing elements of the project from outside sources including partnerships and co-ventures with other government agencies, academia, industry, and foreign organizations.
  1. The Project Manager shall plan software engineering tasks per NPR 7150.2, Software Engineering Requirements and NASA Standard 8739.8, Software Assurance Standard.

3.2.3.3.b Define, validate, and manage project requirements. The Project Manager and project team shall flow down program requirements to define a validated set of high-level project requirements prior to entering implementation.27


26 The terms, trade studies, trades, tradeoff analyses, and analysis of alternatives are often used interchangeably, even though the scope of such activities may vary widely.
27 AO-driven projects in the Discovery Program, for example, generate Level 1 requirements from the Step 2 proposal+s Concept Study Report, rather than the Program Plan. The requirements are then documented as an appendix to the Program Plan. .

3.2.3.3.c Perform system analyses. The Project Manager and project team shall complete planned cost-performance trades such as Analysis of Alternatives (AoA) studies, Cost as An Independent Variable (CAIV) assessments, mission success probability assessment, and other systems analyses. (Reference L.2.a(8) provides useful detailed information on planning and conducting a formal AoA.)

  1. Early in formulation, and in cooperation with the customer, the Project Manager shall define key performance parameters (KPPs) for the project that are selected on the basis of their close relationship with mission success criteria. These KPPs should appear in trade studies as measures of effectiveness and/or measures of performance.
  2. As a result of these studies and analyses, but prior to the end of formulation, the Project Manager shall specify quantitative values (a goal value and a threshold value) for each KPP, which will then be incorporated into the Project Baseline (along with the related mission success criteria, schedule, and LCCE) and which will be used to evaluate project performance. For each KPP, the goal is the performance level that the project team is striving for, and the threshold is the minimum performance level that the MDAA (or MSOD) and Program Manager agree is acceptable for the system-of-interest or end item deliverable.
  3. As a result of these studies and analyses, the Project Manager shall also establish a close link between each KPP and project technical performance requirements.
  4. The Project Manager shall provide the final quantitative values of each KPP to the independent assessment (IA) organization as part of the NAR Baseline.

3.2.3.3.d Define a preferred system design. The Project Manager and project team shall collect and allocate project requirements into an implementable architecture. This activity typically leads to a preliminary design of the system(s) to be developed.

3.2.3.3.e Plan verification and validation efforts. The Project Manager and the project team shall complete the Verification and Validation (V&V) Plan and incorporate it into the Project Plan, Part 3, Test and Verification.

  1. (1) The V&V Plan shall clearly identify the approach to the verification of each requirement.
  2. (2) The V&V Plan shall include software/hardware integration and appropriate independent verification and validation of software.
  3. (3) The V&V Plan shall clearly identify the approach to system validation.

Figure 3-1. Systems Analysis and Trade Study Activities During Formulation

3.2.4 Independent Technical Authority

3.2.4.1 Purpose: The purpose of ITA is to establish sound technical requirements and decisions for safe and reliable system operations. During formulation, ITA establishes technical requirements as part of the project's planned technical approach, once the high-level requirements have been defined by the Mission Directorate (or Mission Support Office).

3.2.4.2 The NASA Chief Engineer has established ITA through a system of Technical Warrant Holders (TWHs), who are funded independently of programs and projects. The TWHs are also administratively in a separate management and reporting chain from the program and project. Ideally, the TWH is organic with the project and may also serve as the lead system engineer for the project (or project chief engineer). Once the high-level requirements have been defined by the Mission Directorate (or Mission Support Office), the TWH, with support from the Project Manager and project team, establishes and maintains the subordinate technical requirements. For requirements associated with safe and reliable operations involving human safety, the TWH is the final authority. For requirements that do not affect safe and reliable operations involving human safety, the Project Manager is the final authority with input from the Technical Warrant Holders. When unresolved issues exist between the Project Manager and the TWH, the Project Manager and the TWH will each raise the issue up their respective reporting chains for adjudication.

3.2.4.3 Requirements: During formulation:

3.2.4.3.a Early in project formulation, the Project Manager, in consultation with the MDAA (or MSOD), shall recommend a Technical Warrant Holder. The NASA Chief Engineer selects the Technical Warrant Holder.

3.2.4.3.b Once the high-level requirements have been defined by the Mission Directorate (or Mission Support Office), the Project Manager shall support the TWH in the establishment and maintenance of the subordinate technical requirements.

  1. (i) The Project Manager shall defer to the TWH in determining which standards and requirements affect safe and reliable operations involving human safety.
  2. (ii) The Project Manager shall only accept variances regarding technical standards and requirements affecting safe and reliable operations involving human safety when approved by the TWH. This does not preclude the Project Manager from requiring more extensive investigation.

3.2.4.3.c The Project Manager shall communicate unresolved conflicts with the TWH to the Program Manager, and then to the appropriate MDAA (or MSOD) if required. Likewise, the TWH reports unresolved conflicts with the Program/Project Manager to the NASA Technical Authority (NASA Chief Engineer).

3.2.5 Project Assessment and Control

3.2.5.1 Purpose: Through the project assessment and control activity, the Project Manager provides direction and exercises control over all aspects of the project. The purpose of this activity is to maintain synchronization between project plans and requirements, and the resources to be allocated to meeting them, using elements of the Project Plan, budgets, schedules, KPPs, and supplier, partner, and customer agreements. This activity provides the Project Manager with accurate feedback and information on the status and conduct of the project against plans, KPPs, technical and operational requirements, risks, schedules, supplier and other agreements, budgets, and other resources.

3.2.5.2 Requirements: The Project Manager and the project team shall:

3.2.5.2.a Begin to execute the Project Control Plan as early as practical in formulation.

  1. The Project Manager shall review the EVM guidance provided in paragraph 3.4.3.2 to determine the appropriate application of EVM to the project.
  2. The Project Manager shall develop a Project Control Plan and incorporate it into the Project Plan, Part 3, Project Control.
  3. The Project Manager shall ensure that all elements of the Project Control Plan are fully operational prior to the NAR.

3.2.5.2.b Establish and conduct a continuum of technical and management reviews.

  1. Reviews provide a venue for communication, coordination, and integration of project activities. The Project Manager shall develop a Project Review Plan and incorporate it into the Project Plan, Part 3, Reviews.
  2. The Project Manager shall conduct the formulation phase internal reviews, as specified in the Project Review Plan, to ascertain the status of the project, and to provide an integrated, independent technical assessment of the project's technical risk, and its readiness to proceed to the next level of maturation.
  3. At each such review, the Project Manager shall synthesize and document engineering and management inputs, issues, and recommendations (e.g., Review Item Discrepancies, Requests for Actions).
  1. All such review inputs shall be subsequently analyzed and recommendations/action items tracked and dispositioned.
  2. An index of review inputs and recommendations shall be maintained and made available at all subsequent reviews.

3.2.5.2.c Establish and implement configuration management. The Project Manager shall develop a Configuration Management Plan and incorporate it into the Project Plan, Part 3, Configuration Management. 28


28 Various supporting engineering disciplines have specific configuration management policies and procedural requirements that support project-level configuration management. (See NPR 7150.2 for content requirements for software configuration management plans.)

3.2.5.2.d Put in place a comprehensive risk management decision making process.

  1. In accordance with NPR 8000.4, Risk Management Procedures and Guidelines, the Project Manager shall establish a continuous risk management (CRM) process that identifies risks; analyzes their impact and prioritizes them; develops and carries out plans for risk mitigation or acceptance; tracks risks and the implementation of mitigation plans; supports informed, timely, and effective decisions to control risks and mitigation plans; and assures that risk information is communicated and documented. (The CRM process is shown in Figure 2-1.)
  2. The Project Manager and project team shall develop a Risk Management Plan that meets the program requirements for CRM processes as described in paragraph 2.2.2.d and incorporate it into the Project Plan, Part 3, Risk Management.
  3. Risk identification shall involve the entire project team to assess all identifiable risks and project constraints up front. If an Independent Assessment (IA) has been performed, the project shall include the risks identified during the assessment as input.
  4. Each project shall follow the CRM process steps as shown in Figure 3-2; this process is iterated throughout the project life cycle. Specifically, the Project Manager and the project team shall:
  1. Identify. Develop the risk statements in terms of condition and consequence(s); capture the context of the risk scenario; e.g., what, when, where, how, and why. Tools such as Failure Modes and Effect Analyses (FMEA), Probabilistic Risk Assessment (PRA), and Fault Tree Analyses (FTA) can be used to identify risks. During engineering product development, risk will be identified and addressed in the final product as part of a risk management plan, in accordance with systems safety engineering practices.
  2. Analyze. Evaluate risk probability, impact/severity, and timeframe (when action needs to be taken); classify/group with similar/related risks; and prioritize. Tools such as Probabilistic Risk Assessment (PRA) can be used to analyze risk.
  3. Plan. Assign responsibility, determine approach (accept, mitigate, or watch); if risk will be mitigated, define mitigation level (e.g., action item list or more detailed task plan) and goal and include budget estimates.
  4. Track. Acquire/update, compile, analyze, and organize risk data; report results; and verify and validate mitigation actions.
  5. Control. Analyze results, decide how to proceed (replan, close the risk, invoke contingency plans, and continue tracking); execute the control decisions.
  6. Communicate and document. Essential risk status is to be communicated on a regular basis to the entire project team, as well as to the GPMC. A system for documentation and tracking of risk decisions will be implemented.

Figure 3-2: The Continuous Risk Management Process Steps

  1. The Project Manager shall use the risk management process as a basis for decisions to mitigate cost, schedule, technical, environmental, security, or safety risk. Examples include, but are not limited to, mission success criteria; development schedule; budget limits; launch window and vehicle availability; international partner participation; critical single-source suppliers; security or environmental concerns; human space flight safety issues; "fail ops/fail safe" requirements; facilities and infrastructure limitations; technology readiness; surveillance requirements; and amount and type of testing.
  2. For each primary risk, the project shall develop and maintain the following in accordance with the Risk Management Plan and, as appropriate, in the PCA.
  1. Description of the risk, including pri , mary causes and , contributors, , actions , embedded in the program/project to date to reduce or control it, and information collected for tracking purposes.
  2. Identify primary consequences (including effects on safety, project cost, schedule, and performance) should the undesired event occur.
  3. Estimate of the probability (qualitative or quantitative) of occurrence together with the uncertainty of the estimate. The probability of occurrence should take into account the effectiveness of any implemented risk mitigation measures.
  4. Characterization of the risk as "acceptable" or "unacceptable" with supporting rationale.
  1. (7) Characterization of a primary risk as "acceptable" shall be supported by the rationale, with the concurrence of the GPMC, that all reasonable mitigation options (withi , n cost, schedule, and technical constraints) have been instituted. Moreover, the GPMC must concur that, given the risks and their impact on the probability of the project meeting its requirements, the expected value of the project is still sufficient to justify the costs of undertaking it.

3.2.5.2.e Identify project standards and practices.

  1. The Project Manager shall document the technical standards and any intended variances from NASA Preferred Standards as identified by the TWH in the Project Plan, Part 3, Standards and Practices.
  2. The Project Manager shall acquire approvals from the Technical Warrant Holder, and other authorities as appropriate, before executing any variances from mandatory NASA standards or specifications as established in Section 3.2.4.
  3. In accordance with the Standards and Practices section of the Project Plan, the Project Manager shall ensure that designs utilize the International System of Units (SI, metric measurement system), in concurrence with NPD 8010.2, Use of the SI (Metric) System of Measurement in NASA Programs.

3.3 Project Approval

3.3.1 Purpose: The project approval process is an ongoing effort by senior NASA management to determine the project's readiness (at key milestones) to proceed with the next project phase.29 To secure project approval, the Project Manager must prepare (or revise) key project management documents (Project Plan, etc.) and submit them to the GPMC at a decision review meeting.


29 For existing projects, re-approval may be required during implementation as a result of proposed changes to the PCA and Project Plan based on budgetary, technical, or institutional considerations.

3.3.2 The term "ongoing" is used in paragraph 3.3.1 because the number of key milestones at which decision reviews are required varies from project to project. The number and focus of decision reviews depends on the project's product line and development strategy. Most projects will have at least one decision review--the NAR--occurring between formulation and implementation. Flight systems and ground support projects will have additional decision reviews that are identified in Chapter 6. Basic and applied research portfolios and real property institutional projects are exempt from the requirements of Section 3.3.

3.3.3 Requirements: In support of GPMC decision review meetings during project approval:

3.3.3.a The Project Manager shall support evaluation by the IA organization in accordance with the project evaluation process. (See Section 3.5.)

3.3.3.b The Project Manager shall prepare a project readiness overview briefing for presentation at the GPMC milestone decision review meeting to include a summary of the project, the status of project documentation and products, concurrence of TWH on technical requirements (including all variances), and significant risks, all appropriate to the level of project maturity.

3.3.3.c The Project Manager shall prepare (and/or submit) the project documents and products described in Table 3-1.

3.3.3.d At that meeting, the IA results and findings, including an ICE for Category I and II projects, will also be presented. The Project Manager shall then follow with a presentation of responses to the IA findings.

3.3.4 When all presentations are concluded, the GPMC convenes an executive session to discuss the material presented and determines whether to recommend approval to the appropriate decision authority. The decision authority for Category I projects is the Deputy Administrator; for Category II projects, the MDAA (or MSOD); and for Category III projects, the Center Director (of the executing Center). A positive recommendation may be unconditional, or conditional on the Project Manager completing assigned action items, some of which address the IA organization findings. A negative recommendation by the GPMC could result in the decision authority either directing the Project Manager to address the deficiencies, or in the authorization of a termination review. If project approval requires a modification to the PCA, the MDAA (or MSOD) is responsible for obtaining PCA approval by the Deputy Administrator. Upon GPMC approval, the project's NAR Baseline is formally established.

Table 3-1. Key Project Documents and Product Maturity by Decision Review

3.4 Project Implementation

3.4.1 Project implementation entails continued execution of the Project Plan and all design and development activities leading up to the successful transition-to-use of the product or service that meets the original requirements and customer expectations, followed by operations through final disposition of project assets. Project implementation requires close interaction between the project team and the customer(s).

3.4.2 The Project Manager and project team executes implementation activities in accordance with the controlling documents developed during formulation and the approval process, but during implementation, projects may be impacted by external forces, such as budget modifications, schedule, or requirements changes, and internal situations, such as technology challenges or new requirements. Formulation products may need to be revisited to ensure that the planning is consistent with commitments and resource availability. If necessary, agreements (PCAs, Program and Project Plans) are modified and approved in accordance with the approval process. During project implementation, the Project Manager with the project team performs the following activities:

  1. Project assessment and control.
  2. Customer advocacy.
  3. Systems engineering.
  4. Design, develop, transition-to-use, and operations.
  5. Independent technical authority engagement.
  6. Capture knowledge.

3.4.3 Project Assessment and Control

3.4.3.1 Purpose: Through the project assessment and control activity, the Project Manager provides direction and exercises control over all aspects of the project. The purpose of this activity is to ensure that the project is making progress commensurate with the resources expended. This activity provides the Project Manager with accurate feedback and information on the status and conduct of the project against plans, KPPs, technical and operational requirements, risks, schedules, supplier and other agreements, budgets, and other resources.

3.4.3.2 Requirements: The Project Manager and the project team shall:

3.4.3.2.a Execute the Project Control Plan. The intent of this requirement is to maintain close configuration control of requirements, to assess the cost, technical and schedule status of the project relative to the NAR Baseline. Therefore:

  1. EVM principles as defined by EIA-748-A 30 shall be applied to all projects (contractor and civil service) exceeding $20M total project cost. However, the MDAA (or MSOD) can require EVM principles be applied to any project or activity.
  2. A fully validated EVM system as defined by EIA-748-A shall be applied to all projects (contractor and civil service) exceeding $50M total project cost. However, the MDAA (or MSOD) can require a fully validated EVM system be applied to any project or activity.
  3. In implementing (1) and (2) above, the Project Manager shall ensure (for all applicable procurements) the appropriate provisions and clauses are included in solicitations and contracts.
  4. For projects requiring EVM, the Project Manager shall conduct and complete Integrated Baseline Reviews (IBRs) on projects to ensure the validity of the baseline.

30 These principles are listed here for clarity: (1) plan all work scope for the project to completion; (2) break down the project work scope into finite pieces that can be assigned to a responsible person or organization for control of technical, schedule, and cost objectives; (3) integrate project work scope, schedule, and cost objectives into a performance measurement baseline plan against which accomplishments may be measured and control changes to the baseline; (4) use actual costs incurred and recorded in accomplishing the work performed; (5) objectively assess accomplishments at the work performance level; (6) analyze significant variances from the plan, forecast impacts, and prepare an estimate at completion based on performance to date and work to be performed; and (7) incorporate Earned Value Management into the project+s decision-making and review processes.
  1. The IBR shall be accomplished within six months after contract award or after approval of the Project Plan by the MDAA (or MSOD).
  2. The IBR shall be accomplished within two months after definitization of significant scope changes or after budget realignment.
  1. Surveillance of contractor EVM systems is normally delegated to the Defense Contract Management Agency (DCMA) in accordance with the NASA/DCMA Memorandum of Understanding (MOU) for Earned Value Management System Acceptance/Surveillance and Earned Value Management Project Surveillance. When such surveillance is to be delegated, the Project Manager shall, in coordination with the Contracting Officer, initiate the action for the Contracting Officer to issue a letter of delegation to the responsible DCMA activity. The letter of delegation shall define the specific support, products, services, etc., to be provided by the DCMA. (See FAR Part 42.2.)
  2. Expenditures shall be accumulated according to the WBS established for the project and in as near-real time as possible. Consistent with Continuous Cost-Risk Management (see reference L.2.a(1)), in addition to standard WBS-level performance measurement reporting, performance measurement of medium- and high-risk WBS elements identified during life cycle cost estimation shall be provided to the Project Manager through specification in the Cost Performance Report (CPR) Data Requirements Description (DRD) and/or the Project Plan.
  3. The full cost of civil service labor shall also be accumulated according to the WBS to permit later integration into full cost accounting and reporting.
  4. Use of EVM is optional in contracts with research institutes and in grants of any type. In such cases, when EVM is appropriate to the project but not to such project components, the Project Manager shall include in the Project Plan, Part 3, Control, the strategy for integrating cost and schedule aspects of those project components.

3.4.3.2.b Manage reserves.

  1. Project Managers have the authority to make decisions, allocate reserves, and modify the implementation path in response to new information. The Project Manager shall closely monitor the application of project reserves.
  2. The Project Manager shall treat all program transfers to the project during implementation, other than planned project reserve funds being held by the Program Manager, as augmentations to the Project Baseline. This includes the use of civil service labor above the staffing plan provided by the project. Such transfers may not imply an impending breach, but the Project Manager must follow paragraph 3.4.3.2e.

3.4.3.2.c Perform continuous risk management.

  1. The Project Manager and project team shall perform the five-step continuous risk management process of Figure 3-2 during implementation.
  2. The Project Manager shall ensure that all elements of the Risk Management Plan are followed.
  3. The Project Manager shall communicate risk mitigation actions taken, the effectiveness of risk mitigation activities, and residual risks to the Program Manager for QSR briefings.
  4. All risks shall be dispositioned before the transition to operations or the equivalent for an advanced technology project.

3.4.3.2.d Conduct the implementation phase reviews specified in the Project Review Plan.

  1. The Project Manager shall conduct the implementation phase internal reviews, as specified in the Project Review Plan, to ascertain the status of the project and to provide an integrated, independent technical assessment of the project's technical risk and its readiness to proceed to the next level of maturation.
  2. For each review, the Project Manager shall synthesize and document engineering and management inputs, issues, and recommendations (e.g., Review Item Discrepancies, Requests for Actions).
  1. All such review inputs shall be subsequently analyzed, and recommendations/action items tracked and dispositioned.
  2. An index of review inputs and recommendations/action items shall be maintained, and made available at all subsequent reviews.

3.4.3.2.e Provide information and data regarding a breach of the NAR Baseline.

  1. The Project Manager shall monitor project performance and provide trending data to the Program Manager.
  1. For the cost metric, cost growth shall be measured after project approval using the latest project cost Estimate at Completion (EAC) against the NAR cost baseline (the approved NAR estimate). (Since the NAR estimate contains project reserves, cost growth occurs only when these reserves are exhausted.)
  2. For the schedule metric, schedule growth shall be measured after project approval using the latest project schedule Estimate at Completion (EAC) against the NAR schedule baseline. The schedule baseline shall start from the date of project FAD approval and shall extend through project completion (considered to be end of prime mission for long-lived projects).
  3. KPP changes shall be measured using the latest project performance against the NAR threshold values.
  1. The Project Manager shall report to the Program Manager when the results of surveillance reviews conducted by IA organizations indicate that a breach is to be expected.
  2. When projected cost or schedule performance exceeds the NAR Baseline by ten percent (10%), or a KPP breaches its threshold value, the Project Manager shall report the breach to the Program Manager and the information shall be presented to the GPMC.
  3. The Project Manager shall coordinate with the Program Manager to provide a proposed continuation or termination plan to the GPMC.

3.4.3.2.f Evaluate and coordinate actions related to changes in project scope, requirements, schedules, funding, or anticipated progress. Changes to the Project Baseline that lead to commensurate changes in the procurement requirements and deliveries shall be quickly communicated in the form of procurement change documentation.

3.4.3.2.g Maintain configuration management.

  1. The Project Manager shall ensure that baselined project documents are maintained under configuration management.
  1. The Project Manager shall maintain configuration management on all drawings, design specifications, part selections, and other means of documenting aspects of the design (e.g., close-out photographs).
  2. Final versions of design documentation shall reflect the "as-built," "as-delivered," or "as-deployed" configuration of the system/asset.
  1. The Project Manager shall place all dimensions of the Project Baseline (cost, schedule, and KPPs) under configuration management, retaining the Project Baseline at the time of the NAR (the NAR Baseline) as the datum against which changes are measured.

3.4.3.2.h Maintain project team awareness of emergency response plans and procedures. Specifically, the Project Manager shall test those procedures at planned intervals during project implementation.

3.4.3.2.i Protect intellectual property and technology. The Project Manager shall protect contractor proprietary data provided in support of Government analyses and reviews, and maintain required non-disclosure agreements (NDAs).

3.4.4 Customer Advocacy

3.4.4.1 Purpose: The purpose of this activity is to proactively consult and involve customers in the implementation process to ensure customer satisfaction with delivery of quality products and services within budget and schedule commitments. It provides internal implementation process advocacy of customer interests in project decision forums.

3.4.4.2 Requirements: The Project Manager and the project team shall:

3.4.4.2.a Maintain close customer interactions per the Project Plan. Specifically, the Project Manager shall proactively consult and involve customers in implementation activities, especially efforts that impact requirements and KPPs.

3.4.4.2.b Involve customers as an integral part of evaluating progress against commitments.

3.4.5 Systems Engineering

3.4.5.1 Purpose: The purpose of systems engineering is to ensure that the project accomplishes its goals in the most technically robust and cost-effective way possible. Systems engineering provides the integrating technical processes to define, develop, produce and operate the project's systems. As such, the processes involved in systems engineering span the project life cycle and the total technical effort. In implementation, the focus of systems engineering is on transforming the selected design solution into an integrated set of products/services that comply with the baselined system requirements, verifying those requirements, transitioning the end products to use, and validating those products/services.

3.4.5.2 Requirements: The Project Manager and project team shall:

3.4.5.2.a Define, validate, and manage project requirements.

  1. Throughout implementation, the Project Manager shall maintain a well-documented hierarchy of validated project requirements.31
  2. The Project Manager shall ensure that the hierarchy of requirements and the resulting end-item specifications, including those for software, GFE, and operations, are maintained under configuration management, and that modifications to requirements are recorded in a change log as part of overall project configuration management mechanisms.
  3. The Project Manager shall evaluate changes in requirements that impact safety, quality, cost, schedule, and performance, and incorporate the impacts as changes to the Project Baseline.

31 The project software requirements are developed and documented in compliance with NPR 7150.2.

3.4.5.2.b Manage technical resource margins (e.g., mass, volume, power). The Project Manager shall manage all technical resource margins and apply project-level technical reserves as needed during design maturation.

3.4.5.2.c Implement the closed loop problem tracking process developed during formulation. (See paragraph 3.2.1.2.d(2)(iv).)

3.4.5.2.d Comply with the Standards and Practices section of the Project Plan.

  1. The Project Manager shall ensure that standards and practices identified in the Project Plan are implemented.
  2. The Project Manager shall acquire approvals from the Technical Warrant Holder, and other authorities as appropriate, before executing any variances from mandatory NASA standards or specifications as established in Section 3.2.4.

3.4.5.2.e Complete verification and validation (V&V) activities.

  1. The Project Manager shall implement the V&V strategy outlined in the V&V Plan. The Project Manager and project team should be ready to adjust the plan during implementation to deal with unexpected events and the need for additional verification.
  2. The Project Manager shall be responsible for assuring that proper inspection, testing, screening, and/or other verifications have been performed.
  1. Test plans shall include acceptance criteria.
  2. Test data shall be fully documented and maintained to support downstream analyses of project products and services, and of any operational anomalies and mishaps, if needed.
  1. Deliverable products/services shall be verified prior to transfer for operations.

3.4.6 Design, Develop, Transition-To-Use, and Operations

3.4.6.1 Purpose: This activity develops the specific project products and services, and establishes the supporting infrastructure for continuing production, training, sustaining engineering, logistics, and operations. For flight systems and ground support projects, the integration of design, development, manufacturing, verification and validation, certification, operations capability development, launch operations and checkout, and in-space operations are major elements of this activity.

3.4.6.2 Requirements: The Project Manager and the project team shall:

3.4.6.2.a Implement the technology strategy.

  1. The Project Manager shall closely monitor the readiness of advanced technology developments occurring within the project or being supplied under partnering agreements, as per the technology strategy, for the purpose of exercising alternative technology options before the project's cost and schedule are at risk. Technologies supplied by outside sources should be tracked as high risk deliveries until such time that objective data can confirm that lower risk levels are appropriate.
  2. The Project Manager shall ensure that adequate resources are made available to document the design, development, certification, and validation of technologies created under project auspices.
  3. The Project Manager shall periodically update the appropriate Center and Headquarters commercialization offices with information relevant to the commercialization of project-developed intellectual property (i.e., technologies, discoveries, innovations, tools, processes, or software) by U.S. industry.

3.4.6.2.b Generate a procurement package for each acquisition action.

  1. The Project Manager shall generate a procurement package that contains a statement of work including performance standards, specifications, documentation deliverables, and other applicable data.
  2. In this process, the Project Manager shall use a Draft Request for Proposals (DRFP) as required by NFS 1815.201, Exchanges with Industry Before Receipt of Proposals, to ensure that comments on acquisition requirements (from contractors and other potential providers) are obtained. When a DRFP is not required, the Project Manager should consider a less formal method for obtaining industry comment.

3.4.6.2.c Develop and execute contracts and non-procurement instruments.

  1. In collaboration with the appropriate Center and/or Headquarters offices, the Project Manager shall develop or select the most appropriate acquisition instrument, per the Acquisition Plan, to satisfy program and project goals.
  2. The Project Manager shall assist the Contracting Officer in the solicitation and award of contracts, and in the development of a plan to ensure appropriate surveillance, monitoring, and reporting of activities related to contracts and non-procurement instruments in accordance with Federal law and regulations.
  3. If systems being acquired contain software, the Project Manager shall ensure compliance with the software contract requirements in NPR 7150.2, NASA Software Engineering Requirements.

3.4.6.2.d Closely monitor contractor performance.

  1. The Project Manager shall ensure that adequate contract mechanisms are in place to ensure timely and complete receipt of contractor (or grantee) financial and progress reports throughout the contract life cycle.
  2. With the aid of the Contracting Officer (or other cognizant acquisition specialist), the Project Manager shall continually assess the performance of each contractor (or grantee). The Project Manager has a responsibility to ensure that the value of items or services received remains commensurate with the plan for funds expended.
  1. EVM shall be used as a tool to monitor contractor performance as described in paragraph 3.4.3.2.
  2. Records of contractor and grantee performance shall be maintained in accordance with Government, Agency, Mission Directorate, and Center policies to support future source selection activities.
  3. The Project Manager and the Contracting Officer shall report the Government's assessment of performance to the contractor (or grantee).
  1. In cases where the Defense Contract Management Agency (DCMA) conducts or supports the performance monitoring function, the Project Manager shall ensure that DCMA responds to requests for information in a timely fashion.
  2. The Project Manager and the Contracting Officer shall perform surveillance of contractor safety and mission assurance performance in accordance with NPR 8735.2, Management of Government Safety and Mission Assurance Surveillance Functions for NASA Contracts.

3.4.6.2.e Ensure that safety and reliability are an integral part of the product/service design, development, production, and operations. Specifically, where the safety of the public, NASA or contractor personnel is at risk, the Project Manager shall reinforce NASA's first core value, Safety, and emphasize to the project team that safety of the public, NASA flight crews, government and contractor employees, and Agency critical assets is of paramount importance.

3.4.6.2.f Ensure compliance with property control rules and regulations. ,

  1. , The Project Manager shall ensure that property control rules and regulations are carefully followed. Specifically, the Project Manager shall ensure that:
  1. Property is safeguarded at all times.
  2. Equipment, systems, components, and other elements of hardware and software developed under contract(s) and/or grant(s) are not transported without required documentation being executed.
  3. Parts, equipments, and components under NASA control are stored in secure facilities with environmental controls and location tracking appropriate to the value of the property.
  1. The Project Manager shall also ensure that NASA personnel follow property control rules and regulations when accessing parts and equipment under property control by contractors.
  2. The Project Manager shall ensure that NASA personnel follow Agency guidance in procuring spare parts per NPR 5900.1, NASA Spare Parts Acquisition.

3.4.6.2.g Execute Quality Assurance Plans.

  1. (1) The Project Manager shall ensure that government, contractor, and grantee personnel follow design, development, manufacturing, and fabrication quality assurance practices matched to the investment that the project represents.
  2. (2) The Project Manager shall ensure the completeness and integrity of Quality Assurance Plans or other documentation developed to measure the quality of products and services delivered by the project.

3.4.6.2.h Transition the system/asset to the end-user for operations.

  1. (1) The Project Manager shall establish and maintain an integrated logistics support capability to enable continued operations consistent with the system/asset's intended use.
  2. (2) The Project Manager shall ensure that adequate checkout of the system/asset is performed, and that formal acceptance of the delivered item(s) is secured at the appropriate transition point.

3.4.6.2.i As part of sustaining engineering, perform trend analyses.

  1. (1) The Project Manager, with the TWH, shall monitor system incidents, problems, and anomalies, as well as system margins to ensure that deployed project systems function as intended.
  2. (2) Adverse trends shall be carefully evaluated and alerts shall be issued to the Program Manager, if adverse trends cannot be reversed.
  3. (3) The Project Manager shall ensure that project engineering data related to failures, anomalies, evaluations, problems, incidents, and Requests for Action (RFAs) are captured, retained, and made available to the NESC upon request.

3.4.6.2.j Ensure the orderly disposition of the system/asset at the end of its useful life.

  1. (1) The Project Manager shall ensure that all requirements are met for archiving, preserving, transferring, and/or disposing of data, information, hardware, and software components.
  2. (2) Records shall be maintained that track disposed assets.
  3. (3) For assets with retained value, an asset valuation shall be performed prior to final disposition.

3.4.7 Independent Technical Authority

3.4.7.1 Purpose: The purpose of ITA is to establish sound technical requirements and decisions for safe and reliable system operations. During implementation, the ITA maintains project technical standards, requirements, and procedures as established in Section 3.2.4.

3.4.7.2 Requirements: During implementation, the Project Manager and the project team shall:

3.4.7.2.a Include the Technical Warrant Holders (TWHs) as a part of the Project Manager's analysis, evaluation, and technical decision-making processes.

3.4.7.2.b Ensure that variances from technical standards and requirements affecting safe and reliable operations have been approved by the TWH and other authorities as appropriate.

3.4.7.2.c Communicate unresolved conflicts with the TWH to the appropriate MDAA (or MSOD). Likewise, the TWH reports unresolved conflicts with the Program/Project Manager to the NASA Technical Authority (NASA Chief Engineer).

3.4.7.2.d Obtain the technical approval of the cognizant TWH for the guiding technical requirements governing the conduct of risk assessments and analysis.

3.4.8 Capture Knowledge

3.4.8.1 Purpose: The intent of this activity is to accrue knowledge in an organized fashion to improve the performance, and reduce the cost and risk of future programs and projects, and to adhere to Federal and NASA requirements for records management and retention. Lessons learned are disseminated by the OCE and reflected in modifications to NASA training and technical standards and practices.

3.4.8.2 Requirements: The Project Manager and the project team shall:

3.4.8.2.a Ensure that project engineering and cost data, technical management information, and official project records (collectively called the project library) are captured electronically, retained, secured, disseminated, and managed in accordance with agreements, the Project Plan, and program, Center, and Agency policies.

3.4.8.2.b Provide the OCE with inputs to the Lessons Learned Information System in the form of captured experiences and lessons learned by the project team throughout the project lifecycle, for example, at major milestones.

3.5 Project Evaluation

3.5.1 NASA's leadership places a high value on independent review of programs and projects as an unbiased quality check of the engineering and management efforts.

3.5.2 Purpose: Evaluation provides an independent assessment (IA) of the ability of the project to meet its technical and programmatic commitments. The evaluation process utilizes independent review teams composed of knowledgeable, independent experts from outside the advocacy chain of the project. Evaluation during formulation supports the approval process by providing findings and supporting data needed to decide whether to proceed to implementation. Evaluation during formulation assesses whether a project supports the Agency vision and strategic goals, and whether that project can be successfully conducted within available resources and applicable constraints. Evaluation during implementation assesses whether a project continues to contribute to Agency vision and goals, is being successfully executed according to the Project Plan, and provides findings to enhance the project's technical and programmatic performance.

3.5.3 These evaluations are generally planned to minimize disruptions to the project and avoid unnecessary duplication of review events. In keeping with that policy, NASA will adjust its project evaluations and management accountability hierarchy to accommodate programs that are an evolving system-of-systems. Specifically, when a program uses an evolutionary acquisition approach, reviews of projects under that program by the GPMC will occur at the "spiral level" milestones, and milestone decision meetings for the major program elements (i.e., projects) will be held by the GPMC to coincide with the spiral decision reviews.

3.5.4 Requests for external audits and assessments of projects may come from the Congress, the NASA Inspector General, the Government Accountability Office (GAO), advisory groups such as Science Advisory Committees, and other similar sources. When requested, the OCE will coordinate responses to external review requests, work in concert with the MDAA (or MSOD) to disposition such requests, and coordinate the scheduling of such activities with the Project Manager, Program Manager, and GPMC.

3.5.5 Special-purpose independent reviews (e.g., Termination Review) will be conducted when directed by the GPMC, the Mission Directorate, (or the Mission Support Office). Requests for special purpose reviews may come to the GPMC from customers, line organizations, or others. Elements such as the anticipated inability of a project to meet its commitments, an unanticipated change in Agency strategic planning, or an unanticipated change in the NASA budget may initiate such reviews.

3.5.6 Because independent reviews require a significant investment of resources, NASA seeks to minimize the number of these external reviews that the Project Manager and project team must support. For basic and applied research activities, evaluation relies on peer review and this section is not applicable. (See Chapter 4, Section 4.5 for applicable requirements.) Advanced technology development projects have only one GPMC decision review--the NAR. (See Chapter 5, Section 5.5, for applicable requirements). Flight systems and ground support projects will be evaluated at multiple designated GPMC decision reviews and through surveillance conducted after NAR approval on Category I and II projects. (See Chapter 6, Section 6.5 for applicable requirements.)

3.5.7 The general process flow leading to each GPMC project decision review is as follows: The Project Manager schedules project site field review events with the IA organization. During the IA organization site field review, the Project Manager presents a detailed project briefing, which demonstrates the project's readiness to continue. This briefing includes a project cost estimate. At the end of the IA organization site field review, the IA organization provides a preliminary verbal outbrief to the Project Manager. The IA organization prepares an initial briefing and briefs the Project Manager. The Project Manager reviews the initial briefing's findings, facts, and assumptions, and provides a formal response to the IA organization. The IA organization and Project Manager brief the Program Manager, Center management (if applicable), and the Mission Directorate on findings and program responses. The IA organization prepares a final briefing and issues it to the Project Manager and GPMC members. After the final briefing is issued, the Project Manager and IA organization brief the GPMC.

3.5.8 Requirements: To accomplish the project evaluation process, the Project Manager shall:

3.5.8.a Plan project team and schedule resources to support IA for the NAR decision review. For initial planning purposes, the Project Manager should consult Table H-3 in Appendix H. The project's planning schedule may be modified through negotiation with the IA organization.

3.5.8.b Comply with the evaluation Terms of Reference (ToR) or equivalent for all independent reviews.

  1. The ToR or equivalent is prepared by the IA organization through negotiation with the Project Manager and Program Manager, MD (or MSO) point-of-contact, or appropriate organization. The ToR is approved by the OCE and the MDAA (or MSOD). The ToR (or equivalent) specifies the details of conducting site field review events, including the schedule, deliverable items and areas of project risk. For IAs performed by IPAO or SMO, if the negotiating parties cannot agree on the ToR scope and content, the OCE shall be the final decision authority.
  2. The final schedule shall be documented in the evaluation Terms of Reference (ToR).

3.5.8.c Prepare project briefings and material demonstrating the project's readiness to continue, and present them at the IA organization site field review. These briefings shall include a project cost estimate. The Project Manager should consult Table H-1 in Appendix H for other assessment criteria.

3.5.8.d Review the initial IA organization briefing's findings, facts, and assumptions, and provide a formal response to the IA organization.

3.5.8.e Comply with external requests for evaluation and audit (e.g., Congress, OMB, the NASA Inspector General, GAO, etc.).

3.5.8.f Support any additional independent reviews or technical assessments that may be required during formulation and implementation as directed by the Administrator, GPMC, MDAA, the OCE (including the NESC), or the Office of Safety and Mission Assurance. The Project Manager shall provide formal responses to action items/recommendations from these reviews for closure.

3.5.8.g Ensure that project engineering data related to failures, anomalies, evaluations, problems, incidents, and Requests for Action (RFAs) are captured, retained, and made available to the NESC upon request.

3.5.8.h In cases where a major project milestone (as identified in the Project Plan, Part 2, Schedules) slips but may not appear to breach the overall project completion, the Project Manager shall notify the Program Manager and GPMC. In order to understand the consequences of the slip, the GPMC may direct an independent assessment to determine the impact on project completion schedule, cost, safety, technical performance, and residual risks.

3.5.8.i Provide support for a Safety and Mission Assurance Readiness Review (SMARR) prior to any launch or safety critical event or other activity selected by the Chief SMA Officer.


CHAPTER 4. Basic and Applied Research Portfolios

SPECIAL NOTICE: Chapter 4 & 5 of this NPR has been cancelled by NPR 7120.8.

4.1 Four-Part Portfolio Management Process

4.1.a Basic research addresses the need for knowledge, while applied research directs this new knowledge toward a practical application. Basic and applied research is directly tied to the Agency Vision and strategic goals. The results of this research may expand the knowledge base, may provide scientific and technological breakthroughs that are immediately applicable, or may evolve into an advanced technology development (ATD).

4.1.b Basic and applied research investments are typically carried out under programs associated with Themes, and are managed as portfolios of investigations, sometimes organized and managed as a project. A portfolio consists of one or more investigations. Each investigation is managed by a Principal Investigator (PI), who has been selected from NASA, academia, industry, non-profit organizations, or State and local governments normally through a competitive process and peer review. These investigations are characterized by unpredictability of outcome, high risk, and funding usually at a fixed level on a yearly basis. The progress and relative value of such investigations are continually assessed, and the portfolio is adjusted accordingly. The basic and applied research portfolio lifecycle is shown in Figure 4-1. Because of the unique features of basic and applied research, management processes differ substantially from those used for traditional project management. Consequently, the requirements of Chapter 3 are replaced by the requirements in this chapter.

4.1.c NASA management practices for basic and applied research are intended to assure that portfolios reflect the probability of success since success or a certain outcome cannot be guaranteed.32 NASA management practices are also intended to assure that, over time, NASA-funded portfolios are highly productive, based on qualitative and quantitative evaluations. Basic and applied research portfolios strive for quality and relevance to the NASA Vision and strategic goals. Not all research investigations will be successful, but most will result in knowledge and discoveries from which new opportunities will flow. Further, research portfolios and investigations are intended to be flexible, and have the ability to be assimilated or infused into current or new research, decision support and other information systems, technology application, or ATD projects in NASA and other agencies to take advantage of innovation and improve the competitive position of domestic industries.


32 Balance must also reflect the different scientific and technology disciplines that must be supported, and the appropriate mix of intramural and extramural funding.

4.1.d The primary mechanisms for assuring quality in basic and applied research are open competition and peer review, where peer review means independent evaluation by internal or external subject matter experts who do not have a conflict of interest. NASA solicits most basic and applied research proposals for investigations through three forms of Broad Agency Announcements (BAA)--NASA Research Announcements (NRA), Announcements of Opportunity (AO), and Cooperative Agreement Notices (CAN). Proposals are evaluated for relevance to the NASA Vision and strategic goals; scientific, engineering, technical, programmatic or educational merit; and cost realism, cost reasonableness, and cost performance history.

4.1.e This chapter establishes requirements for the Portfolio Manager using the four-part management process of paragraph 1.7.1. The Portfolio Manager operates under the requirements of this chapter, NPD 1080.1, NASA Science Policy, NPR 1080.1, Science Management, NASA procurement regulations such as the NASA FAR Supplement, Agency-level agreements with partners, Mission Directorate Handbooks, the Guidebook for Proposers to NASA Research Announcements, and the criteria identified in research solicitations such as the annual Research Opportunities in Space and Earth Sciences (ROSES).

Figure 4-1 Basic and Applied Research Portfolio Lifecycle

4.2 Portfolio Formulation

4.2.a In portfolio formulation, the Portfolio Manager builds a collection of research investigations that supports the NASA Vision, strategic goals, Theme objectives, and program goals, and which can be successfully conducted within available resources and applicable constraints. Portfolio formulation is initiated when a portfolio (project-equivalent) Formulation Authorization Document (FAD) (or equivalent such as a Program Plan section) is signed, and a Portfolio Manager is designated by the MDAA (or MSOD) and the Program Manager.

4.2.b During formulation, the Portfolio Manager performs and orchestrates the following activities:

  1. Portfolio process planning
  2. Proposal solicitation, evaluation, and selection.

4.2.1 Portfolio Planning Requirements: The MDAA- or MSOD-designated Portfolio Manager shall:

4.2.1.a Prepare a Portfolio Process Plan.

  1. At a minimum, the Portfolio Process Plan shall:
  1. Define and document portfolio objectives that support Agency, Theme, and program goals. The Portfolio Manager coordinates with the cognizant MDAA (or MSOD) and Program Manager.
  2. Define a process for the solicitation, evaluation, and selection of proposals (including identifying Selection Official(s)).
  3. Establish evaluation criteria including considerations of quality, relevance to NASA missions and strategic goals, and performance.
  4. Include an integrated portfolio budget typically for three or five years (including appropriate WBS elements).
  5. Include a multi-year schedule for the portfolio.
  6. Include portfolio evaluation processes.
  1. Create a management and control structure to implement the Portfolio Process Plan.

4.2.1.b Obtain approval of the Portfolio Process Plan. The Portfolio Manager shall forward the Portfolio Process Plan to the Program Manager for approval.

4.2.2 Proposal Solicitation, Evaluation, and Selection Requirements: The Portfolio Manager shall:

4.2.2.a Initiate solicitation and receipt of proposals through the issuance of a Broad Agency Announcement following the process established in the approved Portfolio Process Plan. Prospective PIs participate in portfolio formulation by preparing and submitting proposals in response to a solicitation. Research proposals for individual investigations include proposed research designs, budgets, schedules, and expected outcomes.

4.2.2.b Using peer review processes established in NPR 1080.1, Science Management, evaluate proposals based on the criteria established in the solicitation.

4.2.2.c Recommend proposals for selection. Specifically, the Portfolio Manager shall:

  1. Review findings from peer review and other factors, and recommend selections for approval by the Selection Official.
  2. Include the rationale for selection or non-selection of each proposal evaluated.
  3. Include a description of all research activities within the portfolio including activities that are continued from previous years.

4.3 Portfolio Approval

4.3.1 The MDAA (or MSOD) through the designated Selection Official shall review the recommendations and supporting information, and if acceptable, approve the selection of investigations for award.

4.4 Portfolio Implementation

4.4.1. Purpose: During portfolio implementation, the Portfolio Manager monitors the performance of investigations selected for inclusion in the portfolio, and adjusts the portfolio composition following evaluation, usually on a cyclical basis until the portfolio is terminated.

4.4.2 Requirements: The Portfolio Manager shall:

4.4.2.a Initiate funding for selected investigations.

4.4.2.b Update the portfolio to include the specific details of the new research investigations that have been selected.

4.4.2.c Encourage PIs to communicate their results through activities such as:

  1. Submitting progress reports (at least on an annual basis) that summarize research results to date.33
  2. Publishing research results in peer-reviewed publications, participating in scientific and technical society meetings, major conferences, workshops, and carrying out other similar efforts.

33 Final reports for investigations funded through grants and contracts are archived in the NASA Scientific and Technical Information System, as specified in NPR 2200.2, Requirements for Documentation, Approval, and Dissemination of NASA Scientific and Technical Information.

4.4.2.d Maintain and report performance metrics in electronic form as required by NPR 1080.1, Science Management, and report it to the NASA Office of the Chief Scientist (OCS).

4.5 Portfolio Evaluation

4.5.1 Purpose: Portfolio evaluation assesses whether the portfolio is contributing to the NASA Vision, Theme and program goals, and is being successfully executed according to the approved Portfolio Process Plan. Portfolio evaluation results in recommendations for enhancing the portfolio's performance.

4.5.2 Requirements: Evaluation is a multi-level process in which the Portfolio Manager shall:

4.5.2.a Evaluate investigations within a portfolio largely during peer review following solicitation and during performance of the investigation by review of progress reports submitted by the PI during implementation.

4.5.2.b Review portfolio scope annually, describe changes in portfolio scope in solicitations, and report changes in annual evaluations.

4.5.2.c Provide information to support evaluation of portfolio performance as specified in the Program Plan.

4.5.3 The outcome of a portfolio evaluation can be continuation, continuation with changes, or termination.


Chapter 5. Advanced Technology Development Projects

SPECIAL NOTICE: Chapter 4 & 5 of this NPR has been cancelled by NPR 7120.8.

5.1 Four-Part Project Management Process

5.1.a NASA advanced technology development (ATD) programs and projects are investments that produce entirely new capabilities or that help overcome technical limitations on a system-of-interest. This document distinguishes between basic and applied research programs and projects, on the one hand, and ATD programs and projects on the other. The principal distinction is that, in the former, a technologist is given adequate time and resources to prove the merits of a new concept, whereas in the latter, a concept has already been shown to be successful enough to warrant further investment in order to make it ready for application. NASA uses Technology Readiness Levels (TRLs) as a maturity measurement technique. (See Appendix F for a description of Technology Readiness Levels.) Basic and applied research generally reflects lower TRL levels, whereas ATD projects reflect TRLs 4 through 6. Because TRLs are somewhat subjective, some ATD projects may fall outside this range. ATD is seen as a bridge between basic and applied research and actual application in NASA or elsewhere.

5.1.b ATD projects may be a part of a program whose sole purpose is technology development, or they may be embedded in a flight systems and ground support program. In both programmatic structures, however, the Program Plan must designate its component ATD projects, and ATD Project Managers must comply with the requirements of the four-part management process described in Chapter 3 as clarified and modified by this chapter. Figure 5-1 shows the ATD project lifecycle.

Figure 5-1. Advanced Technology Development project lifecycle

5.1.c ATD projects present unique management challenges. Often an ATD "project" (within NASA's budget and financial structure) is actually a large collection of tasks, each of which is small in budget and produces a discrete product or service. The Project Manager in this case coordinates the collection of tasks, but is required to create only one Project Plan. Occasionally, an ATD project will be large enough to be Category I or II.34 In this case, additional management requirements are imposed.


34 System-level X-type vehicles (such as the X-33) are examples of large ATD projects. For the purposes of determining project category, ATD Program and Project Managers should calculate LCC based on the entry and exit TRLs for the ATD project.

5.1.d NASA values technology infusion, whether into NASA flight projects or the U.S. economy as a whole. Flight projects and other users tend to embrace a new technology when sufficient maturity has been aptly demonstrated, and applicability to a mission or missions is abundantly clear. When a user "pulls" a technology into a mission or other use, the ATD Project Manager has successfully infused the technology. This requires close interaction with potential users of the new technology to overcome the many practical design and system integration challenges. To foster higher infusion rates, this document requires ATD projects to identify potential adopters and to ensure that progress is measured not only in terms of maturation level (TRL), but also through quantifiable key performance parameters (KPPs) important to those adopters. The combination of KPPs and TRLs not only enhances progress communication at key milestones, but also provides a more balanced assessment of risks and rewards in ATD projects.

5.2 Project Formulation

5.2.1 The work that constitutes formulation for an ATD project is mainly project planning and cost estimation. It is expected that some adjustment of management plans and products will be needed to comply with the requirements of Chapter 3, depending on the size, complexity, and priority of the ATD investment.

5.2.2 Requirements: The ATD Project Manager and the project team shall:

5.2.2.a Perform technology portfolio analyses. The Project Manager shall ensure that portfolio analysis studies are conducted to justify technology selections. Techniques such as Alignment Matrices, ROI vs. Risk Matrices, Technology S-curve Maps, etc. can be used to determine the best mix of technologies that will balance the project's risk posture.

5.2.2.b Identify a set of project KPPs (a goal value and a threshold value for each).

  1. These KPPs shall be defined as the performance parameters associated with the end item delivery of the technology to the application community. The KPPs must consist of measurable engineering parameters that would be readily understood and used by engineers concerned with the ultimate application of the technology. For each KPP, the goal is the performance level that the project team is striving for, and the threshold is the minimum performance level that users agree is acceptable for the end item deliverable. Typically the threshold KPPs values are set beyond the current state-of-the art to warrant investment in the project.
  2. When the ATD project contains multiple tasks and end items deliverables, KPPs shall be identified for each task or end item deliverable.

5.2.2.c Complete the project estimate.

  1. With the cognizant Program Manager, the Project Manager shall establish a project cost estimate based on the delivery of technology end items with the agreed-upon KPPs at the required end TRL.
  2. The basis of cost and schedule estimates, including defined reserves, shall be defined in relation to the goal and threshold KPP values.

5.2.2.d Prepare a Project Plan containing the elements described in Appendix D, with the following modifications:

  1. In Part 2, Resources, the Project Manager shall employ the standard WBS template for the overall structure of the project.
  2. In Part 2, Performance, the Project Manager shall describe the project's KPPs and establish the quantitative value for each to be achieved at each project milestone. This relationship can be in the form of a matrix that shows the KPP range (goal and threshold) and TRL to be achieved at each planned major demonstration or test.
  3. In Part 2, Schedule, the Project Manager shall include a detailed schedule showing project milestones or planned major events. Managers are encouraged to identify alternative development paths in order to maximize the probability of success.
  4. Only Project Managers of Category I and II ATD projects are required to complete Part 2, Acquisition Project Baseline.
  5. Part 3, Technology Strategy shall be replaced with Part 3, Technology Insertion, and the Project Manager shall describe how the technology end item deliverable(s) (product or service) will transition to application or user adoption (i.e., a technology transfer strategy). In this section of the Project Plan, the Project Manager shall maintain close integration with the application community, and provide an exit strategy following technology transfer.
  6. Part 3, Reviews shall include a description of planned Continuation Reviews for technology pull projects. The Continuation Reviews are decision points for the users to determine if the technology maturation is still viable to meet the users' requirements. The Continuation Reviews shall have users' concurrence on their schedule frequency, participants, and review criteria.

5.3 Project Approval

5.3.1 To secure approval for ATD projects, the Project Manager shall ensure that project deliverables are clearly defined and that proposed plans allow for quantitative measurements of performance that can be objectively assessed. ATD projects, like other projects, are subject to a NAR with an independent cost estimate (for Category I and II projects) prior to implementation. ATD Project Managers are expected to update the Project Baseline for the NAR; upon approval, the project's NAR Baseline is formally established. The requirements of Section 3.3 apply to ATD projects with the modifications in Section 5.2 above.

5.4 Project Implementation

5.4.1 ATD project implementation requires continuing interaction between the project team and the user or application community.

5.4.2 Requirements: During implementation, the ATD Project Manager and the project team shall:

5.4.2.a Monitor cost and schedule for breaches as required by paragraph 3.4.3.2e. A breach for ATD projects is measured against cost and schedule growth. The Project Manager shall provide notification to the Program Manager, the MDAA, and the GPMC when the growth in the projected (or actual) cost and schedule needed to deliver the threshold KPPs exceeds ten percent (10%).

5.4.2.b Communicate progress to the Program Manager and user/application community.

  1. The maturation progress of a technology at project milestones shall be measured using KPPs and TRLs.35
  2. The Project Manager shall ensure that internal technical reviews of progress are conducted at each project milestone to validate achieved values for each KPP. The Project Manager should secure concurrence from the internal review team that the project has met the quantitative values for each KPP at the milestone prior to reporting progress to the Program Manager. The Program Manager reports maturation progress for each ATD project to the GPMC.

35 The use of "spider diagrams" to convey progress is encouraged but not required. In some technologies, TRLs may not be appropriate, and the Project Manager may substitute another form for describing maturation progress.

5.4.2.c The Project Manager shall ensure that changes to threshold KPPs established in the NAR Baseline are captured as part of updates to the Project Baseline.

5.5 Project Evaluation

5.5.1 It is expected that only rarely will ATD projects be Category I, so Project Managers will normally report to Center and Mission Directorate PMCs. Agency visibility into the progress of ATD projects will occur through program reviews at regularly scheduled QSRs at the Agency PMC, and through any reviews conducted by IPAO of programs containing ATD projects. The requirements of paragraph 3.5.3 apply.


SPECIAL NOTICE: Chapter 6 of this NPR has been cancelled by NPR 7120.5D, March 6, 2007.

Chapter 6. Flight Systems and Ground Support Projects

6.1 Four-Part Project Management Process

6.1.a Flight systems and ground support projects are often the most visible and complex of NASA's product lines. Because of this, these projects must emphasize safety and mission success as primary drivers in order to justify the substantial time and resources they require. These projects typically have formulation periods of one to three years because of the need to conduct system analyses, select the best mission concept, and retire technological risks to the point where implementation can begin. They typically have even longer implementation periods for design, development, testing, and operations. Due to this, NASA has found it useful to decompose the project life cycle for flight systems and ground support projects into more incremental pieces that allow managers to assess management and engineering progress. Consequently, this document re-institutes the NASA project life cycle consisting of Phases A through F.

6.1.b Project formulation consists of two sequential phases, traditionally denoted as Phases A and B, while project implementation consists of Phases C, D, E and F. Approval marks the transition from Phase B of formulation to Phase C of implementation. The start of Phase E marks the transition from primarily development activities to primarily systems operations and sustaining and maintenance activities. Independent evaluation activities occur throughout all the phases. While not formally a part of formulation, some formulation-type activities will naturally occur as part of advanced studies. These fall into a part of the project life cycle known as Pre-Phase A.

6.1.c Some of these flight systems and ground support projects have long-term operations and sustainment periods, lasting decades.36 In these cases, the Project Manager needs to maintain a strategic view and value flexibility while managing established operations and sustainment activities. The new Vision for Space Exploration also envisions an evolving system-of-systems, in which established operations and sustainment activities will likely exist along side new flight systems and ground support projects seeking enhanced capabilities in an evolutionary acquisition approach ("spirals").


36 The Shuttle and International Space Station are examples. These strategic investments are generally so large that the pressure to cut development costs can lead to increased operations and sustainment costs downstream. For this reason, additional requirements to ensure the visibility of these downstream costs are needed for such programs/projects. In this chapter, the terms Project Manager and project will be used even when it is a single-project program.

6.1.d In recent times, NASA has chosen to establish several new flight projects using a one or two-step Announcement of Opportunity (AO) process. These projects are often referred to as "AO-driven." AO solicitations are often used for the development of small and mid-sized scientific spacecraft, and are cost-capped and highly competitive. Several PI-led teams prepare detailed proposals aimed at meeting program-level requirements, and a winner is selected at the end of a rigorous selection process. Pre-Phase A includes the development of Step 1 proposals and Phase A develops Step 2 proposals. Since the selection process involves a great deal of independent assessment, the normal requirements for a preliminary NAR are waived, and the emphasis shifts to the NAR (or equivalent, often referred to as the Confirmation Review (CR)) at the end of Phase B for review and approval.

6.1.e As a result of these different approaches to acquisition, this document recognizes variations from the traditional flight systems and ground support project cycle. Figure 6-1 shows the project lifecycle and GPMC milestone decision reviews for these different approaches.

Figure 6-1. Flight Systems and Ground Support Project Lifecycle Phases
and Milestone Decision Reviews

6.1.f New cost estimation requirements for flight systems and ground support projects are another important addition to this document. Category I and II projects must develop a CADRe. Cost-risk identification and quantification of medium- and high-risks are an integral new addition to project lifecycle cost estimates. Consistent with Continuous Cost Risk Management (CCRM), these medium- and high-risks are identified for performance measurement reporting in the application of earned value management. While conceptually related to the DoD CARD, the CADRe is NASA's unique response to the need to improve cost estimates during formulation, and to do project grass roots and independent cost estimation based on the same information. The CADRe is a comprehensive document, developed and configuration controlled by the project, that provides a technical and quantitative description of the project in terms that permit the development of a LCCE. Typically, the contractor and/or NASA project engineers, assisted by cost estimators and the Center SMO, construct the CADRe. The CADRe should be considered a "living document", which is matured at major milestones.

6.1.g With the CADRe as a basis, each flight systems and ground support project is expected to develop a risk-based LCCE, and to manage that as part of the Project Baseline through a process called CCRM (Continuous Cost Risk Management), described in Reference L.2.c(1). At the end of the project lifecycle, the project's actual cost, schedule, and technical parameters by WBS are then captured in the ONCE (One NASA Cost Engineering) database as part of the project library.

6.1.h Flight systems and ground support projects shall meet the requirements of the four-part management process described in Chapter 3 and the requirements in this chapter. For projects for which the concept of operations requires activities such as extensive refurbishment of a flight system, extensive re-supply or maintenance (ground and on-orbit), additional requirements are imposed to cover additional planning, analysis and other activities necessary for a successful Phase E. These will generally be preceded with the phrase "For projects with long-term operations and sustainment" in italics. These additional requirements are not intended for projects with extended cruise time.

6.2 Project Formulation

6.2.a Because of the challenges and uncertainties associated with developing these projects, it is essential that formulation activities fully prepare the project for implementation, and where applicable, long-term operations and sustainment. During formulation, the Project Manager performs and orchestrates the following activities:

  1. Project planning.
  2. Cost estimation.
  3. Systems engineering.
  4. Project assessment and control.

6.2.1 Project Planning Requirements: The Project Manager and the project team shall:

6.2.1.a Structure the detailed product-based project WBS and WBS dictionary based on the standard WBS in Appendix J, or shall obtain approval for WBS tailoring from the OCFO and OCE.

6.2.1.b Generate a Contract WBS that supports cost/schedule control requirements for each contract following contractor selection or authority to proceed to implementation (see paragraph 3.4.3.2 for detailed EVM requirements).

6.2.1.c Generate and maintain an Integrated Master Schedule (IMS) in the form of a detailed, logic-driven, highly-integrated network schedule using an automated project management (automated time phasing of tasks, critical path determination, schedule assessment, trend analysis, sort, select, and summarization capabilities, etc.) tool.

  1. The project's progress against the IMS shall be assessed and updated monthly, or more often as required, to meet the program/project needs for assessment, control and communication.
  2. The IMS baseline shall be managed through an established schedule change control process.
  3. Schedule reporting during the project shall be done in accordance with the authorizing documents (e.g., Project Plan, Data Requirements Description (DRD), Schedule Management Plan (SMP)).
  4. For projects with long-term operations and sustainment, identify the Initial Operational Capability (IOC) and Full Operational Capability (FOC) dates in the Integrated Master Schedule.

6.2.1.d Obtain the additional approval of the cognizant MDAA for the Project Plan, at the discretion of the Mission Directorate.

6.2.1.e Develop a Software Management Plan in accordance with NPR 7150.2, NASA Software Engineering Requirements.

6.2.1.f Form an operations team organization compatible with the operations portion of the WBS and the project's flight and ground operations concept. This team shall include expertise in the following areas: flight operations, ground operations, safety, mission assurance, logistics, sustaining engineering, and any other expertise required for a successful Phase E, and/or Phase F.

  1. For projects with long-term operations and sustainment, the Communications Plan shall discuss safety and problem reporting during long-term operations.
  2. For projects with long-term operations and sustainment, the operations team shall conduct operational planning and analyses to support the flight systems and ground support project and to prepare for the transition of flight assets to long-term operations.

6.2.1.g Assure that the project team seeks to learn and apply relevant lessons from successful flight systems and ground support projects, mission anomalies and mishaps.

6.2.1.h Maintain the project team awareness of emergency response plans and procedures. The Project Manager and project team shall develop, maintain and test their project-specific plans (e.g., ground and mission emergency/contingency/failure plans) to ensure the team is adequately trained and prepared.

6.2.2 Cost Estimation Requirements: The following requirements apply to both AO-driven and non-AO-driven flight systems and ground support projects, with exceptions for AO-driven projects noted:

6.2.2.a For Category I and II projects, the Project Manager shall complete a preliminary CADRe (Parts A and B), in accordance with Table H-4 in Appendix H. Appendix E contains the initial CADRe DRD, but the latest CADRe DRD, available in the on-line NASA Cost Estimation Handbook (http://www.ceh.nasa.gov/), should be used. For AO-driven projects, the requirement for a preliminary end-of-Phase A CADRe is waived in lieu of the submission of a copy of the winning proposal and concept study report.

6.2.2.b For Category I and II projects, the Project Manager shall develop a risk-based LCCE (including a project cost S-curve) consistent with the preliminary CADRe for presentation at the preliminary NAR. This LCCE is called the project estimate and is appended to the CADRe as Part C.

6.2.2.c For Category I and II projects, the Project Manager shall develop a Baseline CADRe and a risk-based LCCE (including a project cost S-curve) consistent with the Baseline CADRe for presentation at the NAR. This LCCE is called the NAR estimate and is appended to the CADRe as Part C. AO-driven Category I and II projects shall develop a risk-based LCCE (including a project cost S-curve) consistent with the Baseline CADRe for presentation at their Confirmation Review. This LCCE is called the CR estimate and is appended to the CADRe as Part C.

6.2.2.d Category I and II projects shall provide updated CADRe submissions (all parts37 ) at:

  1. Critical Design Review (CDR),
  2. Approximately six months after launch (to capture the project's technical definition and its Phase A through D costs), and
  3. At the end of the planned project lifecycle (to capture final Phase E through F costs).

37 If Part A has not changed, it does not have to be resubmitted.

6.2.2.e For projects with long-term operations and sustainment, the Project Manager shall work with the OCFO to establish a nominal project end date for the purpose of estimating operations and sustainment costs.

6.2.3 Systems Engineering Requirements: The Project Manager and the project team shall:

6.2.3.a Working with the Mission Directorate, Program Manager, customers and stakeholders, define a validated set of project requirements that are levied by the program and that include mission success criteria. These high-level project requirements shall be placed under configuration control in Phase A

6.2.3.b Develop operations scenarios and concepts, mission profiles, and mission operational modes for the purpose of fostering a better understanding of operational requirements, including LCC drivers for logistics and maintenance. The concept of operations describes the "who, what, when, where, and how" of the system.

6.2.3.c Define the internal and external operational environments for the flight system.

6.2.3.d For projects with long-term operations and sustainment, the concept of operations shall include the operational KPPs; the sustaining engineering, mission operations, ground operations, and integrated logistics support (e.g., maintenance concepts(s), sparing philosophy) concepts necessary for a successful Phase E.

6.2.3.e For projects with long-term operations and sustainment, complete planned cost-performance trades, Analysis of Alternatives (AoA) studies, Cost As an Independent Variable (CAIV) assessments, and other systems analyses that include these operational KPPs as measures of effectiveness/measures of performance.

  1. As a result of these studies and analyses, but prior to the end of formulation, the Project Manager shall specify quantitative values for each operational KPP, which will then be incorporated into the Project Baseline (along with the related project success criteria, schedule, and LCCE) and which will be used to evaluate project performance.
  2. As a result of these studies and analyses, the Project Manager shall also establish a close link between each operational KPP and project operational performance requirements.

6.2.3.f Define a validated set of flight and ground system requirements, including interface requirements and specialty engineering (e.g., safety, reliability) requirements.

6.2.3.g Define a validated set of enabling system requirements, especially for integrated logistics support. (See NPD 7500.1, Program and Project Logistics Policy.)

6.2.3.h Ensure that the requirements flow hierarchy is consistent with the Work Breakdown Structure.

6.2.3.i Establish and maintain a (configuration-managed) requirements baseline in an established database.

6.2.3.j Evaluate major changes to the requirements baseline through the systems analysis process as needed prior to any approval of such changes.

6.2.3.k Ensure that trade studies are documented as part of the project library.

6.2.3.l Ensure that models and simulations used to support these trade studies have been validated. Early in formulation, the project team should identify, develop, or otherwise acquire and implement the models (including prototypes and simulations) needed to accomplish all trade studies.

6.2.3.m Identify and plan a series of trade studies to determine the most cost-effective means of meeting requirements for communications, tracking, data processing, and mission operations, including commercial options.

6.2.3.n For Category I flight systems and ground support projects, complete an initial Probabilistic Risk Assessment (PRA) during formulation. NPR 8000.4, Risk Management Procedural Requirements, provides general criteria for selecting the scope of the PRA, while NPR 8705.5, Probabilistic Risk Assessment Procedures for NASA Programs and Projects, provides detailed procedures for performing a PRA.

6.2.3.o Develop a technical resource margin management approach, and implement a tracking and reporting process to support it.

6.2.4 Project Assessment and Control Requirements: The Project Manager and the project team shall:

6.2.4.a Monitor changes in the project estimate presented at the preliminary NAR, and immediately inform the Program Manager if it increases by more than 25% in Phase B. The Project Manager should make every effort to produce a project cost estimate that contains an adequate cost-risk margin. During Phase B, life cycle cost growth beyond 25% of the preliminary NAR project estimate may result in a Termination Review initiated by the Program Manager or MDAA.

6.2.4.b Provide the MDAA a Project Status Report (PSR) in formats ready for reporting to the OCFO when required to do so, as defined in GAO Report B-237602, "Project Status Reports."38 The OCFO will validate the PSR and forward it, through the Office of Legislative Affairs, to the appropriate congressional committees.


38 A PSR is prepared for a flight development project when it reaches the $200 million cost threshold for its total estimated research and development. This includes launch vehicle costs and operations (Phase E) costs.

6.3 Project Approval

6.3.1 Purpose: The project approval process for flight systems and ground support projects is an on-going effort by senior NASA management to determine the project's readiness (at key milestones) to proceed to the next project phase or to implementation. To secure approval for a flight system and ground support project, the Project Manager shall prepare (or revise) key project management documents (Project Plan, etc.) and presents them to the GPMC at a decision review meeting.

6.3.2 In addition to the requirements in paragraph 3.3.4 that deal with the NAR, the Project Manager must also successfully pass a preliminary NAR at the Phase A to B transition. Flight systems and ground support projects using the AO process have the equivalent of the preliminary NAR in the Step 2 proposal selection process, and are exempt from requirements pertaining to the preliminary NAR. To avoid unnecessary duplication of review events, these decision review meetings for the first project in a program are generally timed to coincide with the program's preliminary NAR and NAR. For all programs that use evolutionary acquisition, there are two additional decision reviews--the Concept Decision Review, occurring before formal formulation activities start, and the Production Review, occurring during implementation before significant production activities start. Table 6-1 shows the required project decision reviews.

Table 6-1. Project Decision Reviews

6.3.3 NASA will modify its project evaluations and management accountability hierarchy to accommodate projects that are part of an evolving system-of-systems. Specifically, when a Mission Directorate uses an evolutionary acquisition approach, program decision reviews by the Agency PMC will occur at the "spiral level", and decision review meetings for the major program elements (i.e., projects) will be held by the GPMC to coincide with the spiral decision reviews. The NASA Deputy Administrator is the authority for these types of Agency PMC decision reviews. Because this is a new approach to project approval, NASA senior management plans to revisit the number and level of decision review meetings after some experience has been gained.

6.3.4 Requirements: In support of GPMC decision review meetings during project approval:

6.3.4.a The Project Manager shall support evaluation by the IA organization in accordance with the project evaluation process. (See Section 6.5.)

6.3.4.b The Project Manager shall prepare a project overview briefing for presentation at the GPMC milestone decision review meeting to include a summary of the project, the status of project documentation and products, and significant risks, all appropriate to the level of project maturity.

6.3.4.c The Project Manager shall ensure that the project documents and products described in Table 6-2 are available at the GPMC decision review.

6.3.4.d At that meeting, the IA results and findings, including the results of an ICE or ICA, will also be presented. The Project Manager shall then follow with a presentation of responses to the IA findings.

6.3.5 When all presentations are concluded, the GPMC convenes an executive session to discuss the material presented and determines whether to recommend approval to the appropriate decision authority. The decision authority for Category I projects is the Deputy Administrator; for Category II projects, the MDAA (or MSOD); and for Category III projects, the Center Director (of the executing Center). A positive recommendation may be unconditional, or conditional on the Project Manager completing assigned action items, some of which address the IA organization findings. A negative recommendation by the GPMC could result in decision authority direction to the Project Manager to address the deficiencies, or in a decision authority recommendation to the next higher GPMC decision authority to authorize a Termination Review. If project approval requires a modification to the PCA, the MDAA (or MSOD) is responsible for obtaining PCA approval by the Deputy Administrator. Upon GPMC approval, the project's NAR Baseline is formally established.

Table 6-2. Key Project Documents and Product Maturity by Decision Review

6.4 Project Implementation

6.4.a Project implementation entails continued execution of the Project Plan and all activities leading up to the successful delivery of the product or service that meets the original requirements. Successful project implementation relies on close interaction between the project team and the user and/or customer of the product or service. The Project Manager shall comply with the requirements in Section 3.4, and shall meet additional requirements in the following activities:

  1. Project assessment and control.
  2. Systems engineering.
  3. Design, develop, transition-to-use, and operations.
  4. Capture knowledge.

6.4.1 Project Assessment and Control Requirements: The Project Manager and the project team shall:

6.4.1.a Determine and implement appropriate means for observing the project in all phases where technical risks have been identified, along with a means for collecting, trending, archiving, and analyzing data for post-anomaly investigation.

6.4.1.b Implement a system to access "as-built" configurations, including photographic records and engineering drawings of all critical subsystem modifications, to assist in real-time troubleshooting.

6.4.2 Systems Engineering Requirements: The Project Manager and the project team shall:

6.4.2.a For Category I projects, ensure that the PRA is updated throughout implementation. The Project Manager should integrate PRA results into system design and operational risk mitigation trades.

6.4.2.b Track and report project technical resource margins periodically throughout implementation.

6.4.2.c Conduct Physical and Functional Configuration Audits.

6.4.2.d For projects with long-term operations and sustainment, evaluate (using the systems analysis process) upgrades or modifications to deployed project systems, alternative product improvement investments, and decommissioning/disposal alternatives, as needed.

6.4.3 Design, Develop, Transition-to-Use, and Operations Requirements: The Project Manager and the project team shall:

6.4.3.a Deliver, deploy, and transition-to-use project flight and ground systems.

6.4.3.b Deliver new technology through data, information, products, and services.

6.4.3.c Execute acceptance/turnover agreements and data for those products requiring transfer of custodial responsibility.

6.4.3.d Establish and maintain an integrated logistics support capability, including spares, ground support equipment, system maintenance and operating procedures, in order to sustain deployed hardware and software systems, consistent with mission requirements and plans.

6.4.3.e Establish and maintain other enabling systems, as needed, so as to ensure that critical facilities, equipment, materials, training, simulation support, and other services are available when needed.

6.4.3.f Provide sustaining engineering to promote efficiency enhancements, safety enhancements, and accommodate obsolescence.

6.4.3.g Refine and implement plans for disposition/decommissioning of project assets (flight and ground) after the end of their useful life.

6.4.3.h For projects with long-term operations and sustainment, the project during Phase E refines its operations success criteria, operations concept and plans to meet mission objectives specified in the Program and Project Plans, but the focus is on the tactical execution of the next mission increment, launch, or mission epoch. As the project produces its intended products and services, it continually explores new operations and sustainment options to meet the overall objectives, reduce operations costs and operational risks; fine tunes the internal management control functions that will be used throughout the remaining life of the project; assesses new technologies, modifications, and upgrades that potentially increase safety and performance, and lower operations costs; and tracks operational margins and reserves consistent with project safety requirements. If necessary, agreements (Program and Project Plans) are modified, and approved in accordance with the approval process. In order to accomplish this, the Project Manager and the project team shall:

  1. Refine program/project goals, objectives, and success criteria as a part of the ongoing validation of the deployed project systems,39 and ensure that these flow down as appropriate to lower-level operations plans.
  2. As applicable, refine and incorporate updated mission plans and technology upgrade strategies, infrastructure plans, acquisition strategies, technical and management implementation plans, space operations service agreements, launch services agreements, and other internal agreements into the Project Plan.
  3. Continually examine opportunities to exploit promising product improvement technologies that could reduce program/project operational risk, reduce LCC, gain performance, correct newly uncovered design defects, or overcome operational constraints. The Project Manager should make recommendations regarding which product improvement technologies should be funded by the project, and which should be , considered for funding at hi , ghe , r levels.
  4. Continue to work with the Office of External Relations and the MDAA to identify potential non-NASA partners and necessary agreements for international or interagency; all activities and documentation must be consistent with policy and with program or Agency-level agreements with partners.
  5. Ensure that the deployed project systems continue to function as intended, perform trend analyses40 as , needed of:

39 Deployed project systems refer to the as-deployed flight system and its associated enabling systems.
40 These analyses may be performed in conjunction with project control activities, such as risk management. If adverse trends are uncovered, it is expected that they will be communicated through the organization so that appropriate actions, such as a desired product improvement, may be initiated. The NASA Engineering and Safety Center (NESC) is available to complement program/projects efforts by providing an independent engineering assessments, testing, analyses and evaluation to uncover technical vulnerabilities, and to recommend appropriate preventative and corrective actions for problems, trends or concerns.
  1. System incidents, waivers/deviations, problem reports, and anomalies.
  2. Key performance parameters (KPPs) for operations and sustainment.
  3. Project technical resource margins.

6.4.4 Capture Knowledge Requirements: The Project Manager and the project team shall:

6.4.4.a Capture and forward summaries of project costs as a function of the WBS and other performance information, to the OCFO Cost Analysis Division for inclusion in the ONCE database using the CADRe format.

6.4.4.b Archive all relevant project records and data (drawings, analyses, reports, etc.) in the project library in electronic format.

6.5 Project Evaluation

6.5.1 Due to the visibility, risk and importance to the Agency, flight systems and ground support projects are assessed more frequently and monitored more closely than other types of projects. At a minimum, flight systems and ground support projects are subject to a preliminary NAR (Phase A to B), NAR (Phase B to C), and surveillance following the NAR. For the first project within a program, the decision reviews are conducted concurrently with the program reviews. For initial planning purposes, the Project Manager should consult Table H-4 in Appendix H. The flight development project evaluation process flow is the same as that for a project NAR as described in paragraph 3.5.8.

6.5.2 Flight development projects are closely monitored during implementation by IA organizations through a surveillance activity. The purpose of surveillance is to provide timely reporting to the GPMC when the project is showing adverse trends in its performance. After NAR approval, the responsible IA organization will conduct project surveillance by collecting timely performance data from the existing project performance reporting and activities (e.g. project quarterly reviews, monthly reviews, internal reviews, onsite visits, etc.). Successful surveillance depends on an open interface between the project team and IA organizations.

6.5.3 Requirements: To accomplish the project evaluation process, the Project Manager shall:

6.5.3.a Prepare project briefings and material demonstrating the project's readiness to continue, and present them at the IA organization site field review. The Project Manager should consult Table H-1 in Appendix H for other assessment criteria.

6.5.3.b Following the NAR approval, provide the IA organization access to project information databases, performance data, meetings, and NASA and contractor sites in accordance with the ToR. This includes access to project cost-performance evaluations, including EVM data for Category I and II projects.


CHAPTER 7. Institutional Projects

7.1 Four-Part Project Management Process

7.1.a To conduct its missions, NASA must also implement projects aimed at building institutional infrastructure. These investments are typically managed by Mission Support Offices with close linkage to and often direct funding from mission programs and projects. Several types of investments fall into the category of institutional projects: the development of real property, (construction of facilities (CoF) and environmental compliance and restoration (ECR)) projects, information technology (IT) projects, and other functional initiative (OFI) projects. This chapter provides requirements unique to the management of these institutional investments.

7.1.b NASA's real property investments represent institutional projects designed to acquire, maintain, remediate, and dispose of the facilities, plant, equipment, and systems needed to support programs and projects. NASA's goal is to ensure that when construction is needed, facilities are planned, designed, and constructed for sustainability. Project Managers must ensure that the facilities are of the right size and type; are safe, secure, and environmentally sound; provide quality workplaces; operate efficiently and effectively; and are retired when economically appropriate.41 Sometimes real property investments are funded directly from mission program or project budgets; at other times they can be funded from indirect funds, indicating general purpose use.


41 Proper asset valuation is key to being able to make strategic decisions about the recovery and maintenance of institutional elements so as to provide programs and projects with the most cost-effective solutions possible. Real property funded directly for use by a program or project has a retained value at the end of its initial use, a value that can exceed its original cost. Many NASA facilities find new uses that are impossible to foresee at the outset of their initial development.

7.1.c IT investments are a large part of NASA's annual spending and are critical to mission success as well as efficient day-to-day operations. These investments demand a great deal of interaction between Headquarters and the Centers to meet the complete set of Agency goals. As with real property investments, IT investments are sometimes funded directly from mission program or project budgets; at other times they can be funded from indirect funds, again indicating general purpose use.

7.1.d OFI investments capture a myriad of large and small projects that support NASA missions and Agency operations. The Integrated Financial Management System (IFMS) and educational projects are examples of OFI investments. OFI projects are always managed by Mission Support Offices, typically through cross-cutting Agency programs.

7.1.e Management approval of institutional projects is generally provided by a governing authority (e.g. Board, Council, Institutional Committee (IC)), including many of those funded directly from mission sources.42 Institutional projects are subject to the same categorization scheme as required of other projects. In most cases, institutional projects represent small-to-moderate Agency investments and are lower risk developments, placing them in Categories II and III. Some institutional projects can be Category I but regardless of size, the governing authority approves and reviews all categories of projects in accordance with their charter and processes.43 Figures 7-1 and 7-2 show the nominal project lifecycle for institutional projects.


42 In the case of institutional investments, references to the GPMC structure in Chapters 1, 2, and 3 should generally be replaced by references to the IC, and references to the MDAA by MSOD.
43 The Chair of the Agency PMC can, on occasion and by exception, require a Category I institutional project to report to the Agency PMC. This can occur when an institutional investment is especially critical to the mission success of a NASA program or project, or is viewed as vital to the overall performance of the Agency.

Figure 7-1: Capital Assets Project Life Cycle for Institutional Projects

Figure 7-2: Non-Capital Assets Project Life Cycle for Institutional Projects

7.1.f The Director of the Facilities Engineering and Real Property Division is the Agency's functional leader and authority for the breadth of NASA facilities matters, including master planning, facility requirements analysis and planning, life cycle cost analysis, design, construction, facilities budgeting strategy, acquisition/leasing, maintenance, utilization, and disposal. (See NPD 8820.2, Design and Construction of Facilities.) CoF investments, including facility improvements, modifications and upgrades, can be funded directly by programs and projects, or from Agency accounts. In all cases, CoF projects are institutionally managed. This means that when, for example, a flight project needs a new or upgraded facility to meet project requirements, the funding is supplied from the project budget, but the facility investment is managed by a facilities organization located at the appropriate Center or component facility. In normal practice, a Facility Project Manager (FPM) is appointed by the facilities organization to organize, manage, and direct the multitude of activities and complete the assigned facility project work on schedule with the approved funds. FPMs must comply with the requirements of NPD 8820.2, Design and Construction of Facilities, and NPR 8820.2, Facility Project Implementation Guide.

7.1.g The Director of the Environmental Management Division is the Agency's functional leader and authority for the breadth of NASA environmental matters, including pollution prevention, compliance, restoration, and conservation. (See NPR 8590.1, Environmental Compliance and Restoration Program Implementation.) Environmental Compliance and Restoration (ECR) investments are generally funded from Agency accounts. In all cases, ECR projects are institutionally managed. In normal practice, an Environmental Project Manager (EPM) is appointed by the environmental management organization to organize, manage, and direct the multitude of activities and complete the assigned environmental project work on schedule with the approved funds, as agreed to in a Center Spend Plan negotiated by the Center Environmental Manager and the Director of the Environmental Management Division. EPMs must comply with the requirements of NPR 8590.1, Environmental Compliance and Restoration Program Implementation.

7.1.h The requirements of Chapter 2 and 3 for NASA programs do not apply to CoF or ECR investments because real property program planning is contained within an existing overarching facility master plan consisting of a network of Center Real Property Master Plans (CMPs). Individual real property projects are addressed within the context of the CMPs. The ECR program consists of projects that are planned and negotiated between Centers, Headquarters, and regulatory agencies.

7.1.i The Chief Information Officer (CIO) establishes best practices for the development of IT solutions44 and maintains oversight responsibility for all IT investments in the Agency, which come in three types:


44 The CIO must integrate mission-unique IT systems, into other multi-user mission support investments, utilizing common infrastructure tools and services where practical. The result is the NASA Enterprise Architecture (EA) that is based on a broader Federal Enterprise Architecture. The EA also supports NASA's participation in the expanded electronic government initiative (e-Gov). NASA's EA is supported by the companion Information Resources Management (IRM) Strategic Plan, which provides long-range guidance to IT investments.
  1. Office Automation and Infrastructure Technology (OAIT) - indirectly funded services provided across the NASA community that fall into the following three classes: communications services (e.g., wide and local area networks, voice, and video); computing services (e.g., desktop computers, applications software, and data centers), and the electronic work environment (e.g., e-mail, messaging, collaborative systems, and the World Wide Web).
  2. Multi-program/project - services funded directly from mission accounts used to support multiple projects within a given Mission Directorate. These are generally funded at the mission program-level and managed as a separate institutional project within the program.
  3. Program/project-unique - services funded directly from mission accounts used to provide IT command, control, and data management services for a particular mission. These are generally funded at the mission project-level and are managed as a project work element.

Multi-program/project and program/project-unique IT investments are the responsibility of mission Program and Project Managers; as such, they report to a GPMC and are an exception to other institutional projects. However, the CIO maintains oversight and approval authority by virtue of his/her presence on the GPMC. OAIT investments are managed by the CIO. The CIO appoints Program Managers who, in turn, appoint Project Managers for OAIT projects.

7.1.j Because of the varied mix of institutional investments and the associated complexity of management responsibility, Table 7-1 is provided to guide institutional program and project managers. Institutional projects implement the same four-part management process as any NASA project with minor changes as outlined in the following sections.

Table 7-1 Institutional Projects Management Requirements Summary

7.2 Project Formulation

7.2.1 Institutional projects are similar to other projects in terms of the level of analysis and management practices needed for successful execution. As with other projects, the cognizant Mission Support Office will usually invest in a period of concept screening (e.g., business case analyses) prior to committing to an institutional project. This up-front effort is considered part of the project pre-formulation period, as referenced in paragraph 3.2.a. All IT projects require the submission of a business case in accordance with OMB Circular A-11.

7.2.2 Requirements: This document recognizes that different development models and historical practices apply. IT and OFI projects often take the form of spiral or incremental developments with a sustained level-of-effort throughout development. CoF and ECR projects, on the other hand, are usually waterfall developments following tried-and-tested construction practices. Therefore, separate requirements are identified below.

7.2.2.1 For CoF projects, the FPM shall comply with the requirements of NPR 8820.2, Facility Project Implementation Guide, rather than Section 3.2 of this document. For ECR projects, the EPM shall comply with the requirements of NPR 8590.1, Environmental Compliance and Restoration Program Implementation, rather than Section 3.2 of this document.

7.2.2.2 For IT and OFI projects, the Project Manager and the project team shall:

7.2.2.2.a Comply with the requirements of Section 3.2.

7.2.2.2.b Prepare a Project Plan containing the elements described in Appendix D with the following modifications:

  1. In Part 2, Resources, the Project Manager shall employ the appropriate WBS template for the overall structure of the project.
  2. Project IT investments shall be separately planned for, evaluated in terms of Return on Investment (ROI), budgeted, and managed.
  1. Planning shall cover the life cycle of the project and be sufficient to provide for data recovery, contingency facilities, and reconstitution of critical IT resources.
  2. The IT Project Manager shall conduct risk assessments in accordance with NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems, and prepare an IT Security Plan in accordance with NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems.

7.2.2.2.c The Project Manager shall comply with the requirements of NPR 7150.2, NASA Software Engineering Requirements, for software elements.

7.2.2.3 Because of the nature of institutional projects, the duration of the project may be substantially shorter than the life of the asset created. The Project Plan shall address the transition of responsibility for the asset to the receiving operations and sustainment organization.

7.3 Project Approval

7.3.1 For CoF projects, approval authority is outlined in NPD 7330.1, Approval Authorities for Facility Projects. The CoF approval process and project management requirements are found in NPD 8820.2, Design and Construction of Facilities, and NPR 8820.2, Facility Project Implementation Guide. These documents provide the framework and accepted best practices for planning and execution of facility projects.

7.3.2 NPR 8590.1, Environmental Compliance and Restoration Program Implementation, outlines the approval authority, approval process, and project management requirements for planning and execution of ECR projects.

7.3.3 For all other institutional projects, the Project Manager shall meet the requirements of paragraph 3.3.3. Institutional projects, like other projects, are subject to a NAR prior to implementation and an ICE, if warranted by project category. As a part of securing approval, all projects with IT elements shall be assessed against compliance with the current approved version of the NASA Enterprise Architecture (EA). This means that the CIO must have access to mission Program and Project Plans when they contain IT elements. Approval of such plans is provided by the OCIO through participation in the IC and GPMC structures.

7.4 Project Implementation

7.4.1 Because institutional projects may create assets which are transitioned to the user or application community, institutional project implementation requires especially close interaction between the project team and that community.

7.4.2 During CoF project implementation, the FPM shall comply with the requirements of NPR 8820.2, Facility Project Implementation Guide, rather than Section 3.4 of this document. During ECR project implementation, the EPM shall comply with the requirements of NPR 8590.1, Environmental Compliance and Restoration Program Implementation, rather than Section 3.4 of this document.

7.4.3 During IT and OFI project implementation, the Project Manager shall:

7.4.3.a Comply with the requirements of Section 3.4.

7.4.3.b Monitor changes to security plans and procedures to ensure that the project's security controls and implementation activities are well-matched to threat assessments related to physical and information security.

7.4.3.c Prepare user operational training and familiarization documentation to ensure a smooth transition-to-use, customer acceptance, and high utilization of the product or service under development.

7.4.3.d For IT investments, utilize NASA software assurance personnel and the requirements found in NASA-STD-8739.8, Software Assurance Standard, and when indicated or selected, use the NASA IV&V capabilities.

7.4.3.e Provide the MSOD a Project Status Report (PSR) in formats ready for reporting to the OCFO when required to do so, as defined in GAO Report B-237602, "Project Status Reports."45 The OCFO will validate the PSR and forward it, through the Office of Legislative Affairs, to the appropriate congressional committees.


45 A PSR is prepared for a project when it reaches the $200 million cost threshold for its total estimated research and development

7.5 Project Evaluation

7.5.1 Agency visibility into the progress of institutional projects will occur through independent project reviews, program reviews by the governing authority, and biennial (every two years) PIRs conducted by the IPAO. CoF projects are evaluated using the criteria outlined in NPR 8820.2, Facility Project Implementation Guide, and ECR projects in accordance with NPR 8590.1, Environmental Compliance and Restoration Program Implementation. To support evaluation, all other institutional Project Managers shall comply with the requirements of Section 3.5.3.

7.5.2 IT projects shall be assessed throughout their lifecycle to evaluate their effectiveness in supporting program/project objectives. Assessments shall be made against appropriate metrics and benchmarks to evaluate the cost and performance of IT investments.


This page intentionally left blank.



APPENDIX A. Formulation Authorization Document Template

A.1 Program FAD Title Page

Figure A-1 Program Formulation Authorization Document Title Page

A.2 Project FAD Title Page

Figure A-2 Project Formulation Authorization Document Title Page

A.3. Template

PROGRAM/PROJECT
FORMULATION AUTHORIZATION DOCUMENT
(PROGRAM/PROJECT TITLE)

1.0 Purpose

Identify the purpose of the program/project whose goals and objectives are referenced in the Mission Directorate Strategies or Mission Support Functional Leadership Plans or Program Plan (as applicable). This need is independent of any particular technological solution and is stated in terms of functional capabilities.

2.0 Authority

Describe the NASA organizational structure for managing the formulation process from the MDAA or MSOD to the NASA Center program/project managers, as applicable. Include lines of authority, coordination, and reporting.

3.0 Terms of Reference

Describe the level or scope of work, goals and objectives to be accomplished in the formulation phase, any cost targets or constraints, the time available, and any other constraints.

4.0 Internal Participants

Identify Mission Directorates, Mission Support Offices, and Centers to be involved in the activity, their scope of work, and any constraints related to their efforts (e.g., the program/project must be co-funded by a different Mission Directorate).

5.0 External Participants

Identify participation external to NASA to be involved in the activity, their scope of work, and any constraints related to their efforts (e.g., the program/project must be co-funded by the external participant).

6.0 Funding

Identify, by fiscal year, the funding that will be committed for formulation.

7.0 Reviews

Describe the reviews, including independent reviews according to Reviews Table in Appendix H, required during the formulation process.


APPENDIX B. Program Commitment Agreement Template

B.1 Title Page

Figure B-1 Program Commitment Agreement Title Page

B.2 Template

PROGRAM COMMITMENT AGREEMENT
(PROGRAM TITLE)

1.0 Program Objectives

Identify the broad program objectives. Describe the program's relationship to the Directorate Strategies or Mission Support Office Functional Leadership Plans including the commitment to safety. Convey the public good of the program to the taxpayer, stated in a way that can be understood by the average citizen.

2.0 Program Overview

Provide a broad description of the strategy to achieve the above-mentioned objectives. Relationships with external organizations, other agencies, or international partners should be addressed if achievement of the program objectives is dependent on their performance. Identify the associated projects governed by the program along with the appropriate product line for each project.

3.0 Program Authority

Describe the NASA organizational structure for managing the program and projects from the MDAA or MSOD to the NASA Center project managers. Include lines of authority and reporting, Center(s) responsibilities, the GPMC(s) for the oversight of the program and its projects, and the approving official for new projects.

4.0 Technical Performance Commitment

Summarize the Key Performance Parameters thresholds needed to achieve the program objectives. If the objectives include a technical performance target (goal) in addition to a threshold requirement (e.g., as for an applied technology research program), the commitment could be stated as a range.

5.0 Schedule Commitment

Identify the following key target milestones for each project in the program, such as:

  1. Start of Formulation;
  2. Target date or time frame for the Preliminary NAR and NAR;
  3. Start of Implementation;
  4. Start of operations;
  5. End of prime operations and/or disposal requirements, if applicable.
  6. Other milestones or time periods shall be added as appropriate for a specific program/project.

6.0 Cost Commitment

Provide the maximum cost for the program. This will incorporate programmatic constraints and can be demonstrated by including a table of all projects in Formulation and Implementation for the current year and nine-year horizon. The actual cost plan is developed during the annual POP process and shall reference the IBPD or equivalent for the budget year. The cost commitment shall include all full cost data necessary to perform the program, including, but not limited to, standard project activities, facilities costs, launch vehicles, tracking, sustaining operations, maintenance, data analysis, and disposal. For more information on full cost and practices, see Volume 7 of the NASA Financial Management Requirements.

7.0 Acquisition Strategy

Provide a brief statement of the proposed acquisition strategy for major elements.

8.0 High Risk Areas

Identify the areas of highest risk for the program (covering safety, technical, cost, or schedule issues) in which failure may result in serious consequences. This section should identify, where possible, the specific risk drivers, such as high-risk technologies upon which the program is dependent.

9.0 Internal Agreements

If the program is dependent on other NASA activities outside of the MDAA or MSOD's control, identify the required support and list any formal agreements required.

10.0 External Agreements

Explain the involvement of external organizations, other agencies, or international partners including a brief overview of the external support necessary to meet the program objectives. Include an identification of the commitments being made by the external organizations, other agencies, or international partners and a listing of the specific agreements to be concluded. Any unique considerations affecting implementation of required NASA policies and processes necessitated by the external involvement should be clearly identified.

11.0 Independent Review

Specify the type of independent reviews, (e.g., Preliminary NAR, NAR) that will be performed during the life cycle of the program/project.

12.0 Outcomes

Identify the discrete set of expected deliverables (outcomes) that flow from the Agency goals and objectives as defined in the Agency strategic roadmaps and architecture.

13.0 Waivers

Identify those waivers that will be sought for the program. Provide rationale consistent with program characteristics such as scope, complexity, visibility, cost, safety, and acceptable risk.

14.0 PCA Activities Log

Provide and maintain a log of all PCA activities, depicting revisions that reflect all deviations to the original PCA. This log includes the information shown in Figure B-2 and may be supplemented with an attached addendum for each change, describing the change. The PCA should be updated to add approved projects or whenever substantial change makes it necessary.

Cancellation MDAA or MSOD Deputy Administrator
Date Event Change Addendum Review Req'd Signature Signature
dd/mm/yy Revalidation None N/A No
dd/mm/yy Revalidation None N/A No
dd/mm/yy Approval of new project Addition of Project N Ref. #1 No

Figure B-2 Sample Program Commitment Agreement Activities Log


APPENDIX C. Program Plan Template

C.1 Title Page

Figure C-1 Program Plan Title Page

C.2 Template

PROGRAM PLAN
(PROGRAM TITLE)

1.0 Part I: Program Overview

1.1 Introduction

Briefly state the background of the program and its current status, including the results of formulation activities, decisions, and documentation.

1.2 Program Goals, Objectives And Metrics

State program goals and specific objectives with clear traceability to the Agency Vision, Mission, and strategic goals. Performance goals, and performance indicators, and their relationship to NASA program goals and objectives set forth in NPD 1000.1, NASA Strategic Plan, should be expressed in an objective, quantifiable, and measurable form. Goals and objectives should include commitment to safety and mission success.

1.3 Customer And Stakeholder Definition And Advocacy

State the main customers and stakeholders of the program (e.g., PI, science community, technology community, public, education community, Mission Directorate, Mission Support Office, OCE, OSMA, CIO, NASA Centers) and the process to be used to ensure customer and stakeholder advocacy.

1.4 Program Authority And Management Structure

Identify the location (Center or Headquarters) where the Program Manager resides and each Center's responsibilities, the Governing Program Management Committee or Council(s) for oversight of the projects within the program, and the approving official for projects.

Briefly describe the architecture of the program, its major components, and the way they will be integrated. Describe how the major components are intended to operate together, and with legacy systems. Describe the way the program will relate to other institutions within NASA as well as outside of NASA. Identify the responsibilities of each NASA Center as they relate to their respective requirement allocations referenced in PROGRAM REQUIREMENTS below. Describe the process by which projects are formulated, approved or terminated.

  1. Organization. Describe the NASA organizational structure for managing the program and projects from the Mission Directorate or Mission Support Office to the NASA Center Project Managers. Include lines of authority and reporting; illustrate the organization graphically.
  2. Responsibilities. Define management responsibilities of the Mission Directorate or Mission Support Office, the Program Manager, and Project Manager, including the authority of these persons as described in NPD 7120.4, Program/Project Management. Indicate their responsibilities for developing, concurring, and approving principal program documents, such as the formulation authorization, the Program Plan, Project Plan, RFPs and other contract-related documents, reports associated with major reviews, and other key activities.

2.0 Part Ii: Program Baseline

2.1 Program Requirements

Document the program requirements, including performance and safety requirements, and technical success criteria, in an objective, quantifiable and measurable form. For multiple projects within a program, describe the way in which the program requirements will be allocated to the respective projects. The approving authority is required to document objectives and high-level requirements and how these requirements flow down from the program requirements for each project as they are formulated. Traceability of requirements and flow-down from/to projects should be demonstrated. If the mission characteristics indicate a greater emphasis is necessary on maintaining either technical, cost, or schedule, then this section should also identify which is more important to be considered, (e.g., it should address if the mission is cost capped, or if schedule is paramount, as for a planetary mission, or if it is critical to accomplish all of the technical objectives.) Programmatic success criteria such as Key Performance Parameters (KPPs), outcomes, and other accompanying performance indicators should be expressed in objective, quantifiable, and measurable form. Include project KPP thresholds and KPP goals, where applicable.

2.2 Program Schedule

Provide a schedule of program activities and events covering the life of the program; include all applicable events, such as approval dates for major program and project documents, instrument selection dates, dates of major project reviews, launch dates (or equivalent system "delivery" dates), and other Deputy Administrator, Mission Directorate, or Mission Support Office decisions. Include all PCA milestones. Include the strategy for addressing schedule updates when impacts to the schedule occur.

2.3 Program Resources

All elements in full cost are to be included for each participating NASA Center, identify yearly New Obligational Authority (NOA) full cost estimates for system development and operations, facility construction, institutional support (including safety and mission assurance), and management. Address Civil Service workforce levels. Once program approval has been completed, this section will be a reference for reconciliation to IBPD and IFM data.

3.0 Part Iii: Subplans

3.1 Controls And Compliance

Describe the process by which the program assures compliance with NASA policies, directives, as well as other applicable requirements. Describe the process by which project requirements are validated for compliance with the program requirements. Describe the process for controlling changes. Describe the process for updating the PCA as a result of any changes. Indicate key program parameters (cost, schedule, and technical) which will require Deputy Administrator, Mission Directorate, Mission Support Office, or Program Manager approval for change. Identify the reserves management strategy and approval authority to include identification of an Allowance for Program Adjustment (APA). Describe the strategy for supporting and/or implementing independent assessments.

3.2 Relationships To Other Programs And Agreements

3.2.1 Internal: Describe the way the program will relate to other institutions within NASA (e.g., crosscutting technology efforts, space communications and launch services). List the internal agreements necessary for program success and projected dates of approval. This list should include those agreements that are concluded with the authority of the Program Manager, and reference those agreements concluded with the authority of the Mission Directorate or Mission Support Offices.

3.2.2 External: Describe the way the program will relate to entities outside of NASA (e.g., interagency or international). List the external agreements necessary for program success and projected dates of approval. This list should include those agreements that are concluded with the authority of the Program Manager, and reference those agreements concluded with the authority of the Mission Directorate, Mission Support Office, and/or Deputy Administrator.

3.3 Budget And Acquisition Strategy

Briefly describe the budget and acquisition approach to be applied at the program level toward each project. The respective roles, responsibilities, and relationships between the Government and its contractors, vendors, and/or partners are addressed, including a description of integration and surveillance responsibilities. The use of cost caps or other cost control strategies should be addressed as well as the strategy for initiation of new program elements.

3.4 Technology Strategy

Identify the NASA crosscutting or other technology thrusts to be utilized by the projects. Identify those technologies the program expects to mature during the life of the program. Briefly describe how the technologies will be developed and infused. Describe how and when the program will evaluate the feasibility, readiness, cost, risk, and benefits of the new technologies. Also provide alternative development strategies for technologies that do not mature as expected.

3.5 Cooperation And Commercialization

Identify opportunities for establishing partnerships with private industry, academia, or other governmental organizations to conduct dual use research, develop mutually beneficial technologies, and transfer results into NASA for mission use and the private sector for commercial application.

3.6 Data Management And Distribution

Program data management planning is provided as either a section of this Program Plan or as a separate document. Address the data being captured by all projects within the program and its availability. It contains plans for data rights and services addressing issues which are community-wide and often require tradeoffs between project and Center interests and various communities.

3.7 Safety And Mission Assurance

Safety and mission assurance planning is provided either as a section of this Program Plan or as a separate document. Address the activities and steps to be taken to ensure safety of the public, the NASA astronauts and pilots, the NASA workforce, and NASA's high value equipment and property. Address both hardware and software aspects of the program, and identify all activities such as safety, reliability and maintainability, quality assurance, software assurance (including IV&V), environmental related design and test including orbital debris mitigation, program surveillance, failure detection, isolation, and recovery, and failure reporting/resolution, and hazard analysis and mitigation, which are used to ensure the success and safety of the mission.

3.8 Risk Management Strategy

Summarize the risk management approach to be used for the program, including appropriate actions to mitigate risk and program de-scope plans. Also identify primary risks. A stand-alone Risk Management Plan will also be developed that includes the content shown in NPG 8000.4, Risk Management Procedures and Guidelines.

3.9 Environmental Impact

Identify the documentation and schedule of events associated with environmental compliance considerations (NEPA and other requirements). This may include an Environmental Assessment and/or an Environmental Impact Statement.

3.10 Institutional And Logistics

Describe the institutional facilities and equipment that currently exist, or

must be completed to successfully meet program goals and objectives. This section should outline methods for meeting the logistics and re-supply aspects (if applicable) of the program.

3.11 Physical And Information Technology Security

Describe the approach to ensuring that the team members, hardware and software are secure from intentional and/or unintentional breaches do not occur.

3.12 Verification And Validation

Describe the program's approach to verification and validation for the assurance of program success. Address requirements for hardware and software verification and validation as well as software independent verification and validation.

3.13 Reviews

List the reviews that the program will conduct, including independent assessments, in response to MDAA (or MSOD) and GPMC requirements. Include the timeline for these reviews.

3.14 Education And Public Outreach Plan

Describe planned efforts and activities to improve science literacy by engaging the public in understanding the project, its objectives, and benefits. Summarize plans to stimulate interest in science, engineering, and technology through mission-related outreach activities.

3.15 Termination Review Criteria

Provide the technical, scientific, schedule, cost, and other criteria, which will be utilized to consider whether a termination review for the program should be conducted.

3.16 Deviations And Waivers

Identify known deviations and waivers that the program will obtain against NASA policies, directives or other applicable external requirements. Provide rationale and risk impact for the waiver or deviation, include characteristics such as scope, complexity, visibility, cost, and safety. This list should include the variances requiring Independent Technical Authority approval.

3.17 Change Log

Document changes to the Program Plan.

3.18 Appendices

NPR 7120.5 Compliance Matrix


APPENDIX D. Project Plan Template

D.1 Instructions

The Project Plan is an agreement between the Center Director (if applicable), Program Manager, and Project Manager. It defines, at a high level, the scope of the project, the implementation approach, the environment within which the project operates and the commitments of the program and project. The Project Plan is used by the Governing Program Management Committee (GPMC) in the review process to determine if the project is fulfilling its agreement. The Project Plan shall be consistent with the Program Plan. The Project Plan is updated and approved during the project life cycle if warranted by changes in the stated commitments or Level-1 requirements.

This template Project Plan is for all projects and all sections should be included. If a section is not applicable to a particular project, indicate by an "NA" and provide rationale.

A preliminary Project Plan is due at the preliminary NAR or System Requirements Review at the end of Phase A. An updated version is due at the NAR or Preliminary Design Review per Appendix G, and the final is due by the approval gate.

The planning efforts called out in this document designated as a "plan" are not necessarily intended to be a separate plan; (however, is not precluded). These requirements may be addressed in this document, or as part of another document with a summary of the approach in this document. A planning effort called out as a "Plan" is a stand-alone document and should be included in the Project Plan as a summary with reference to the control document number and title of the document. Note that the plans included in this section are not an all inclusive set of Plans required for a given project.

The required signatures are the Center Director (if applicable), Program Manager, and the Project Manager. Other signatures may be added if applicable.

D.2 Title Page

Figure D-1 Project Plan Title Page

D.3 Template

PROJECT PLAN [PROJECT NAME]

1.0 Part I: Project Overview

1.1 Introduction

The project is identified by a NASA program, PCA, and/or unique Work Breakdown Structure (WBS) number and has an official title. Provide a reference to the governing Program Plan.

Provide a brief general history and summary to include the project's purpose, goals, overall approach, and timeframe. Identify previously conducted projects, studies, proposals, concept study reports, experiments, related activities or any other information appropriate to providing a perspective on the project.

Describe participation, if any, of other NASA Centers as well as other government agencies, and industry or international partners. Provide key project dates, such as launch, arrival or other event, and end of mission. Refer to the section of the Plan containing the Project schedule.

Briefly describe the process for change control of the Project Plan. Include the approval authority for changes to the Plan.

1.2 Objectives

State the specific project objectives, performance goals, and their relationship to the program objectives and goals. Performance goals should be stated in an objective, quantifiable, and measurable form. Include technology objectives and related performance goals, if applicable, also stated in objective, quantifiable, and measurable form.

Include project-specific high-level requirements.

State the full mission success criteria clearly and concisely in a form suitable for objective verification and validation. State the minimum mission success criteria associated with the high-level project requirements that, if not met, trigger a possible Termination Review.

1.3 Mission Description

Provide a brief overview of the mission, indicating important characteristics of the mission, such as mission trajectory and a brief description of the phases and events on the mission timeline. Drawings, figures, charts, etc., may be used for clarification.

Identify major constraints affecting system development (e.g., cost, launch window, required launch vehicle, mission planetary environment, fuel/engine design, foreign partners, etc.)

1.4 Customer And Stakeholder Definition And Advocacy

State the customers and stakeholders of the project (e.g., PI, science community, technology community, public, education community, Program and Mission Directorate sponsor) and the process to be used to ensure customer advocacy.

1.5 Project Authority

Identify the Center where the Project Manager resides and other Center's responsibilities, and the GPMC responsible for the oversight of the project. Provide a chain of accountability and decision path that outlines the roles and responsibilities of the Project Manager, Program Manager, Center Director, and other authorities as required.

1.6 Management

Describe the project management structure consistent with the project WBS, including organization and responsibilities, its integration into the program management structure, and NASA Center participation. Include clear lines of authority and reporting; illustrate the organization graphically. Identify all significant interfaces with other contributing organizations. Describe the process for problem reporting and subsequent decision making, clearly describing the roles and responsibilities of all organizations. Identify specific management tools to support management in planning and controlling the project. Describe any use of special boards and committees. Address any requirement for a NASA Resident Office including duties and authority.

1.7 Governance Structure

Describe the governance structure based on the project category (see Section

1.5.4). Describe the process that the Project will follow to communicate to the GPMC, Mission Directorate, Mission Support Office, and Program Manager. Include clear lines of authority and reporting, including frequency of reporting.

1.8 Project Requirements

Document the project requirements. Identify KPPs and success criteria, as a flow down from the program requirements. This includes the allocation of these requirements and success criteria among the systems to be developed, both hardware and software. Describe the process by which project requirements are validated for compliance with program requirements. Describe the process for controlling changes to these requirements.

1.9 Technical Summary

Present a technical description of the project. This includes the systems to be developed (hardware and software), facilities, flight plans, operations and logistics concepts, and planned mission results analysis and reporting.

  1. System(s)
  2. System operations concept
  3. System constraints
  4. Ground systems and support
  5. Facilities
  6. Mission results analysis and reporting
  7. End of life cycle

1.10 Implementation Approach

The implementation approach of the project should be included (e.g., in-house, NASA Center, contractor prime), as well as a project WBS and a WBS dictionary. Make-or-buy plans and trade studies should also be included.

  1. Implementation approach
  2. Project summary WBS

1.11 Program/Project Dependencies

Other NASA, U.S. agency, and international activities, studies, and agreements are summarized with emphasis on their effect on the program.

a. Related activities and studies, e.g., space communications, launch services, crosscutting technology b. Related non-NASA activities and studies

1.12 Logistics

Describe the project's logistics requirements, for example, spares provisioning, shipping and handling equipment, transportation, user manuals, simulators, training and training materials, and supporting personnel.

2.0 Part II: Project Baseline

2.1 Schedules

Document the project's Integrated Master Schedule for all major events, independent reviews, and other activities throughout the life cycle of the project. Include approval dates for principal project documentation, lifecycle transitions, major reviews, program-controlled milestones, and significant contract milestones. Identify lower level schedules to be developed and maintained.

For ATD, Project Managers are encouraged to identify alternative development paths in order to maximize the probability of success.

2.2 Resources

  1. Funding Requirements: Document the initial LCCE consistent with the project WBS, schedule, and performance parameters to form the project estimate baseline. Present a funding requirements chart that includes the same elements as for the acquisition summary. Indicate the NOA in full cost real-year dollars for the prior, current, and remaining fiscal years. The displayed detail should cover major elements of cost (typically reflecting at least at the second level of the WBS or its equivalent). (For more information on full cost and practices, see Volume 7 of the NASA Financial Management Requirements.)
  2. Institutional Requirements: Present the infrastructure requirements (use or development of real property/facilities, aircraft, personal property, information technology) for the entire project throughout its life cycle. The business case includes full life cycle cost (LCC) (including operations, sustainment and disposal); benefit estimates; alternative and sensitivity analyses; and risk assessment. Present the workforce requirements. Include full cost civil service workforce requirements on the providing organizations for the prior (e.g., actuals), current, and remaining years.
  3. Facility Requirements: Identify means of meeting infrastructure requirements through synergy with other programs and projects, thus avoiding costly duplication of support facilities and capabilities. Identify any necessary upgrades or new developments, including those needed for environmental compliance.

2.3 Acquisition Management

Document the integrated acquisition strategy that allows the project to meet its mission objectives. Provide summary information on the Acquisition Plan, including procurement items (such as engineering design study, hardware and software development, mission and data operations support); type of procurement (competitive, AO for instruments); type of contract (cost-reimbursable, fixed-price); source (institutional, contractor, other Government organizations); procuring activity; and surveillance.

For ATD, only Category I and Category II projects are required to complete this section.

2.4 Performance

Describe the project specific KPPs and establish quantitative values (goal and threshold values) for each to be achieved at each milestone. The relationship may be in the form of a matrix that show the KPP range (threshold and goal) and the TRL to be achieved at each major demonstration.

3.0 Part III: Subplans

3.1 Communications Plan

Describe the communications plan for fostering effective (upward and downward) communication of critical management, technical, risk and safety information. Define the relationships among various project elements within the project structure and clearly state the responsibilities for problem reporting and subsequent decision making. Define the relationships and interactions with all stakeholders, team members, and supporting organizations.

3.2 Control Plan

All technical performance, risk, cost, or schedule parameters specified as requiring approval by the Administrator, the MDAA, Center Director, or Program Manager, should be identified. Describe the project EVM implementation strategy. Examples include funding by year, threshold KPPs, success criteria, program requirements, project objectives, requirement deviation or waivers, management structure, and major program/project documentation. Identify the thresholds associated with each parameter that could cause a change request. Describe the configuration management approach that the project team will implement. Reference the project Configuration Management Plan if applicable.

3.3 Risk Management Plan

Summarize the risk management approach to be used for the project, including appropriate actions to mitigate risk and project plans. Also identify primary risks. A stand-alone Risk Management Plan should be developed that includes the content shown in NPR 8000.4, Risk Management Procedures and Requirements.

3.4 Technology Strategy Or Insertion

3.4.1 Strategy: Identify the NASA crosscutting or other technology thrusts to be utilized by the project as well as the sources of the technologies. Describe how the project will remove remaining technology gaps, including maturation, validation, and insertion plans, quantifiable milestones, decision gates, and resources required. Describe how and when the project will evaluate the feasibility, readiness, cost, risk, and benefits of the new technologies. Also provide alternative development strategies for technologies that do not mature as expected. Identify distribution restrictions on the software, hardware, or data.

3.4.2 Insertion: For ATD, describe how the technology end item deliverable (product or service) will transition to application or user adoption (i.e., a technology transfer strategy). Demonstrate close interaction with the application community, and provide an exit strategy following technology transfer.

3.5 Cooperation And Commercialization

Describe all agreements, memoranda of understanding, barters, in-kind contributions, and other arrangements for collaborative and/or cooperative relationships. List all such agreements (the configuration control numbers and the date signed or projected dates of approval) necessary for project success. Include all agreements concluded with the authority of the Project Manager and reference agreements concluded with the authority of the Program Manager and above.

  1. NASA agreements, e.g., space communications, launch services
  2. Non-NASA agreements:
  1. Domestic
  2. International

Identify opportunities for establishing partnerships with private industry, academia, or other governmental organizations to conduct dual use research, develop mutually beneficial technologies, and transfer results into NASA for mission use and the private sector for commercial application.

3.6 Safety And Mission Success Plan

Safety and mission success planning should be included either as a section of this Project Plan or as a separate document. Address the activities and steps to be taken to ensure safety of the public, the NASA astronauts and pilots, the NASA workforce, and NASA's high-value equipment and property.

Address both hardware and software aspects of the project, and identify all activities, such as safety, reliability and maintainability, quality assurance, environmental related design and test including orbital debris mitigation, project surveillance, failure detection, isolation, and recovery, failure reporting/resolution, and hazard analysis and hazard mitigation which are used to ensure the success and safety of the mission.

3.7 Environmental Management Plan

Identify the documentation and schedule of events associated with environmental compliance considerations (NEPA and other requirements). This includes a preliminary Environmental Evaluation and Record of Environmental Consideration (REC) signed by the Center NEPA Document Manager) which may lead to an EA and/or an Environmental Impact Statement. Refer to section 3.2.1.2 k, Complete the Environmental Management Plan.

3.8 Systems Engineering Plan

Describe the systems engineering scope and approach to be implemented on the project. Identify the technical standards that are applicable to the project and any intended.

3.9 Verification And Validation

Describe the project's approach to verification and validation for the assurance of project success. This should address requirements for hardware and software verification and validation, as well as software IV&V.

3.10 Reviews

Summarize the approach to a continuum of reviews for the Project life cycle. Provide the names, purposes, content, and timing of the critical milestone reviews. Describe the process for selecting the IA team and the communication requirements of the results. Explain the reporting requirements for program and project reviews. Reference the Project Review Plan, as appropriate.

3.11 Configuration Management Plan

Describe the structure of the CM organization and tools to be used. Identify the methods and procedures to be used for configuration identification, configuration control, interface management, configuration traceability, and configuration status accounting and communications. Describe how CM will be audited and how contractor CM processes will be integrated with the project.

3.12 Education And Public Outreach Plan

Describe planned efforts and activities to improve science literacy by engaging the public in understanding the project, its objectives, and benefits. Summarize plans to stimulate interest in science, engineering, and technology through mission-related outreach activities.

3.13 Termination Review Criteria

Provide the technical, scientific, schedule, cost, and other criteria, which will be utilized in the consideration of a termination review.

3.14 Knowledge Capture

Summarize the approach to knowledge capture on the project as well as the methods for contributing knowledge to other entities and systems. This includes the development and maintenance of an electronic project library.

3.15 Waivers/Deviations Log

Identify those requirements for which a waiver or deviation has been requested and approved consistent with project characteristics such as scope, complexity, visibility, cost, safety, and acceptable risk and provide rationale and approvals. Identify those variances requiring Independent Technical Authority approval.

3.16 Change Log

Document changes to the Project Plan.

3.17 Appendices

NPR 7120.5 Compliance Matrix
CADRe (Category I and II Flight and Ground Support Projects)

A

APPENDIX E. CADRe Data Requirement Description


USE: The Cost Analysis Data Requirement (CADRe) documents the programmatic, technical, and life cycle cost information for Category I and Category II Flight Systems and Ground Support Projects. It is the NASA version of the Department of Defense Cost Analysis Requirements Document (CARD). NASA's CADRe combines and streamlines the contents of formerly separate DRDs - the CARD and the Life Cycle Cost Estimate (LCCE). The CADRe is for both internal project use and for independent cost estimating. CADRe is part of an overall Agency focus on performing best practices in cost estimating called Continuous Cost Risk Management (CCRM).

Typical projects will make five CADRe submissions across the project life cycle (see Submissions below). The NASA Project Manager is responsible for the CADRe. The Project Manager may develop the CADRe within the Project Office or use the CADRe as a DRD on contract(s). Because the CADRe collects Full Cost information, it is likely that the project will have to perform final integration of a contractor prepared CADRe to include all Full Cost information.

OTHER DRD INTERRELATIONSHIP: Work Breakdown Structure; Earned Value Management Report; Integrated Master Schedule; Risk Management Plan & Reports; Phase Implementation Plans; PRA Plans and Reports, 533 Reports.

REFERENCES: NASA Cost Estimating Handbook (http://www.ceh.nasa.gov); DoD 5000.4M (CARD); DI-MGMT-81466, CPR DID; DD Forms 2734/1-5 (CPR Formats) (http://www.dior.whs.mil)

Figure E-1. Flight Systems and Ground Support Projects
CADRe Submissions Timeline

FIRST SUBMISSION: The initial CADRe submission shall occur 90 days prior to the Preliminary Non-Advocate Review (Preliminary NAR) as referenced in Figure E-1. For AO (Announcement of Opportunity)-driven projects, in lieu of this initial CADRe, copies of the selected winning proposal and Concept Study Report may be submitted at the end of Step 2 down selection.

SUBSEQUENT SUBMISSIONS: The CADRe shall be submitted 90 days prior to the following events: Non-Advocate Review (NAR), Critical Design Review, and Production Reviews (for projects using an evolutionary acquisition approach). The CADRe shall also be submitted 180 days after launch, and one final CADRe at the end of the planned project lifecycle (Phase E/F).

DOCUMENT FORMATS: The use of Microsoft Office™ products (Word, Excel, PowerPoint, and Project) is preferred. At www.ceh.gov, there are three downloadable Microsoft Excel CADRe Report formats (the Hardware Metrics Report, the Software Metrics Report and the WBS Cost Report). However, project formats are acceptable. Most, if not all, CADRe information can be extracted from other project documents and included in the CADRe. Projects are encouraged to provide other supporting and supplemental documentation46 to the CADRe as these documents are helpful in understanding project cost.


46 Examples include: Project Plan, Systems Engineering Plan, Work Breakdown Structure and Dictionary, Integrated Master Schedule, requirements documents, parts program, and major review documentation/briefings

DELIVERY METHODS: The CADRe and supporting documents may be delivered on CDs or otherwise made electronically accessible, for example, from a web page.

DISTRIBUTION: As a minimum, the CADRe and supporting documents shall be delivered to the Headquarters Office of the Chief Engineer (IPAO/Cost Division) and the Headquarters Office of the Chief Financial Officer (Cost Analysis Division). Further distribution is at the discretion of the project.

PREPARATION INSTRUCTIONS: The guidance contained in this document describes the contents of the CADRe. It is a guide for content rather than format. Projects are encouraged to extract existing project documentation for appropriate sections of the CADRe. These extracts shall be included in the CADRe and/or in the attached CADRE Hardware Metrics Report, Software Metrics Report and WBS Cost Report in order to provide a complete, stand-alone CADRe document.

The body of the CADRe consists of three parts. Part A contains general descriptive information. Part B contains hardware and software technical parameters necessary to estimate the project's life cycle cost. The Hardware Metrics Report and Software Metrics Report formats at http://www.ceh.gov are available to use directly or as a content guide for Part B. Part C contains the project's life cycle cost estimate (LCCE). The WBS Cost Report available at http://www.ceh.gov is available to use directly or as a content guide for Part C. The Project Manager is responsible for collecting the inputs from the various participants including Full Cost elements and submitting an integrated CADRe.

The level of detail reported in the CADRe will depend on the maturity of the project in the life cycle. The Hardware Metrics Report, the Software Metrics Report and the WBS Cost Report provide a template of information that would typically be provided at the NAR (for example, at WBS Level 4). These Reports may be tailored to provide less detail for projects earlier in the life cycle (for example, WBS Level 3 at Preliminary NAR). The project shall submit lower-level information in subsequent CADRe submissions when and if such information becomes readily available (for example, WBS Level 5 at CDR). Prior to CADRe submittals, representatives of the Headquarters Cost Analysis Division, the applicable Mission Directorate, and Program Office, will meet with the Project Manager to provide guidance on the scope, schedule, parties involved in CADRe preparation, CADRe tailoring, WBS reporting levels and WBS mapping.

The Freedom of Information Act (FOIA) law defines . confidential business information as data that provides visibility into elements of cost (labor rates, overhead rates, G&A rates, profit rates and similar rates and factors). The CADRe reports costs rolled into the project WBS without visibility into elements of cost/rates and factors. Likewise, the CADRe does not collect proprietary technical information such as insight into production processes, etc. Rather, the CADRe only collects performance specifications as technical cost drivers. Therefore, NASA intends that no proprietary, confidential or sensitive business information be included in the CADRe and that CADRe submissions need not be marked as "proprietary", "sensitive" or display other confidential business information markings.

The subsequent paragraphs describe the information that shall be contained in each part of the CADRe.

Part A - General Descriptive Information (in narrative form supplemented by tables, figures and graphics as appropriate)
  • Description - Provide a top-level description of the system, including functions to be performed, measurements to be obtained and key performance parameters. A functional block diagram and/or photograph or drawing of the system (with major elements identified) shall be provided. For CADRe purposes, document the baseline project description that is being used as the basis for budget forecasts (i.e. excluding other options that might still be in the trade space at any given point in the project evolution).
  • Mission/Objective - Describe the overall mission(s) of the system, including interfaces and functional relationships to other systems. Include a description of the concept of operations (CONOPS) for the system.
  • Configuration - Provide complete WBS and WBS Dictionary at the appropriate level of detail. The required NASA Standard WBS through Level 2 for flight systems and ground support projects is shown below. The NASA Cost Estimating Handbook contains a WBS template for flight systems and ground support projects down to Level 4 to assist projects in forming the WBS. If a project is not able to conform to the NASA Standard WBS and/or the CADRe Level 4 WBS, a mapping shall be provided that maps the project WBS at Level 4 and above to the NASA Standard/CADRe WBS. It is recognized that it may occasionally be necessary to carry an element at a higher level in the project WBS than it will appear in the CADRe WBS (for example, a foreign-contributed instrument may need to appear at WBS Level 2 in the project for political purposes but can be mapped to Level 3 in the CADRe WBS).

Table 1 - NASA Standard Level 2 WBS for Flight Systems
and Ground Support Projects

Program Management
Systems Engineering
Safety and Mission Assurance
Science/Technology
Payload
Aircraft/Spacecraft
Mission Operations
Launch Vehicle/Services
Ground Systems Development
System Integration Assembly & Test
Education & Public Outreach

  • Project Management and Systems Engineering - Describe the responsibilities and functions of the project office. Include current and anticipated funding levels (by Government Fiscal Year) for all project elements and funding lines/sources.
  • Acquisition Plan - Describe the contract type(s), acquisition strategy and schedule for system development, procurement and implementation. Provide an Integrated Master Schedule (IMS) that includes major milestone dates for SRR (System Requirements Review), PDR (Preliminary Design Review), CDR (Critical Design Review), LRR (Launch Readiness Review), etc. Lower-level schedules should be included when known. Describe contract type(s), fee structure(s) and any unusual acquisition strategies assumed or corporate investments. If known, identify contractors and major subcontractors (or NASA in-house organizations) and their products at a summary WBS level. Identify any government or foreign partners and the hardware and/or software elements that will be furnished by the partners. For items such as joint-use of facilities, availability and schedule constraints should be identified along with any cost-sharing provisions.
  • Heritage - In Part A, provide at a summary level, any heritage or analogous systems that are being used to reduce development/production costs. Describe any ECP/ECO (Engineering Change Proposal/Engineering Change Order) activity that modified original system performance requirements from the previous CADRe submission (in order to understand requirements creep/evolution). Lower-level WBS heritage is documented in Part B on the Hardware Metrics Report and Software Metrics Report.
  • Test Plan - If available within the current phase of the program, describe all testing to be conducted by the developing organization(s) and/or other agencies to include equipment, subsystem and system-level testing. Testing includes assessment of functionality, reliability, utility, operational effectiveness, supportability, etc.
  • Project Risks - Identify programmatic and technological aspects of the project that present potential or demonstrable risks to the schedule and/or budget of the project and their effects on specific WBS elements. Include an identification of cost-correlated WBS elements. Describe risk mitigation philosophy and processes. As the project proceeds through its life cycle, this information should be updated to document the interim results of risk mitigation and to include any risks identified since the last CADRe submission.
  • Track to Prior Release - Summarize changes made since submission of the previous CADRe. If no changes occurred since the last submission, the Project Manager is not required to resubmit, but to notify the Distribution list provided earlier. The CADRe will document evolution in the project, specifically addressing changes in cost drivers and cost.

Part B - Technical Data

The project shall provide hardware and software metrics data that will permit an independent team to estimate project cost. To report Part B Technical Data, use the latest CADRe Hardware and Software Metrics Reports directly or as a content guide (available at http://www.ceh.gov). The CADRe Hardware and Software Metrics Reports document the cost driver metrics that the NASA cost estimating community uses to estimate project cost and to develop future cost models. The Project Manager shall coordinate with the Headquarters Cost Analysis Division regarding significant departures from providing the majority content of these reports.

Part C - Life Cycle Cost Estimate

This part of the CADRe contains the LCCE.

Life Cycle Cost Estimate Documentation

The CADRe WBS Cost Report can be used directly to report Part C life cycle costs or be used as a content guide. The LCCE consists of design, development, test and evaluation (DDT&E) and production through the end of operations and disposal. The LCCE in this section is the Project Manager's estimate. It should be consistent with the basis of estimate contained in Parts A and B of the CADRe (which may be used by independent cost estimating organizations within NASA).

NPR 7120.5C requires projects to take cost risk into account when performing cost estimates. The costs reported in Part C shall be risk-adjusted costs consistent with the Continuous Cost Risk Management (CCRM) process as described in the NASA Cost Estimating Handbook. The LCCE documentation shall identify where cost reserves are included in the WBS accounting.

The LCCE documentation shall also include:

  1. a. Sufficient information to allow an independent estimator/analyst to understand how the estimate was constructed, understand the impacts of key assumptions and inputs, and determine a level of confidence in successfully completing the system(s) within the estimated cost.
  2. b. LCCE team memberships, including basic functional organizational memberships and names of cost experts.
  3. c. LCCE methodologies and models used, by phase of project: System design cost analysis methodology and parametric or other cost models, analogy, or "grass roots/WBS-based"(or combinations). Provide information on cost and economic models (especially, information concerning model validation, history of successful use, configuration version), backup and supporting data, ground rules and assumptions.
  4. d. The WBS Cost Report format provides for a separation of non-recurring and recurring cost assumptions. The NASA Cost Estimating Handbook provides guidance on defining non-recurring and recurring costs. However, if a project believes it cannot reasonably separate non-recurring and recurring cost, total cost may be reported without such a separation.
  5. e. A WBS display of total cost in tabular form to the agreed upon WBS Level for the phase of the project (for example, WBS Level 3 at the Preliminary NAR and WBS Level 4 or 5 at the NAR). A fiscal year time-phased display of life cycle cost shall be provided at least to WBS Level 2. At any given milestone (Preliminary NAR, NAR, etc.), past years' costs are "actuals", while future years' costs are estimates. Obviously, the final CADRe at the end of Phase E/F contains all actual costs. See the WBS and Cost Report at http://www.ceh.gov to use directly or for sample content.
  6. f. Narrative identification and explanation for cost growth occurring since the last CADRe submission stemming from all technical, programmatic, and project configuration sources delineated in accordance with the following two general categories:
  • Risk-Driven cost and schedule growth is cost and schedule growth, overruns or funded changes, linked to technical risk drivers (e.g., technology maturity, design/engineering, complexity, integration, etc.) and key engineering performance parameters.
  • Externally-Driven cost and schedule growth is cost and schedule growth, overruns or funded changes, linked to external factors (e.g., requirements changes, technical enhancements not driven by risk, perturbations to budgets by external agents causing schedule changes, labor strikes, business base changes, etc.).

(NOTE: Sources for both categories of this cost and schedule growth can be specifically identified in the Earned Value Management Cost/Schedule Performance Report variance analysis reporting - Cost Performance Report Format 5).


APPENDIX F. Technology Readiness Levels



APPENDIX G. Program and Project Products Maturity Matrix


G.1 Program Products

G.2 Project Products (Flight Systems and Ground Support Projects only)






Appendix H. Reviews

This Appendix provides information to guide compliance with requirements for Independent and Project Milestone Reviews.

Guiding Principles of Reviews:

  • Reviews are a resource. They offer an opportunity to add value to the products and to the sharing of knowledge by inviting outside experts that can provide confirmation of the approach and/or recommend options.
  • Reviews are a tool for communication. They offer an opportunity to organize, assess, and communicate critical data and information between providers, customers, and stakeholders.

H.1 Independent Reviews

This section provides information to guide compliance with the requirements for independent reviews and assessments contained in Section 2.5 for programs, in Section 3.5 for common projects and in Section 6.5 for flight projects. For applicability of these reviews to the various Product Lines, refer to Table 2-1 Program Decision Reviews.

H.1.1 Major Reviews

The objectives and salient features of the eight major independent review types are provided to guide program/project managers in the formulation and implementation of programs and projects. Reviews provide the opportunity to confirm the approach or offer options, if needed, and communicate progress and risks toward meeting the success criteria. These reviews also evaluate and communicate the level of safety and likelihood of mission success.

Reviews also serve the needs of the various levels of the management hierarchy from an individual product lead on a project to the NASA Administrator. The output of these reviews (i.e., assessments, options, findings, recommendations, and decisions) flows as inputs into subsequent reviews as appropriate to ensure alignment between providers, customers, and stakeholders, and ensure proper disposition of issues. It is the responsibility of the Program or Project Manager to propose options to combine reviews to providers, customers, and stakeholders, provided that the objectives of each are met. The goal is to maximize the probability of mission success through added value and efficiencies.

Independent reviews are conducted by independent panels composed of management, technical, and budget experts from organizations outside of the advocacy chain of the program/project being reviewed. To the extent possible, continuity of review panel membership is maintained from review to review and throughout the life cycle of a project.

The Program Manager negotiates with Mission Directorate and GPMC officials to optimize the value of independent reviews for a program/project. The agreement for independent reviews for each program is documented in the FAD, PCA, and Program Plan. The Program Manager flows down the agreed requirement for independent reviews, as appropriate, to the projects within the program. Independent reviews planned during the project life cycle are documented in the FAD (or equivalent) and in the Project Plan.

H.1.1.2 Concept Decision Review

A Concept Decision Review (CoDR) is an independent review conducted on both proposed programs and projects that use the evolutionary development approach. It provides Agency management with an independent assessment of the readiness of the program and project proceed into formulation (pre-Phase A to Phase A). Review criteria include assessment of the program's or project's alignment with NASA's strategic goals and the thoroughness of the planning for formulation. The CoDR is not applicable to programs and projects that use a traditional development approach.

H.1.1.3 Preliminary Non-Advocate Review

A Preliminary Non-Advocate Review (Pre-NAR) is an independent review of programs and projects conducted at the end of Phase A. It provides Agency management with an independent assessment of the readiness of the program or project to proceed into Phase B and an early assessment of preparations for implementation. Review criteria include assessment of the program's or project's concept, programmatic and technical plans for execution and draft implementation documentation.

H.1.1.4 Non-Advocate Review

A Non-Advocate Review (NAR) is an independent review process of programs and projects conducted at the end of formulation (Phase B). It provides Agency management with an independent assessment of the readiness of the program or project to proceed into implementation (Phase C). Upon successful completion of this review process, a recommended program or project baseline is established. Review criteria include assessment of the program's or project's preliminary design, plans for implementation and final implementation documentation.

H.1.1.5 Production Review

A Production Review (PR) is the independent review of an approved evolutionary project's programmatic and technical readiness to proceed with flight hardware production. It provides Agency management with an independent assessment of the readiness of the project to proceed into Phase D of implementation. Review criteria include assessment of the project's continued consistency with NAR Baseline commitments (performance, safety, cost, risk, and schedule) and adequacy of engineering hardware design, development, and test results. The PR is not applicable to programs and projects that use a traditional development approach.

H.1.1.6 Program Implementation Review

Program Implementation Reviews (PIR) are conducted by the IPAO after the NAR approval and assesses the program's continued consistency with NAR Baseline commitments (performance, safety, cost, risk, and schedule) and strategic alignment, as defined in a PCA, Program Plan, and/or Project Plans. The results of this review are reported to the Agency PMC. PIRs are nominally scheduled at two-year intervals during implementation.

H.1.1.7 Program and Project Safety and Mission Readiness Review

A Program Safety and Mission Readiness Review (SMARR) is a NASA Headquarters Safety and Mission Assurance review that is held for Chief Safety and Mission Assurance (SMA) Officer to independently assess, from an SMA perspective the readiness of selected mission event/milestones (e.g. launches and high risk tests). This assessment is designed to:

  1. Affirm that assurance processes have been implemented over the life of the program or project and verify compliance with the applicable baseline requirements set.
  2. Identify and evaluate the SMA residual risks for the program or project milestone.

All programs and projects shall provide support for Safety and Mission Assurance Readiness Review. This review is generally conducted concurrently with another program or project review occurring in the same timeframe. H.1.1.8 Office of Safety and Mission Assurance Program Audit and Review

The OSMA Program Audit and Review (PA&R) process is a series of reviews conducted by independent review teams throughout the program and project life cycle. These reviews are conducted to verify program or project compliance with Agency assurance process requirements and technical requirements by concentrating on flow-down in earlier phases and verification in later program and project phases. The process is designed to take full advantage of information gained in earlier phases, as well as other internal and external audits and reviews. All programs and projects shall provide support for OSMA PA&Rs. This review is generally conducted concurrently with another program or project review in the same timeframe.

H.1.1.9 Other Independent Technical Reviews and Assessments

Other Independent Technical Reviews and Assessments refer to reviews and assessments conducted by NESC and Center safety organizations, as authorized by NASA management, to evaluate technical and safety aspects of the projects. These assessments may include independent testing and analyses.

H.1.2 Assessment Criteria

Assessment criteria serve as a quality check of the engineering and management efforts.

Table H-1 Assessment Criteria

Note for Table H-1: Demonstrate is to show planning and tools are in place. Execution is to show results that plans are being effectively carried out.

H.1.3 Review Schedules

The following are typical schedules based on historical precedent and are provided for initial planning purposes. Table H-2 is for programs; Table H-3 is for common projects; and Table H-4 is for flight systems and ground support projects. The specific review schedule is negotiated between the independent review organization and the Mission Directorate (or Mission Support Office) point-of-contact in coordination with the Program or Project Manager, as appropriate. The agreed-upon schedule is documented In the Terms of Reference (ToR).

Table H-2 Program (Chapter 2)

Table H-3 Common Project (Chapter 3)

Table H-4 Flight Systems and Ground Support Projects (Chapter 6)

* Only for Evolutionary Acquisition.


47 CADRe Part A (project description) and a preliminary version of CADRe Part B (technical and programmatic description) is required three months prior to the decision review. An update to Part B is required 30 days prior to the decision review. CADRe Part C (the project lifecycle cost estimate) is due immediately after the decision review.

H.2 Project Milestone Reviews (PMR)

PMRs are the life-cycle series of rigorous system-level technical and programmatic evaluations conducted at key formulation and implementation milestones. Key milestones in this context are the major transition points in the life cycle, such as the transition from requirements development to design activities, final design to manufacturing, and the transition from the assembly and integration of components to system-level environmental testing. PMRs may include, but are not limited to, System Concept Review, Requirements Review, Preliminary Design Review, Critical Design Review, Pre-Environmental Review, Test Readiness Review, Pre-Ship Review, and Operational Readiness Review. Managers define the appropriate critical milestone reviews and document them as internally imposed requirements per the Agency Systems Engineering policy. The purpose of a PMR is to assess the technical and programmatic health of a program, project, or major element of a project with respect to the success criteria and acceptable risk. The reviews provide top-down systematic evaluations of the derivation and functional allocation of requirements, the engineering implementation to address the requirements, the validation and verification of the requirements, the preparation for operations and data analysis, and the system management processes that tie it all together. The PMRs must also address the resources (e.g., workforce, budget, schedule) required to complete the formulation and/or implementation of the program or project as well as any associated resource constraints, issues/risks, and reserves. PMRs will assert that the ITA technical requirements have been complied with, and the ITA has approved all variances to those requirements.

To minimize the burden on projects, efforts should be made to align PMRs with Independent Reviews, for example SDR and PDR should align respectively with Pre-NAR, NAR.

Members of review teams are chosen, based on their combined expertise, objectivity, and their ability to make a broad assessment of the implementation of the project that employs numerous engineering and other disciplines. A review team that provides continuity throughout the life cycle of the project is desirable to limit the amount of reeducation that must be done to get new members knowledgeable.

This systematic, integrated assessment relies on a robust set of appropriate lower level system and subsystem PDRs, CDRs and Engineering Peer Reviews, etc. The action items, results and recommendations of these reviews are documented and reported out at the next higher level of review. Inclusion of reviewers that are independent of the project advocacy chain on review teams is essential. Centers are expected to have procedures and guidelines in place to provide guidance specific to the work of the Center.

H.3 Engineering Peer Reviews (EPR)

EPRs are focused, in-depth technical reviews used to provide confirmation and offer options by bringing in experts early and at appropriate points throughout the life cycle. A thoughtfully formulated, comprehensive set of EPRs per the Agency Systems Engineering policy, is a cornerstone of a successful project. The reviews provide a penetrating table top examination of requirements, interfaces, design, analysis, manufacturing, integration, test and operational details, drawings, processes, and data.

EPRs are most frequently applied to subsystem or lower level development activities. They are also well suited for the evaluation of requirements, concepts, designs, and processes associated with combinations of subsystems and crosscutting functional subdivisions such as the end-to-end optical path, command and data pipeline, maneuver planning, or autonomous fault detection/correction system. Project Managers and line management define a set of engineering peer reviews appropriate for each project.

EPRs are most effective when accomplished with a small group of reviewers working intimately with the developers. Reviewers are experts independent of the executing team, including experts from outside of the performing organization. Reviewers are appointed in collaboration with the product lead's line management. The customers are the product leads and the Project Manager. They are also accountable for the definition of review objectives and subsequent communication and closure of issues resulting from the reviews.


APPENDIX I. Index


  • Accountability, 31, 63, 208
  • acquisition, 17, 23, 24, 26, 29, 39, 40, 59, 60, 63, 73, 74, 79, 82, 85, 96, 101, 108, 109, 114, 116, 150, 152, 158, 159, 172, 173, 185, 195, 198, 199, 202, 204
  • Acquisition Plan, 40, 41, 59, 109, 116, 122, 158, 159, 172
  • advanced technology development, ii, 59, 65, 69, 142, 172, 200
  • advisory groups, 23, 31, 63, 149
  • aeronautical, 10, 147
  • Agency vision, 30, 62, 128, 153
  • aircraft, 13, 39, 108, 142, 146, 147, 157, 158, 200
  • Alignment Matrices, 70, 178
  • alternative technology, 59, 172
  • AO, 35, 47, 65, 73, 76, 79, 109, 114, 123, 181, 196, 207
  • AoA, 23, 47, 77, 150, 164, 182, 193, 195, 206, 207
  • applied research, 12, 13, 19, 32, 52, 65, 69, 202
  • approval, ii, 17, 20, 23, 25, 26, 27, 28, 29, 31, 32, 34, 36, 37, 39, 42, 46, 52, 53, 55, 56, 62, 63, 67, 71, 73, 75, 78, 79, 80, 82, 83, 84, 86, 88, 100, 101, 103, 104, 106, 108, 109, 110, 112, 126, 143, 146, 149, 151, 152, 154, 155, 156, 158, 160, 161, 168, 170, 175, 176, 177, 179, 180, 182, 183, 185, 186, 187, 195, 202, 204, 205, 212
  • approving, 9, 34, 95, 99, 100, 155
  • architecture, 12, 22, 23, 30, 47, 96, 99, 146, 148, 150, 153, 165, 198, 202, 205
  • assembly, 17, 131, 142, 147
  • Associate Administrator, 14, 16, 91, 92, 94, 98, 105, 209
  • ATD, 65, 69, 70, 71, 72, 108, 109, 110, 178, 179, 207
  • BAA, 65, 207
  • Baseline, 28, 32, 35, 37, 46, 47, 53, 54, 55, 56, 57, 58, 71, 72, 74, 76, 77, 80, 121, 124, 126, 130, 156, 164, 165, 168, 169, 170, 171, 178, 179, 181, 182, 196, 200, 201, 202, 204, 209
  • basic and applied research, ii, 9, 12, 13, 14, 15, 16, 21, 32, 63, 65, 69, 142
  • budget, 10, 11, 14, 16, 23, 24, 29, 30, 32, 45, 50, 51, 53, 55, 57, 63, 67, 69, 85, 96, 101, 115, 116, 125, 128, 131, 149, 150, 152, 167, 168, 176, 196, 198, 199, 200, 201, 202, 203
  • CADRe, vii, 74, 76, 82, 112, 113, 114, 115, 116, 117, 118, 123, 124, 130, 142, 181, 185, 196, 197, 207
  • CAIB, 9, 207
  • CAN, 65, 207
  • CARD, 74, 113, 207
  • categorization, 14, 84
  • Category I, 45, 53, 63, 70, 71, 72, 74, 76, 78, 80, 81, 83, 84, 85, 109, 112, 113, 123, 124, 130, 164, 168, 178, 179, 181, 182, 184, 186, 212
  • Category II, 53, 80, 109, 113, 212
  • Category III, 53, 80, 212
  • CCRM, 74, 113, 117, 196, 207
  • CDR, 77, 115, 116, 142, 181, 207
  • Center Director, 16, 18, 26, 34, 36, 53, 80, 98, 104, 105, 107, 109, 151, 155, 203, 207
  • Center Real Property Master Plan, 86, 207
  • Chief Engineer, i, iii, iv, v, 13, 16, 23, 45, 48, 49, 62, 114, 143, 149, 164, 165, 174, 205, 210
  • Chief Financial Officer, 13, 45, 114, 143, 144, 164, 210
  • CIO, 39, 86, 88, 99, 158, 187, 207
  • CMPs, 86
  • CoF, 84, 85, 86, 87, 88, 89, 186, 187, 207
  • commercialization, 23, 35, 38, 59, 150, 157, 172
  • commitments, 16, 18, 23, 28, 30, 32, 54, 57, 62, 63, 96, 104, 126, 149, 152, 153, 171, 195, 198, 200, 202
  • Concept Decision Review, 26, 79, 126, 129, 130, 199
  • Configuration Management, 50, 109, 121, 123, 166, 196
  • Continuous Cost-Risk Management, 55, 169, 196
  • Contract, 37, 55, 60, 75, 156, 169, 173, 180, 197, 208
  • Contracting Officer, 41, 55, 59, 60, 159, 169, 172, 173
  • contractor, 13, 14, 36, 40, 44, 45, 54, 55, 57, 60, 61, 74, 75, 83, 108, 109, 111, 113, 155, 159, 163, 168, 169, 171, 173, 174, 180, 186, 199, 202, 203
  • contracts, ii, 12, 13, 29, 38, 41, 44, 54, 55, 59, 68, 152, 157, 159, 163, 168, 169, 172, 195, 197, 198
  • cost, 9, 11, 12, 14, 15, 18, 19, 21, 22, 24, 28, 29, 30, 32, 33, 34, 35, 38, 39, 45, 46, 47, 51, 52, 54, 55, 56, 57, 58, 59, 62, 63, 64, 65, 70, 71, 72, 73, 74, 75, 76, 77, 78, 83, 84, 85, 89, 93, 96, 100, 101, 102, 103, 106, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 126, 130, 142, 147, 148, 149, 150, 152, 153, 154, 157, 158, 163, 164, 167, 168, 169, 170, 171, 172, 175, 176, 178, 179, 180, 181, 182, 183, 186, 187, 195, 196, 197, 198, 199, 200, 201, 202, 203, 205
  • cost estimation, 45, 55, 70, 74, 169
  • critical assets, 11, 60, 173
  • CRM, 24, 50, 150, 166, 196, 207
  • cross-cutting, 12, 31, 84, 153
  • custodial, 31, 81, 153, 184
  • Customer, 54, 57, 171, 197
  • Customer Advocacy, 57, 171
  • customer involvement, 30, 153
  • customer satisfaction, 30, 34, 57
  • customers, 30, 32, 37, 57, 63, 77, 99, 106, 125, 132, 156, 171, 181, 195
  • dashboard, 19
  • data management, 23, 86, 101, 150
  • DCMA, 55, 60, 169, 173, 208
  • DDT&E, 117
  • decommissioning, 81, 142, 184, 188
  • Deputy Administrator, 18, 22, 28, 29, 53, 79, 80, 94, 97, 100, 101, 148, 152, 195
  • design, 11, 23, 46, 47, 53, 57, 58, 59, 60, 61, 70, 73, 81, 82, 85, 102, 106, 109, 110, 117, 118, 126, 131, 146, 147, 150, 165, 170, 171, 172, 173, 174, 184, 185, 195, 200, 201, 203, 205
  • design reference mission, 23, 150
  • disposal, 39, 81, 85, 95, 96, 108, 117, 142, 147, 158, 184, 188, 200, 201
  • disposition, 25, 31, 53, 61, 63, 81, 125, 151, 154, 174, 184
  • DRFP, 59, 172, 208
  • EA, 86, 88, 111, 187, 208
  • EAC, 56, 170, 208
  • ECO, 116
  • ECP, 116
  • ECR, 84, 86, 87, 88, 89, 186, 187, 208
  • education, 30, 42, 99, 106, 147, 153, 161
  • EMO, 42, 43, 161
  • employees, 29, 60, 152, 173
  • Environmental Impact Statement, 102, 111
  • Environmental Management Office, 42, 161
  • Environmental Management Plan, 42, 111, 122, 161
  • Erasmus, 19, 194
  • estimate, 17, 32, 33, 45, 52, 54, 56, 63, 64, 70, 71, 76, 78, 108, 114, 117, 130, 154, 163, 167, 170, 175, 178, 179, 181, 183, 199
  • evaluation, ii, 10, 17, 18, 20, 27, 31, 32, 33, 41, 53, 62, 63, 64, 65, 66, 67, 68, 73, 79, 82, 83, 89, 117, 131, 151, 154, 159, 168, 174, 175, 176, 178, 183, 185, 187, 199, 202, 203
  • EVM, 49, 54, 55, 60, 75, 83, 109, 165, 168, 169, 173, 180, 186, 197, 200, 208
  • expectation, 9
  • exploration, 10
  • fabrication, 61, 174
  • FAD, vii, 17, 21, 22, 26, 27, 35, 37, 56, 66, 91, 92, 121, 125, 148, 151, 156, 170, 198, 203, 205, 208
  • FAR, 29, 40, 55, 66, 152, 159, 169, 189, 208, 210
  • Fault Tree Analysis, 208
  • feasibility, 17, 35, 38, 101, 110, 157
  • financial structure, 11, 23, 69, 149
  • flight crews, 11, 60, 173
  • flight development projects, 196
  • flight systems, ii, 15, 26, 59, 69, 73, 74, 76, 78, 83, 115, 129, 142, 143, 145, 181, 182, 183, 187, 188
  • FMEA, 50, 166, 208
  • formulation, ii, 17, 20, 22, 23, 26, 31, 33, 34, 35, 36, 39, 40, 41, 43, 46, 47, 48, 49, 52, 53, 58, 62, 64, 66, 67, 70, 73, 74, 75, 77, 78, 79, 87, 91, 92, 93, 99, 125, 126, 131, 148, 149, 150, 151, 154, 155, 158, 160, 161, 164, 165, 166, 171, 175, 176, 177, 182, 195, 196, 198, 200, 201, 203, 205, 212
  • FPM, 85, 87, 89, 186, 187, 208
  • FTA, 50, 166, 208
  • Functional Leadership Plans, 10, 21, 93, 95, 148, 198
  • funding, 12, 13, 14, 29, 56, 65, 68, 82, 84, 85, 93, 108, 109, 116, 152, 170, 177, 185, 195, 196, 202
  • GAO, 31, 33, 63, 64, 78, 89, 154, 175, 183, 187, 194, 208
  • GFE, 31, 58, 153, 171, 208
  • goals, 10, 11, 12, 13, 17, 21, 22, 26, 29, 30, 31, 32, 34, 46, 57, 59, 62, 65, 66, 67, 68, 82, 84, 93, 96, 99, 100, 102, 106, 126, 128, 148, 149, 151, 152, 153, 172, 176, 185, 198, 202, 203, 204
  • government agencies, 15, 46, 106, 164
  • GPMC, 18, 34, 51, 52, 53, 56, 63, 64, 72, 74, 79, 80, 83, 84, 86, 88, 95, 102, 104, 107, 125, 130, 155, 167, 168, 170, 175, 176, 179, 183, 187, 195, 198, 199, 204, 205, 208, 212, 213
  • grants, 13, 29, 55, 68, 152, 169
  • ground support, ii, 13, 15, 19, 26, 52, 59, 63, 69, 73, 74, 76, 78, 79, 81, 83, 115, 129, 142, 143, 145, 147, 180, 181, 182, 183, 184, 187, 188
  • human spaceflight, 15
  • IA, 16, 18, 32, 47, 50, 53, 56, 62, 63, 64, 79, 80, 83, 111, 129, 130, 154, 165, 166, 168, 170, 175, 183, 185, 186, 189, 199, 204, 205, 208
  • IBPD, 10, 11, 96, 100, 208
  • IBR, 55, 168, 200, 209
  • IC, 18, 84, 88, 187, 209
  • ICE, 45, 53, 80, 88, 164, 168, 183, 187, 197, 199, 209
  • IFMS, 14, 84, 209
  • ILS, 209
  • implementation, ii, 16, 18, 20, 22, 23, 26, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 43, 46, 47, 50, 52, 53, 55, 56, 57, 58, 62, 64, 68, 71, 72, 73, 75, 78, 79, 80, 81, 82, 83, 88, 89, 96, 104, 108, 109, 116, 125, 126, 131, 147, 148, 149, 151, 152, 153, 154, 156, 161, 164, 166, 169, 171, 172, 174, 175, 177, 179, 180, 183, 184, 185, 187, 195, 196, 198, 200, 201, 202, 203, 205
  • implementing, ii, 9, 12, 16, 22, 29, 43, 54, 100, 146, 149, 152, 161, 168
  • IMS, 36, 37, 75, 116, 156, 180, 197, 200, 209
  • Independent Assessment, 18, 32, 50, 154, 166, 199, 208
  • independent expert, 31, 62
  • Independent review, 15, 125
  • Information System, 24, 62, 68, 123, 150, 175, 189, 194, 209, 210
  • information technology, 10, 39, 40, 43, 44, 84, 108, 157, 159, 162, 197, 200
  • infrastructure, 12, 13, 14, 30, 31, 38, 39, 44, 46, 51, 59, 82, 84, 86, 108, 109, 153, 157, 158, 162, 164, 167, 185, 200
  • in-house, 12, 13, 36, 40, 108, 116, 155, 159, 200
  • innovation, 11, 65
  • institutional, ii, 14, 19, 26, 35, 52, 84, 85, 86, 87, 88, 89, 100, 102, 109, 142, 186, 187
  • institutional projects, 14, 19, 52, 84, 86, 88, 89, 186, 187
  • Integrated Space Plan, 10
  • integration, 12, 21, 28, 30, 39, 41, 47, 49, 55, 59, 70, 71, 101, 107, 113, 118, 131, 146, 147, 157, 160, 165, 166, 169, 179, 197, 205
  • international, 15, 17, 22, 23, 24, 30, 39, 40, 44, 45, 51, 82, 95, 96, 101, 106, 108, 149, 150, 158, 163, 167, 185
  • international partnerships, 17
  • International System of Units, 52, 168, 211
  • Investment, v, 13, 14, 34, 88, 155, 186, 211
  • investment areas, 9, 13, 31, 153
  • IPAO, 16, 27, 28, 32, 33, 64, 72, 89, 114, 126, 129, 151, 154, 175, 187, 199, 202, 205, 209
  • IRT, 199, 209
  • IT, 34, 39, 84, 86, 87, 88, 89, 155, 157, 158, 186, 187, 204, 209
  • ITA, 9, 16, 17, 48, 62, 131, 199, 209
  • IV&V, 89, 102, 111, 187, 192, 199, 209
  • KPP, 47, 56, 70, 71, 72, 77, 100, 109, 123, 164, 165, 170, 178, 179, 182, 196, 198, 200, 205, 209
  • KPPs, 47, 49, 54, 57, 70, 71, 72, 77, 82, 100, 107, 109, 123, 164, 171, 178, 179, 182, 185, 200
  • launch vehicle, 13, 15, 39, 78, 96, 106, 145, 147, 158
  • LCC, 34, 35, 39, 70, 77, 82, 108, 123, 158, 182, 185, 195, 201, 209
  • LCCE, 45, 47, 74, 76, 77, 108, 113, 114, 117, 163, 164, 181, 182, 209
  • leadership, 16, 21, 31, 62, 148
  • lessons learned, 23, 36, 62, 149, 155, 175
  • Life-Cycle Cost, 201, 209
  • lifecycle processes, 20
  • management structure, 12, 21, 23, 107, 109, 148, 149, 202
  • Master Schedule, 36, 37, 75, 108, 113, 114, 116, 121, 156, 180, 200, 209
  • MDAA, 14, 16, 17, 21, 22, 23, 25, 26, 30, 31, 32, 33, 35, 37, 39, 45, 47, 48, 49, 53, 54, 55, 62, 63, 64, 66, 67, 72, 75, 78, 80, 82, 84, 93, 95, 96, 97, 102, 109, 148, 149, 151, 154, 156, 158, 164, 165, 168, 174, 175, 176, 177, 179, 180, 183, 185, 198, 202, 203, 205, 209
  • metric, 52, 56, 168, 170, 201
  • metrics, 28, 33, 46, 89, 117, 152, 154, 164, 187, 202
  • milestone, 27, 32, 36, 53, 63, 64, 71, 72, 74, 79, 109, 111, 116, 118, 127, 131, 151, 155, 168, 176, 178, 179, 183
  • milestones, 15, 17, 22, 26, 29, 37, 38, 43, 44, 52, 62, 63, 70, 71, 72, 74, 78, 95, 100, 108, 110, 127, 131, 142, 149, 152, 156, 157, 161, 163, 175, 178, 179, 183, 196, 204
  • mission, 9, 10, 13, 14, 15, 18, 23, 24, 25, 30, 34, 35, 37, 38, 40, 41, 42, 47, 51, 56, 60, 70, 73, 76, 77, 78, 81, 82, 84, 85, 86, 88, 99, 100, 101, 102, 106, 107, 109, 110, 111, 115, 125, 127, 145, 146, 147, 150, 153, 156, 157, 159, 160, 161, 164, 167, 170, 173, 180, 181, 182, 184, 185, 187, 195, 196, 199, 200, 201, 202, 203
  • Mission, ii, 10, 11, 12, 13, 14, 15, 16, 18, 21, 22, 23, 26, 28, 29, 30, 32, 33, 34, 35, 39, 40, 41, 42, 43, 45, 48, 60, 63, 64, 66, 72, 75, 77, 79, 84, 86, 87, 91, 92, 93, 94, 95, 98, 99, 100, 101, 105, 106, 107, 115, 116, 121, 122, 124, 125, 127, 129, 142, 146, 147, 148, 149, 151, 152, 153, 154, 155, 158, 159, 160, 161, 164, 165, 173, 175, 176, 180, 181, 192, 195, 198, 201, 202, 203, 205, 209, 210, 211, 212
  • mission assurance, 23, 35, 40, 60, 76, 100, 101, 146, 150, 159, 173, 180
  • Mission Directorates, ii, 10, 11, 13, 15, 18, 34, 93, 142, 155
  • mission success, 15, 18, 24, 34, 35, 37, 41, 47, 51, 73, 77, 84, 85, 99, 106, 110, 125, 146, 150, 156, 160, 164, 167, 181, 201, 203
  • Mission Success, 41, 122, 159, 160, 192, 201
  • Mission Support Office, ii, 10, 12, 13, 14, 15, 16, 18, 21, 22, 23, 26, 29, 30, 34, 35, 40, 43, 48, 63, 84, 87, 91, 92, 93, 94, 95, 98, 99, 100, 101, 105, 107, 129, 142, 148, 149, 151, 152, 155, 158, 161, 165, 195, 198, 202, 205, 209
  • modification, 29, 39, 53, 80, 152, 158
  • MSOD, 14, 16, 17, 21, 22, 23, 25, 26, 28, 30, 31, 32, 33, 35, 39, 45, 47, 48, 49, 53, 54, 55, 62, 63, 64, 66, 67, 80, 84, 89, 93, 95, 96, 97, 102, 148, 149, 151, 154, 158, 164, 165, 168, 174, 175, 176, 177, 187, 198, 202, 203, 205, 209
  • MSRD, 146
  • NAR, 26, 27, 28, 32, 34, 45, 46, 47, 49, 52, 53, 54, 56, 57, 63, 64, 71, 72, 73, 76, 78, 79, 80, 83, 88, 95, 96, 104, 114, 115, 118, 120, 121, 123, 126, 128, 129, 130, 131, 151, 154, 155, 163, 165, 168, 170, 171, 175, 179, 181, 183, 186, 187, 196, 201, 202, 204, 209, 212
  • NEPA, 43, 102, 111, 122, 146, 161, 209
  • NESC, 33, 61, 64, 82, 127, 154, 174, 175, 176, 210
  • new technologies, 13, 81, 101, 110, 185
  • NFS, 40, 41, 59, 159, 172, 189, 210
  • NPD, ii, 10, 15, 16, 39, 41, 42, 43, 52, 66, 77, 85, 88, 99, 158, 160, 161, 162, 168, 182, 190, 191, 192, 193, 210
  • NRA, 65, 210
  • nuclear, 15, 42, 43, 160, 161
  • OAIT, 86, 210
  • objectives, 10, 12, 18, 21, 22, 26, 29, 34, 35, 36, 38, 40, 54, 66, 81, 82, 89, 93, 95, 96, 99, 100, 102, 106, 109, 111, 125, 132, 146, 148, 149, 151, 152, 157, 159, 176, 185, 187, 195, 197, 200, 201, 202, 203, 204
  • OCE, 13, 16, 18, 29, 31, 32, 33, 39, 62, 63, 64, 75, 99, 152, 154, 158, 175, 180, 210
  • OCFO, 13, 23, 28, 29, 45, 75, 77, 78, 82, 89, 149, 152, 164, 180, 181, 183, 185, 187, 210
  • Office of External Relations, 23, 82, 149, 185
  • OFI, 84, 87, 89, 186, 187, 210
  • OMB, 29, 33, 64, 87, 152, 154, 175, 189, 210
  • operations, 10, 12, 13, 16, 23, 24, 30, 33, 39, 41, 46, 48, 49, 53, 54, 56, 58, 59, 60, 61, 62, 73, 74, 75, 76, 77, 78, 80, 81, 82, 84, 88, 95, 96, 100, 107, 108, 109, 115, 117, 131, 145, 146, 147, 150, 153, 154, 158, 160, 164, 165, 169, 171, 172, 173, 174, 180, 181, 182, 183, 184, 185, 186, 195, 200, 204, 206
  • OSMA, 42, 99, 127, 161, 210
  • oversight, 13, 14, 18, 19, 21, 23, 28, 30, 86, 95, 99, 107, 146, 149, 202, 203, 204
  • PA&R, 127, 210
  • partners, 23, 30, 37, 44, 45, 66, 82, 95, 96, 101, 106, 116, 146, 149, 156, 163, 185
  • PCA, 17, 18, 22, 26, 28, 29, 35, 37, 51, 52, 53, 80, 97, 100, 106, 125, 126, 148, 151, 152, 156, 167, 195, 202, 205, 210
  • PDR, 116, 131, 142, 210
  • peer, 13, 63, 65, 67, 68, 132, 177
  • performance, 9, 10, 11, 13, 17, 18, 19, 22, 24, 25, 28, 30, 31, 32, 33, 34, 35, 38, 40, 41, 45, 46, 47, 52, 54, 55, 56, 58, 59, 60, 62, 63, 64, 65, 67, 68, 70, 71, 74, 77, 81, 82, 83, 85, 89, 95, 99, 100, 106, 108, 109, 115, 116, 118, 126, 146, 148, 150, 152, 153, 154, 157, 159, 163, 164, 165, 167, 169, 170, 171, 172, 173, 176, 177, 178, 179, 182, 185, 186, 187, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205
  • performance goals, 106
  • performance metrics, 22, 68, 148, 177
  • Phase A, 73, 76, 77, 79, 83, 104, 120, 126, 181
  • Phase B, 73, 78, 83, 126, 183
  • Phase C, 73, 126
  • Phase D, 126
  • Phase E, 73, 75, 76, 77, 78, 81, 114, 118, 147, 180, 181, 182, 185
  • PI, 65, 68, 73, 99, 106, 177, 200, 210
  • PIR, 32, 33, 126, 128, 129, 154, 202, 210
  • PMC, ii, 18, 26, 27, 28, 29, 30, 31, 32, 33, 45, 72, 79, 85, 126, 151, 152, 153, 154, 164, 195, 198, 199, 203, 210, 212
  • PMRs, 131
  • POP, 96, 203, 210
  • portfolio, 9, 10, 11, 12, 14, 15, 21, 28, 65, 66, 67, 68, 70, 151, 176, 177, 178, 202
  • Portfolio Manager, 66, 67, 68, 176, 177
  • Portfolio Process Plan, 66, 67, 68, 176, 177
  • PRA, 50, 78, 81, 113, 166, 182, 184, 202, 210
  • pre-formulation activities, 35
  • priority, 14, 15, 70
  • product lines, 12, 13, 19, 21, 31, 73, 142, 148, 153
  • program control, 28, 151, 152
  • Program Formulation, vi, 22, 91, 148
  • Program Implementation Reviews, 32, 126, 154
  • program integration, 21
  • Program Manager, 14, 16, 17, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 39, 41, 45, 47, 49, 55, 56, 61, 63, 64, 66, 67, 71, 72, 77, 78, 86, 92, 98, 99, 100, 101, 104, 105, 107, 109, 110, 125, 129, 148, 149, 150, 151, 152, 153, 154, 155, 156, 158, 159, 163, 164, 165, 169, 170, 174, 175, 176, 178, 179, 181, 183, 203, 205, 212, 213
  • program modification, 29, 152
  • Program Plan, vii, 12, 16, 17, 18, 22, 23, 25, 26, 28, 29, 30, 31, 32, 33, 34, 35, 37, 47, 66, 68, 69, 91, 92, 93, 98, 100, 101, 103, 104, 106, 120, 125, 126, 148, 149, 150, 151, 152, 153, 154, 155, 156, 178, 202, 203, 205
  • Program Safety and Mission Readiness, 127
  • project assessment and control, 49, 54
  • project categorization, 15
  • project concepts, 35
  • project life cycle, 36, 37, 46, 50, 57, 73, 104, 113, 125, 127, 155, 156, 166
  • Project Manager, 13, 14, 15, 16, 18, 19, 21, 22, 23, 30, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 69, 70, 71, 72, 73, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 99, 104, 105, 107, 108, 110, 113, 114, 115, 117, 125, 129, 130, 132, 143, 148, 149, 153, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 196, 200, 203, 208, 212, 213
  • Project Plan, vii, 14, 16, 18, 26, 29, 31, 34, 35, 36, 37, 38, 39, 40, 41, 42, 45, 46, 47, 49, 50, 52, 53, 54, 55, 57, 58, 62, 63, 64, 69, 71, 75, 79, 80, 81, 82, 88, 100, 104, 105, 106, 110, 112, 114, 121, 125, 126, 151, 152, 154, 155, 156, 157, 158, 159, 160, 161, 163, 164, 165, 166, 167, 168, 169, 171, 175, 176, 178, 179, 180, 183, 185, 186, 187, 196, 199, 202, 203, 205
  • Project planning, 36, 75
  • PSR, 78, 89, 183, 187, 211
  • QSR, 55, 169, 211
  • Quality Assurance, 61, 174, 194, 203
  • RBAM, 40, 159
  • REC, 111
  • reliability, 9, 11, 16, 23, 42, 60, 77, 101, 110, 116, 149, 160, 173, 182, 201
  • research, 12, 13, 22, 23, 38, 39, 55, 65, 66, 67, 68, 69, 78, 89, 95, 101, 110, 149, 150, 157, 169, 177, 196, 200, 202
  • resources, 9, 11, 12, 17, 31, 32, 35, 38, 43, 49, 54, 59, 62, 63, 64, 66, 69, 73, 88, 110, 128, 131, 147, 154, 156, 157, 162, 172, 175, 186, 195, 198, 199, 200, 203
  • review, 16, 17, 18, 19, 25, 26, 27, 28, 29, 31, 32, 33, 34, 36, 44, 49, 50, 52, 53, 54, 56, 62, 63, 64, 65, 67, 68, 71, 72, 73, 79, 83, 102, 104, 111, 114, 125, 126, 127, 129, 130, 131, 132, 143, 146, 150, 151, 152, 154, 155, 163, 165, 166, 168, 170, 175, 177, 179, 183, 185, 188, 198, 199, 200, 202, 205
  • revision, 29, 152
  • risk, 11, 17, 18, 22, 23, 24, 28, 31, 32, 35, 37, 38, 39, 40, 41, 42, 44, 49, 50, 51, 52, 55, 56, 59, 60, 62, 64, 65, 70, 74, 76, 78, 81, 82, 83, 84, 88, 96, 101, 102, 103, 108, 109, 110, 112, 117, 118, 126, 127, 128, 131, 146, 150, 153, 154, 156, 157, 158, 159, 160, 162, 166, 167, 169, 172, 173, 175, 178, 181, 183, 184, 185, 186, 195, 196, 197, 199, 201, 202, 203, 204, 205, 206
  • risk assessments, 17, 24, 38, 39, 44, 62, 88, 150, 157, 158, 162, 175, 186, 201
  • Risk Management Plan, 24, 50, 51, 55, 102, 109, 113, 120, 123, 146, 150, 166, 167, 169, 197
  • risk management process, 24, 41, 51, 55, 150, 160, 167, 169
  • risk mitigation, 50, 52, 55, 81, 117, 166, 167, 169, 184, 196
  • ROI, 34, 70, 88, 155, 178, 186, 211
  • safety, 9, 11, 15, 16, 18, 19, 22, 23, 24, 28, 31, 33, 34, 35, 37, 40, 41, 42, 43, 46, 48, 49, 50, 51, 52, 58, 60, 64, 73, 76, 77, 81, 95, 96, 99, 100, 101, 103, 109, 110, 112, 125, 126, 127, 146, 149, 150, 152, 153, 154, 156, 159, 160, 161, 164, 165, 166, 167, 171, 173, 176, 180, 182, 184, 185, 200, 201, 202, 203
  • Safety and Health Plan, 41, 159
  • schedule, 17, 18, 19, 22, 24, 28, 29, 30, 32, 33, 34, 35, 43, 45, 46, 47, 51, 52, 54, 55, 56, 57, 58, 59, 64, 67, 71, 72, 74, 75, 77, 85, 86, 96, 100, 102, 106, 108, 109, 111, 115, 116, 118, 126, 128, 129, 131, 142, 149, 150, 152, 154, 161, 163, 164, 167, 168, 169, 170, 171, 172, 175, 176, 178, 179, 180, 182, 196, 197, 199, 200, 201, 202, 203, 204, 205, 206
  • Schedule Management, 75, 180, 204, 211
  • science, 10, 13, 14, 15, 35, 42, 99, 102, 106, 111, 146, 161, 203
  • security, 22, 23, 24, 34, 40, 43, 44, 51, 89, 150, 155, 159, 162, 167, 187
  • SI, 52, 168, 191, 211
  • single-project, 12, 21, 26, 73, 151
  • size, 21, 34, 37, 70, 84, 148, 155, 156
  • SMA, 23, 33, 41, 64, 127, 149, 154, 159, 160, 176, 192, 211
  • SMARR, 33, 64, 127, 154, 176, 211
  • SMO, 64, 74, 175, 199, 205, 211
  • software, 14, 23, 38, 40, 41, 44, 45, 46, 47, 50, 58, 59, 60, 61, 81, 86, 88, 89, 101, 102, 107, 109, 110, 111, 114, 116, 117, 146, 147, 149, 157, 159, 160, 162, 163, 164, 165, 171, 172, 173, 174, 184, 186, 187, 195, 199, 201, 204, 206
  • Software Management Plan, 76, 124, 180
  • space, 10, 11, 12, 13, 23, 24, 39, 51, 59, 82, 101, 108, 110, 115, 142, 146, 147, 150, 157, 158, 167, 185, 197
  • spacecraft, 12, 13, 73, 145, 146, 147
  • spares, 31, 81, 108, 154, 184
  • stakeholders, 12, 30, 37, 77, 99, 106, 109, 125, 156, 181
  • STEM, 14, 42, 161, 211
  • Strategic Plan, ii, 10, 11, 13, 86, 99, 190, 198, 204
  • strategies, 9, 12, 17, 23, 35, 37, 82, 101, 110, 116, 150, 156, 185, 202
  • success criteria, 17, 22, 35, 36, 77, 81, 82, 100, 106, 107, 109, 120, 121, 125, 131, 148, 149, 182, 185, 195, 201
  • sustainment costs, 73, 77, 181
  • synergy, 12, 39, 109, 158
  • systems engineering, 20, 23, 45, 46, 57, 111, 150, 164, 200, 205
  • technology, 13, 14, 21, 23, 30, 31, 35, 36, 38, 42, 44, 46, 51, 54, 56, 57, 59, 63, 65, 69, 70, 71, 72, 81, 82, 95, 99, 101, 102, 106, 108, 110, 111, 118, 146, 150, 153, 157, 161, 163, 164, 167, 169, 171, 172, 178, 179, 184, 185, 196, 198, 199, 204, 205
  • Termination Review, 32, 63, 78, 80, 102, 106, 183, 205
  • terrestrial applications, 13
  • testing, 24, 51, 58, 73, 82, 116, 127, 131, 146, 147, 150, 167, 172
  • theme, 11, 13
  • ToR, 32, 33, 64, 83, 129, 154, 175, 186, 211
  • TRLs, 69, 70, 72, 179
  • TWH, 16, 23, 27, 33, 48, 49, 52, 53, 61, 62, 149, 151, 154, 165, 167, 168, 174, 175, 195, 211
  • uncertainty, 52, 167
  • V&V Plan, 47, 58, 165, 172
  • validation, 21, 23, 38, 47, 58, 59, 82, 102, 106, 110, 111, 117, 131, 150, 157, 165, 171, 172, 185, 201
  • verification, 47, 58, 59, 102, 106, 111, 127, 131, 146, 165, 171, 172, 199, 201, 204
  • WBS, viii, 11, 35, 36, 37, 40, 45, 55, 67, 71, 74, 75, 76, 82, 88, 106, 107, 108, 114, 115, 116, 117, 118, 121, 123, 142, 143, 144, 145, 146, 147, 155, 156, 159, 163, 169, 176, 178, 180, 185, 186, 187, 188, 196, 197, 206, 211

APPENDIX J: Flight Systems and Ground Support Project Work Breakdown Structure (WBS)


J.1 Introduction

J.1.1 The Project Work Breakdown Structure (WBS) is a key element of project management. The purpose of a WBS is to divide the project into manageable pieces of work to facilitate planning and control of cost, schedule, and technical content.

J.2 Assumptions

J.2.1 The WBS standard elements defined in this appendix are only applicable to the flight systems and ground support product line. There is work in progress to develop standard WBS elements for the basic and applied research, advanced technology development, and institutional product lines. These elements will be incorporated in future revisions of NPR 7120.5.

J.2.2 The following list of assumptions is provided as background information to assist in the development of the project WBS: a. The ONCE (CADRe) database captures major assembly/sub-system (or next lower level) actuals at major milestones (PDR, CDR, etc.). b. Acknowledge that there are both political and technical requirement drivers to a WBS.

J.3 Project Requirements and Business Rules

J.3.1 Purpose: The standardization of WBS elements for the flight systems and ground support (aircraft and space vehicles) product line is being driven by requirements for more effective cost estimating, and consistency of project work packages across the Agency. The standard WBS is intended to apply to projects, not programs. There are no program WBS standard requirements due to the variance in structure of the Mission Directorates and Mission Support Offices.

J.3.2 Requirements: For flight systems and ground support projects:

  1. The standard flight systems and ground support project WBS shall be applied to new projects established from June 1, 2005 forward. It is not intended to be applied retroactively to existing projects.
  2. The standard flight systems and ground support project WBS shall apply to the entire life cycle of the project, including disposal and decommissioning.
  3. The standard flight systems and ground support project WBS shall apply to both crewed and robotic projects.
  4. Flight systems and ground support projects shall use the standard Level 1/2 WBS elements (See Section J.5.). Specifically:
  1. The Project Name shall be WBS Level 1.
  2. The title of each WBS Level 2 element can be modified to facilitate project-unique titles, but the content of each must remain the same. If the linkage of the standard and the project-unique title are not intuitive, the project-unique title shall be cross-referenced to the standard title and provided to the WBS Review Team.
  3. The set of standard WBS Level 2 elements do not comprise an exhaustive or exclusive set of WBS elements. Additional WBS elements may be added horizontally (i.e., at Level 2) as long as the content of which does not fit into the content of any existing standard WBS elements.
  4. For each standard WBS Level 2 element, the subordinate (children) WBS elements at Level 3 and lower shall be determined by the project.
  5. The Level 3 and lower elements can differ from project to project, but shall include only work that rolls up to the standard WBS Dictionary definition of the Level 2 element. (See Section J.6.)
  6. If there is no work to fit into a standard WBS element, then an inactive placeholder element (and an inactive placeholder financial code) shall be established.
  7. The financial WBS shall align with the technical WBS.
  8. The management assigned to each WBS element may differ from project to project.
  1. Changes to the standard flight systems and ground support project WBS shall be governed by the WBS Review Team.
  2. Other changes can be made to the standard flight systems and ground support project WBS, but must be approved by WBS Review Team. Requested changes shall be made on a waiver form via the Meta Data Manager (to be in operation June 1, 2005) and submitted to the WBS Review Team, whereby a stringent review process occurs ensuring valid rationale is used to support the changes.

J.4 WBS Review Team

J.4.1 The WBS Review Team is chartered to review and approve Project Work Breakdown Structures. The Project Manager documents approval to use non-standard flight systems and ground support WBS Level 2 elements by processing a waiver or deviation through the WBS Review Team.

J.4.2 The WBS Review Team consists of four members:

  1. Primary member from the Office of the Chief Engineer
  2. Secondary member from the Office of the Chief Engineer
  3. Primary member from the Office of the Chief Financial Officer
  4. Secondary member from the Office of the Chief Financial Officer
  5. Primary members are voting members, and have the authority to approve the project WBS. Secondary members are observers, but can substitute for an absent primary member and then have full voting authority.

J.5 Flight Systems and Ground Support Project WBS Standard Elements

Standard Level 2 WBS elements for the flight systems and ground support product line are shown in Figure J.5-1. The standard WBS template below assumes a typical spacecraft flight development project with relatively minor ground or mission operations elements. For major launch or mission operations ground development activities which are viewed as projects unto themselves, the WBS may be modified. For example, the aero-craft/spacecraft element may be changed to reflect the ground project major deliverable product (such as a facility). The elements such as payload, launch vehicle/services, ground systems, mission operations system may not be applicable and may be deleted.

Figure J.5-1

J.6 Flight Systems and Ground Support Project Standard WBS Dictionary

Element 1 - Project Management: The business and administrative planning, organizing, directing, coordinating, controlling, and approval processes used to accomplish overall Project objectives, which are not associated with specific hardware or software elements. This element includes project reviews and documentation (including NEPA), non-project owned facilities, and project reserves. It excludes costs associated with technical planning and management, and costs associated with delivering specific engineering, hardware and software products.

Element 2 - Systems Engineering: The technical and management efforts of directing and controlling an integrated engineering effort for the project. This element includes the efforts to define the project vehicle - ground system, conducting trade studies; the integrated planning and control of the technical program efforts of design engineering, software engineering, specialty engineering, human rating, system architecture development, and integrated test planning, system requirements writing, configuration control, technical oversight, control and monitoring of the technical program, and risk management activities. Documentation Products include mission/system requirements document (MSRD); interface control documents (ICDs); Risk Management Plan and Verification and Validation (V&V) Plan. Excludes any design engineering costs.

Element 3 - Safety and Mission Assurance: The technical and management efforts of directing and controlling the safety and mission assurance elements of the project. This element includes design, development, safety assessment, review, and verification of practices and procedures and mission success criteria intended to assure that the delivered aero-craft/spacecraft, ground systems, mission operations, and payload(s) meet performance requirements and function for their intended lifetimes. This element excludes mission and product assurance efforts at partners/ subcontractors other than a review/oversight function, and the direct costs of environmental testing. Product assurance efforts should be distributed to each separate product/deliverable WBS element.

Element 4 - Science / Technology: This element includes the managing, directing, and controlling of the science investigation aspects, as well as leading, managing, and performing the technology demonstration elements of the Project. The costs incurred to cover the Principal Investigator, Project Scientist, science team members, and equivalent personnel for technology demonstrations are included. Specific responsibilities include defining the science or demonstration requirements; ensuring the integration of these requirements with the payloads, aero-craft/spacecraft; ground systems, mission operations; providing the algorithms for data processing and analyses; and performing data analysis and archiving. This element excludes hardware and software for on-board science investigative instruments / payloads.

Element 5 - Payload: This element includes the equipment provided for special purposes in addition to the normal equipment (i.e. GSE) integral to the aero-craft or spacecraft. This includes leading, managing, and implementing the hardware and software payloads that perform the scientific experimental and data gathering functions placed on board the aero-craft or spacecraft, as well as the technology demonstration for the mission.

Element 6 - Aircraft(s) / Spacecraft(s): The aircraft or spacecraft that serves as the platform for carrying payload(s), instrument(s), humans, and other mission-oriented equipment in space or air to the mission destination(s) to achieve the mission objectives. The aircraft or spacecraft may be a single aircraft or spacecraft or multiple crafts/modules (i.e. cruise stage, orbiter, lander, or rover modules). Each craft/module of the system includes the following subsystems as appropriate: Crew, Power, Command & Data Handling, Telecommunications, Mechanical, Thermal, Propulsion, Guidance Navigation and Control, Wiring Harness, and Flight Software. This element also includes all design, development, production, assembly, test efforts and associated GSE to deliver the completed system for integration with the launch vehicle and payload. This element does not include integration and test with payloads and other project systems.

Element 7 - Mission Operations System: The management of the development and implementation of personnel, procedures, documentation and training required to conduct mission operations. This element includes tracking, commanding, receiving/processing telemetry, analyses of system status, trajectory analysis, orbit determination, maneuver analysis, target body orbit/ephemeris updates, logistics, and disposal of remaining mission resources at end-of-mission. The same WBS structure is used for Phase E Mission Operation Systems but with inactive elements defined as "not applicable". However, different accounts must be used for Phase E due to NASA cost reporting requirements. This element does not include integration and test with the other project systems.

Element 8 - Launch Vehicle / Services: The management and implementation of activities required to place the aircraft or spacecraft directly into its operational environment, or on a trajectory towards its intended target. This element includes launch vehicle; launch vehicle integration; launch operations; any other associated launch services (frequently includes an upper-stage propulsion system), and associated ground support equipment. This element doesn't include the integration and test with the other project systems.

Element 9 - Ground System(s): The complex of equipment, hardware, software, networks, and mission-unique facilities required to conduct mission operations of the aero-craft or spacecraft systems and payloads. This complex includes the computers, communications, operating systems, and networking equipment needed to interconnect and host the Mission Operations software. This element includes the design, development, implementation, integration, test and the associated support equipment of the ground system, including the hardware and software needed for processing, archiving and distributing telemetry and radiometric data and for commanding the aeronautical or space craft. Also includes the operations, maintenance, and disposal of the project testbeds and project-owned facilities. This element does not include integration and test with the other project systems and conducting mission operations.

Element 10 - Systems Integration and Testing: This element includes the hardware, software, procedures and project-owned facilities required to perform the integration and testing of the project's systems, payloads, aircraft / spacecraft, launch vehicle / services, and mission operations.

Element 11 - Education and Public Outreach: Provide for the education and public outreach (EPO) responsibilities of NASA's missions, projects, and programs in alignment with the Strategic plan for Education (Includes management and coordinated activities, formal education, informal education, public outreach, media support, and web site development).


APPENDIX K. Compliance Matrix


NOTE: For non-compliance, approved deviation(s) and/or waiver(s) must be attached

Program/Project Name: Date:
Program/Project Manager:
Requirement Compliant
(Yes/No)
2 CHAPTER 2. Program Management Requirements
2.1 Four-Part Program Management Process
2.1.a As a strategic management structure, the program construct is extremely important within NASA. Programs provide the critically important linkage between the Agency's ambitious goals and the projects that are the instruments for achieving them. Programs vary significantly in scope, complexity, cost, and criticality; however, a properly designed and executed program structure inevitably contributes to sound project management being embraced and practiced at lower levels. To initiate individual programs, a Mission Directorate (or Mission Support Office) shall prepare a program Formulation Authorization Document (FAD).
2.1.b The Program Manager is responsible for ensuring that program goals address the Mission Directorate Strategies and Mission Support Office Functional Leadership Plans and that the program's content, which may contain multiple product lines, addresses those program goals. The Program Manager shall be responsible for recommending to the MDAA (or MSOD) the appropriate product line for each project in his/her program. The Program Manager coordinates program content with the Mission Directorate (or Mission Support Office), provides leadership, and is responsible for the successful accomplishment of the program that meets the needs of the customer. This chapter further delineates the management requirements for programs, described in terms of the four-part management process of paragraph 1.7.1. Program Managers shall meet all requirements outlined in this chapter irrespective of the size of the program.
2.2 Program Formulation
2.2.1 Purpose: The purpose of program formulation activities is to establish a cost-effective program that is demonstrably capable of meeting Agency and Mission Directorate (or Mission Support Office) goals and objectives. The program Formulation Authorization Document (FAD) authorizes a Program Manager to initiate the planning of a new program, and to perform the analyses required to formulate a sound Program Plan. A FAD template is found in Appendix A. The PCA is the agreement between the MDAA (or MSOD) and the NASA Deputy Administrator that authorizes transition from formulation to implementation. A PCA can be considered an executive summary of the Program Plan. A PCA template is found in Appendix B.
2.2.2 Requirements: During program formulation, the Program Manager, once selected, shall:
2.2.2.a Prepare a Program Plan.
(1) In the Program Plan, the Program Manager shall define and document an affordable program architecture along with the success criteria and performance metrics. (A Program Plan template is provided in Appendix C.) Specifically, the Program Manager shall:
(i) Ensure that top-level requirements, including success criteria, for each constituent project are defined in coordination with the Mission Directorate (or Mission Support Office) and documented in the Program Plan.
(ii) Ensure the validated top-level requirements and program success criteria flow down to projects or portfolios. Program Managers are required to demonstrate this linkage (traceability) while formulating and implementing a program, and this linkage will be closely monitored when the Program Plan is reviewed.
(iii) Prepare estimates of yearly New Obligational Authority (NOA) consistent with top-level program requirements, and identify the civil service workforce so as to enable full cost estimates.
(iv) Prepare an overall program timeline with key milestones related to the accomplishment of program goals and objectives. When applicable, the timeline should provide guidance and a schedule for the announcement of new project (or research) opportunities.
(v) Document synergistic activities with other NASA, industry, academia, and international programs.
(vi) Prepare and implement a comprehensive Safety and Mission Assurance (SMA) Plan early in program formulation to ensure program compliance with all regulatory safety requirements from OSHA and all NASA Safety and Mission Assurance requirements such as mishap reporting and investigation, range safety, software safety and assurance, and human rating requirements. The importance of up-front safety, reliability, maintainability, and quality assurance requirements should be emphasized in all program activities.
(2) Beginning early in program formulation, the Program Manager shall work with the Office of External Relations, the Deputy Chief Acquisition Officer, and the MDAA (or MSOD) to identify potential non-NASA partners and necessary agreements for international or interagency cooperation.
(i) All activities and documentation shall be consistent with policy directives and with Mission Directorate (or Mission Support Office) and Agency-level agreements with the partners.
(ii) All program-enabling commitments shall be obtained prior to program approval for implementation.
(3) The Program Manager shall evaluate lessons learned from existing and previously executed programs and projects to identify applicable lessons for use in program planning and execution.
(4) Early in program formulation, the Program Manager, in consultation with the MDAA (or MSOD), shall recommend a Technical Warrant Holder (TWH). The NASA Chief Engineer selects the TWH.
2.2.2.b Create a program organizational and financial structure.
(1) The Program Manager shall build a program organizational structure that assigns clear lines of responsibility, authority, and accountability to specific Centers, Project Managers, partners, advisory groups, and oversight boards.
(2) Working in close cooperation with the OCFO, the Program Manager shall be responsible for creating financial management structures that comply with budget and accounting standards established by that Office.
2.2.2.c Develop a program technical approach.
(1) As applicable, the Program Manager shall identify scientific and engineering research and development strategies, develop constituent project (systems and operations) concepts, acquisition strategies, technology strategies, commercialization plans, agreements (e.g., space operations service agreements, launch services agreements, safety and mission assurance agreements) and logistics concepts, and incorporate them into the Program Plan. The most important aspect of this formulation activity is conducting a thorough analysis of alternatives (AoA), relying on architecture frameworks, program-level systems engineering, design reference mission analysis, and other formal techniques.
(2) The Program Manager shall establish the program's methods for advanced technology insertion and validation, safety and mission assurance, environmental impact assessment, records and data management and distribution, physical and information security and program protection, and risk management, and incorporate them into the Program Plan.
(3) The Program Manager shall incorporate the security considerations in NIST Special Publication 800-64, "Security Considerations in the Information System Development Life Cycle" in the lifecycle of all Information Technology related Programs.
2.2.2.d Develop a continuous risk management process
(1) The Program Manager shall develop and implement a continuous risk management process (that includes integrated risk management planning for all risks associated with program safety, cost, schedule, and technical performance), and document it in a program Risk Management Plan.
(i) The Program Manager shall begin the process with risk identification and an assessment of program constraints, which defines the acceptable risks. Areas of potential program risks include, but are not limited to: mission success criteria; development schedule; budget limits; launch window and vehicle availability; international partner participation; critical single source suppliers; security; environmental concerns; human space flight safety issues; fail ops/fail safe requirements; safe and reliable operations; and the amount and type of testing.
(ii) The Program Manager shall follow the NASA Continuous Risk Management (CRM) Process, shown as Figure 2-1 and Figure 3-2 in Chapter 3.
(iii) The program Risk Management Plan shall describe periodic risk reviews, system safety, quantitative risk assessments, operations risk management, risk-based acquisition management, and information management systems for problem reporting, surveillance reporting, supportability data and trends analyses
(2) All risks shall be documented and communicated throughout the program life cycle.
(3) The results of the risk management process shall be incorporated into the final technical products.
2.2.2.e Develop a closed-loop problem tracking process that includes problem or anomaly reporting, problem analysis, and corrective action.
(1) The Program Manager shall develop a protocol to review past performance to determine the incidence of identical or related anomalies.
(2) The Program Manager shall develop an escalation procedure (to inform higher levels of management) based on mission criticality.
(3) The Program Manager shall develop a closeout process for root cause determination, anomaly mitigation, and recurrence control.
(4) The Program Manager shall evaluate and disposition Government-Industry Data Exchange Program (GIDEP) Alerts, Safe-Alerts, Problem Advisories, Agency Action Notices and NASA Advisories, and shall exchange significant problem and nonconforming item data with other activities and with GIDEP.
2.2.2.f Present the Program Plan for approval by the MDAA (or MSOD).
(1) Prior to the program Non-Advocate Review (NAR), the Program Manager shall secure Program Plan concurrence by the cognizant MDAA (or MSOD) and from those Center Directors committing support to the program.
(2) For single-project programs, the Program Manager shall either prepare both a Program Plan and a Project Plan, or integrate key elements of the Program Plan with all required elements of the Project Plan. The resultant Program Plan should fully meet the requirements described for both the program and project plans, including adequate linkage to the Agency Vision, goals, and objectives.
(i) For the purposes of compliance with this document, formulation and implementation activities for single-project programs shall follow the requirements outlined for projects.
(ii) A Formulation Authorization Document (FAD) and a Program Commitment Agreement (PCA) shall be required for a single-project program.
2.2.2.g Support the Mission Directorate or the (Mission Support Office) in the preparation of a Program Commitment Agreement, based on the content of the Program Plan.
2.3 Program Approval
2.3.4 Requirements: In support of Agency PMC decision review meetings during program approval:
2.3.4.a The Program Manager shall support evaluation by IPAO in accordance with the program evaluation process. (See paragraph 2.5.8 for more detailed requirements.)
2.3.4.b The Program Manager shall prepare a program readiness overview briefing for presentation at the Agency PMC milestone decision review meeting that includes a summary of the program, the status of program documentation and products, concurrence of the TWH on technical requirements (including all variances), and significant risks, all appropriate to the level of program maturity.
2.3.4.c The Program Manager shall prepare (and/or submit) the program documents and products described in Table 2-2. For programs that have a preliminary NAR, an updated FAD is not needed for the NAR.
2.3.4.d At that meeting, the IPAO results and findings, including an Independent Cost Analysis (ICA), are also presented. The Program Manager shall then follow with a presentation of responses to the IPAO findings.
2.4 Program Implementation
2.4.2 Program Control
2.4.2.2 Requirements: During implementation, the Program Manager shall:
2.4.2.2.a Have a signed PCA before conducting activities associated with program or program element (project or portfolio) implementation.
2.4.2.2.b Demonstrate a comprehensive program control function.
(1) The program control function shall operate to ensure that cost, schedule, safety, and performance commitments made at the program and project levels are demonstrable in terms of agreed-upon metrics.
(2) The Program Manager shall focus attention on assuring that projects are operating within the framework of the approved Program Plan.
(3) The Program Manager shall monitor any program element reserves held at the program level and distribute them, as needed, to meet program goals and objectives.
2.4.2.2.c Prepare and maintain detailed budgets, work authorizations, plans, and schedules.
(1) The Program Manager shall provide a copy of the signed PCA to the OCE and OCFO.
(2) The Program Manager shall support the Mission Directorate (or Mission Support Office) in updating the PCA through a revision when new content is added to the program (e.g., the creation of a new project); the revision shall be noted in the PCA change log.
(3) The Program Manager shall evaluate the need for modifications of the Program Plan and the PCA due to changes in projects and activities within the program. Programs are usually long-lived constructs and should not require extensive modification during implementation. However, external funding changes or strategic shifts within the Agency can generate modifications to the PCA. Specifically, for ongoing programs:
(i) The Program Manager shall support the Mission Directorate (or Mission Support Office) in updating the PCA through a modification when budget changes greater than 20 percent (20%) in a given year, or ten percent (10%) within a five-year horizon, occur.
(ii) The Program Manager shall support the Mission Directorate or (Mission Support Office) in preparing the PCA modifications and documenting them in the PCA change log. The Mission Directorate will approve the modifications and take the modified PCA to the Agency PMC for an approval recommendation to the Deputy Administrator.
(iii) The Program Manager shall support the Mission Directorate (or Mission Support Office) in preparing a briefing for the Agency PMC that describes factors driving the modification and shall support the briefing if requested. When the Deputy Administrator signs the modified PCA, the program modification is approved.
(4) Budget data shall reflect, at all times, the full cost of implementing all aspects of the program. (For more information on full cost and practices, see Volume 7 of the NASA Financial Management Requirements.)
(5) The Program Manager shall prepare and maintain a detailed schedule of program milestones and major planned events. Program Managers are encouraged to identify alternative development paths in order maximize the probability of success.
(6) The Program Manager shall review and approve constituent Project Plans.
2.4.2.2.d Oversee acquisition efforts.
(1) The Program Manager shall ensure that all acquisition efforts and other transactions are implemented in accordance with Federal law and regulations (including the FAR or OMB Circulars, as applicable), and the NASA FAR Supplement, NASA directives, and the Program Plan.
(2) The Program Manager shall ensure that standards and requirements flow down to external parties (i.e., contractors, grantees, and non-NASA parties to Space Act and other agreements and non-procurement instruments).
2.4.2.2.e Conduct an integrated continuum of reviews. The Program Manager shall conduct the internal program reviews during implementation as specified in the Program Plan.
2.4.2.2.f Disposition all risks before delivery to operations (or the equivalent for a technology program).
2.4.2.2.g Support the Mission Directorate (or MSO) in preparing material for Quarterly Status Reviews (QSRs) to the Agency PMC.
2.4.2.2.h Periodically evaluate the performance of Project Managers and their teams.
2.4.3 Program Advocacy
2.4.3.2 Requirements: During implementation, the Program Manager shall:
2.4.3.2.a Advocate and promote customer involvement in the implementation of the program to assess progress against commitments.
2.4.3.2.b Produce and execute a plan for education and public outreach by working with Mission Directorate education leads and the NASA Office of Education.
2.4.4 Program Integration
2.4.4.2 Requirements: During implementation, the Program Manager shall:
2.4.4.2.a Maintain the continuity of requirements by ensuring that requirements are fully traceable from Agency vision and goals down through program requirements and top-level project requirements.
2.4.4.2.b Ensure that the program is being implemented in a cost-effective manner by continuing to conduct architecture trades, technology assessments, mission analyses, and infrastructure and operational analyses that help structure program-level investments for maximum return.
2.4.4.2.c Ensure that all investment areas (product lines) associated with the program are being managed in an integrated manner so that changes in one program investment area are reflected in all other related investment areas.
2.4.4.2.d Ensure that all cross-cutting management elements of the program (e.g., safety, technology strategy, risk management) are being implemented in constituent projects in accordance with the Program Plan.
2.4.4.2.e Identify and secure facilities, infrastructure, equipment (including GFE), materials, supporting personnel, and services that are required to support multiple projects within the program.
(1) The Program Manager shall negotiate agreements with support providers, as needed.
(2) For those products requiring transfer of custodial responsibility, the Program Manager shall ensure that acceptance/turnover activities, licensing, and documentation are addressed.
(3) The Program Manager shall ensure that Project Plans account for the disposition of assets (orbital and other) after the end of their useful life
(4) The Program Manager shall manage all salvageable assets (e.g., spares) remaining at the end of a constituent project's life cycle.
2.5 Program Evaluation
2.5.8 Requirements: To accomplish the on-going program evaluation process, the Program Manager shall:
2.5.8.a Plan program team and schedule resources to support Independent Assessment (IA) for all required program decision reviews and Program Implementation Reviews (PIRs) (nominally every two years after the NAR approval ). For initial planning purposes, the Program Manager should consult Table H-2 in Appendix H. The program's planning schedule may be modified through negotiation with the IPAO.
2.5.8.b Comply with the evaluation Terms of Reference (ToR) for all independent reviews.
(1) The ToR is prepared by the IPAO through negotiation with the MD (or MSO) point-of-contact. The ToR is approved by the OCE and the MDAA (or MSOD). The ToR specifies the details of conducting site field review events, including the schedule, deliverable items and areas of program risk. If the MD (or MSO) point-of-contact and the IPAO cannot agree on the ToR scope and content, the OCE shall be the final decision authority.
(2) The final schedule shall be documented in the evaluation Terms of Reference (ToR).
2.5.8.c Prepare program briefings and material demonstrating the program's readiness to continue, and present them at the IPAO site field review. These briefings shall include a program cost estimate. (PIRs are designed to measure program performance and compare that performance against the Program Plan. Consequently, the biennial PIR focuses on program activities and generally does not delve into project operations. The Program Manager should, however, plan for some level of project-level analysis in order to assess the delivery of products and services according to the agreed-upon metrics in the Program Plan.) The Program Manager should consult Table H-1 in Appendix H for other assessment criteria.
2.5.8.d Review facts, assumptions, and findings of the initial IPAO briefing, and provide a formal response to the IPAO.
2.5.8.e Comply with external requests for evaluation and audit (e.g., the Congress, OMB, the NASA Inspector General, GAO, etc.).
2.5.8.f Support any additional independent reviews or technical assessments that may be required during formulation and implementation as directed by the Administrator, Agency PMC, MDAA, MSOD, the OCE (including the NESC), or the Office of Safety and Mission Assurance. The Program Manager shall provide formal responses to action items/recommendations from these reviews for closure.
2.5.8.g Ensure that program engineering data related to failures, anomalies, evaluations, problems, incidents, and Requests for Action (RFAs) are captured, retained, and made available to the TWH and NESC upon request.
2.5.8.h Provide support for a Safety and Mission Assurance Readiness Review (SMARR) prior to any launch or safety critical event or other activity selected by the Chief SMA Officer.
3 CHAPTER 3. Common Project Management Requirements
3.1 Four-Part Project Management Process
3.1.b This chapter delineates the common requirements for the management of projects, described in terms of the four-part management process of paragraph 1.7.1. The requirements of the chapter apply specifically to projects identified in Program Plans. It is recognized that these projects contain lower-level project activities managed by designated responsible organizations. The cognizant Mission Directorates, Mission Support Offices, programs, projects, or Centers shall flow down the requirements of this document. The Project Manager should also review all Mission Directorate, Mission Support Office, program, and Center-level documents that might include requirements beyond those in this document.
3.1.c Managers of projects identified in a Program Plan shall meet all requirements outlined in this chapter irrespective of the size of the project and the program of which it is an element. Requests for deviations or waivers to NPR 7120.5C requirements shall be documented and submitted for approval to the Center Director, the Program Manager, Mission Directorate (or Mission Support Office), and the appropriate GPMC. The Project Manager should receive written authorization from the Office of Security and Program Protection for waiver of activities related to security. Prior to the NAR, these requests shall be documented in the NPR 7120.5C compliance matrix attached to a single deviation or waiver to assure proper routing and control. Deviations or waivers impacting formulation or requiring long lead-time shall be submitted individually early in formulation. Following the NAR, deviations or waivers shall be submitted individually to the approving authority described above. The compliance matrix, with approved deviations and waivers, shall be included as an appendix to the Project Plan.
3.1.d Project IT investments shall be separately planned for, evaluated in terms of Return on Investment (ROI), budgeted, and managed. Refer to Chapter 7 for requirements related to IT investments made by all projects, regardless of type.
3.2 Project Formulation
3.2.1 Project Planning
3.2.1.2 Requirements: The Project Manager and the project team shall:
3.2.1.2.a Prepare the Project Plan.
(1) At a minimum, the Project Plan shall contain all elements of the template provided in Appendix D. If the Project Manager chooses to write separate plans for some elements of the template, then the Project Plan shall summarize the salient points of the separate plans.
(2) Sections of the Project Plan that are replaced by alternative approaches through an approved waiver or deviation shall be clearly identified in the Project Plan.
(3) The Project Manager shall have the initial version of the Project Plan completed and ready for review by the Program Manager within the relevant milestone in the Appendix G.
(4) The Project Manager shall secure approval of the Project Plan within the relevant milestone as identified in Appendix G. As a minimum, the cognizant Center Director and the Program Manager shall sign the Project Plan.
(5) The Project Manager shall evaluate lessons learned from existing and previously executed projects to identify applicable lessons for use in project planning and execution.
3.2.1.2.b Define a Work Breakdown Structure (WBS).
(1) The WBS for the project shall encompass all the work required in the project, including both in-house and contractor efforts, over the project life cycle.
(2) The WBS for the project shall be based on the appropriate product line template.
(3) The WBS shall have a companion WBS dictionary that narratively describes the overall structure and content of each individual element of the WBS, and a WBS index linked to reference individual elements to the dictionary.
3.2.1.2.c Prepare a project Integrated Master Schedule (IMS) as part of the Project Baseline.
(1) The project IMS shall show all tasks necessary to accomplish the total scope of work derived from authorizing documents (e.g., FAD, PCA, Program Plan, Contract) and defined in the approved project WBS.
(i) Activity durations shall identify the realistic number of work periods required to accomplish each activity in the IMS.
(ii) Resource requirements, capacity, and availability shall be considered.
(iii) Schedule reserve, based on risks and historical norms, shall be clearly identified.
(2) The project IMS shall show all critical project milestones, logical relationships (interdependencies) for all tasks and milestones, and to include critical paths, when required based on both project category and product line type. (See product line chapters).
(3) The project IMS shall have traceability to both lower-level detailed schedules and higher-level management summary schedules controlled by the approval authority (e.g., Program Manager, MDAA).
3.2.1.2.d Create a team structure designed to assure mission success.
(1) The Project Manager shall develop a team organization compatible with the WBS and the implementation strategies selected for the project. The project's organizational structure shall be documented in the Project Plan, Part 1, Project Management.
(2) Project teams can be composed of civil service personnel, contractors, academia, partners, and customers. It is important that project teams have full and open communication. Clear lines of authority and communication must be demonstrated in the project organization chart. Therefore:
(i) The Project Manager shall develop a project Communications Plan so as to foster effective (upward and downward) communication of critical management, technical, risk, and safety information.
(ii) The Communications Plan shall specifically define the relationships among various project elements, and unambiguously identify responsibilities for problem reporting and subsequent decision making, during normal and contingency events.
(iii) The Communications Plan shall define relationships and interactions with all stakeholders, team members, and supporting organizations.
(iv) The Project Manager shall develop a plan to meet the program requirements for a closed loop problem tracking process, described in paragraph 2.2.2.e.
(3) The balance of required skills, experience, and the size of the team will likely change through the project life cycle. Therefore, the Project Manager shall develop staffing plans consistent with the needs of the project over its life cycle, staff with personnel with the appropriate skills, abilities, and experience, and provide integrated team training to successfully execute the project.
(4) The Project Manager shall negotiate required resources with applicable service pool managers.
(5) In their supervisory capacity, Project Managers shall provide for the individual development of personnel that report directly to them. In addition, Project Managers should collaborate with line managers on the individual development needs of other members of the team. Project Managers should identify meritorious performance and create a strategy for using the NASA Awards and Recognition program to acknowledge successful, high-performing individuals and teams. Project Managers should take quick action to remedy unsatisfactory performance, whether through provision of additional guidance or training, or if necessary, changes in personnel.
3.2.1.2.e Examine and manage requirements for advanced technology.
(1) The Project Manager shall analyze technology requirements for feasibility, availability, technology readiness, and opportunities for leveraging ongoing research. Specifically,
(i) The Project Manager shall evaluate sources of technology from other NASA Centers. One resource for accomplishing this is the NASA Technology Inventory Database at http://inventory.gsfc.nasa.gov.
(ii) The Project Manager shall also identify commercial, academic, and other government agency sources of technology.
(iii) Full cost assessments and risk assessments shall be performed to identify preferred sources of technology.
(2) The Project Manager shall develop an integrated technology strategy to enable the project to meet its mission objectives. This strategy shall be documented in the Project Plan, Part 3, Technology Strategy:
(i) The Technology Plan shall describe how the project will remove remaining technology gaps, including maturation, validation, and insertion plans, quantifiable milestones, decision gates, and resources required.
(ii) Sources of technology shall be clearly identified in the Technology Plan.
(iii) Distribution restrictions on the software, hardware, or data shall be clearly identified in the Technology Plan.
(3) The Project Manager shall work with Center legal and commercialization personnel to establish how project-developed intellectual property (technologies, discoveries, innovations, tools, processes, or software) can be licensed or appropriately transferred to U.S. industry in other ways.
(4) The Project Manager shall ensure that all planned technology exchanges, contracts, and partnership agreements comply with all laws and regulations regarding export control and the transfer of sensitive and proprietary information.
3.2.1.2.f Analyze project infrastructure needs.
(1) Working with the real property and industrial property offices, the Project Manager shall ensure that a comprehensive analysis of project infrastructure (real property/facilities, aircraft, personal property, and information technology IT) needs is performed. This analysis should include infrastructure required for: staff office space, test (including ground and flight facilities) and integration functions, research facilities, data systems, logistics and maintenance facilities, aircraft, and personal property and equipment.
(2) The Project Manager, in coordination with the cognizant Center functional office, shall assess existing Agency-wide capabilities to meet infrastructure needs, and also assess whether facilities in other Government agencies, industry, academia, and international organizations can be utilized to reduce project LCC and risk. The Project Manager should work with the Program Manager, the MDAA, OCE, CIO, the Office of Infrastructure, Management, and Headquarters Operations, and other Headquarters offices to identify means of meeting infrastructure requirements through synergy with other programs and projects, thus avoiding costly duplication of supporting infrastructure.
(3) A business case justification shall be performed for any proposed acquisition or major modification of infrastructure (e.g., facilities, IT).
(i) The business case shall include full life cycle cost (including operations, sustainment, and disposal), benefit estimates, alternatives and sensitivity analyses, and risk assessments. (For more information on full cost and practices, see Volume 7 of the NASA Financial Management Requirements.)
(ii) The business case shall be approved by the cognizant MDAA (or MSOD) who will coordinate with the NASA Headquarters functional office, or its designee(s).
(4) First in coordination with the cognizant Center functional office, and then with the Headquarters Office of Infrastructure, Management, and Headquarters Operations, and/or the CIO, as appropriate, the Project Manager shall develop plans for any necessary upgrades or new developments, including those needed for environmental compliance (see paragraph 3.2.1.2j), and then document them in the Project Plan, Part 2, Resources.
(5) The Project Manager shall comply with the provisions of NPD 7900.4 and NPR 7900.3, Aircraft Management Operations, before entering into agreements to procure or operate aircraft that might be necessary to the success of the project. The Project Manager shall directly coordinate with Center Chief of Flight Operations or the Headquarters Aircraft Management Office during the planning stage.
(6) The Project Manager shall work with the respective offices at NASA Headquarters and Centers to assure that requisite spectrum allocations and airspace access are available, and if not, to obtain the necessary approval and permits.
(7) The Project Manager shall comply with the provisions of current space transportation laws and policies, and NPD 8610.7, Launch Services Risk Mitigation Policy for NASA-Owned or NASA-Sponsored Payloads, and NPD 8610.12, Office of Space Operations (OSO) Space Transportation Services for NASA and NASA-Sponsored Payloads, involving launch assignment and acquisition before entering into agreements to procure launch services or launch vehicles. The Project Manager shall directly coordination with Space Operations Mission Directorate (SOMD) during planning and formulation for any project requiring launch.
3.2.1.2.g Manage agreements.
(1) Any use of interagency, industry, academic, and/or international cooperation agreements needs to be addressed early in project formulation. When these agreements are considered for a project, the Project Manager shall work with the appropriate Headquarters offices, and where necessary, have the agreements approved by them. All activities and documentation should be consistent with policy guidelines and with program, Mission Directorate (or Mission Support Office), and Agency-level agreements.
(2) All agreements, memoranda of understanding, barters, in-kind contributions, and other arrangements for collaborative and/or cooperative relationships shall be identified in the Project Plan, Part 3, Cooperation and Commercialization, and the Project Manager shall maintain signed copies of all such agreements.
3.2.1.2.h Complete an Acquisition Plan.
(1) The Project Manager shall develop an integrated acquisition strategy that enables the project to meet its mission objectives, provides best value to NASA, and complies with the FAR and the NASA FAR Supplement. The Project Manager shall ensure that applicable laws, regulations, requirements, and standards are flowed down from NASA to the prime and sub-contractors. This strategy shall be documented in the Project Plan, Part 2, Acquisition Management.
(i) The Acquisition Plan shall identify all major proposed acquisitions in relation to the project WBS.
(ii) The Acquisition Plan shall consider the utilization of NASA in-house capabilities and the maintenance of NASA's core competencies when making make or buy decisions.
(iii) The Acquisition Plan shall identify the project's approach to creating contractor incentives that strengthen safety and mission assurance.
(iv) The Acquisition Plan shall identify significant ($1 million or more) equipment requirements expected to be acquired or fabricated by contractors in support of the project objectives.
2) If systems contain software, the Project Manager shall ensure that software developed internally within NASA or acquired complies with NPR 7150.2, NASA Software Engineering Requirements, and NASA Standard 8739.8, Software Assurance Standard.
(3) The Acquisition Plan shall establish a continuous Risk-Based Acquisition Management (RBAM) process:
(i) The project acquisition planning team shall obtain input from Center personnel responsible for safety and mission assurance, health, environmental protection, information technology, export control, and security. The goal of this involvement is to ensure that the acquisition is structured to address appropriately the concerns of these disciplines as they relate to the requirement. (See NFS 1807.104.)
(ii) During the solicitation process, any exchanges with industry prior to receipt of offers should include requests for any perceived safety, occupational health, security (including information technology), environmental, export control, and/or other programmatic risk issues associated with performance of the work. Similarly, when technical proposals are required as part of requests for proposals for supplies or services, offerors shall be instructed to identify and discuss risk factors and their approach for managing those risk factors (see NFS 1815.201 and NFS 1815.203-72). Where the solicitation requires submission of a Safety and Health Plan (see NFS 1823.7001(c)), safety and health shall be a consideration in the evaluation process (also see NFS 1815.305).
(iii) Quality assurance surveillance plans shall be prepared with the statement of work for all performance-based contracts and, as necessary, for other contracts. The Project Manager shall follow NPR 8735.2, Management of Government Safety and Mission Assurance Surveillance Functions for NASA Contracts.
(iv) Working with SMA, the Project Manager shall ensure that the plans reflect NASA's surveillance approach relative to the perceived programmatic risk. The plans are general at the outset, but after contract award, the Contracting Officer shall ensure that the plans are revised to reflect the risks associated with the successful proposal (see NFS 1846.401 and Procurement Information Circular 02-17).
(4) The Acquisition Plan shall be reviewed and approved by the Program Manager prior to initiating any major procurement actions, as established in Section 3.2.4.
3.2.1.2.i Complete a Safety and Mission Success Plan.
(1) The Project Manager shall complete a Safety and Mission Success Plan and ensure close integration with the appropriate Safety and Mission Assurance (SMA) organization. The resulting plan can be incorporated into the Project Plan, Part 3, Safety and Mission Assurance.
(2) The Project Manager shall perform activities to provide for the early identification, analysis,reduction, and/or elimination of hazards that might cause the following:
(i) Loss of life or injury/illness to personnel;
(ii) Damage to or loss of equipment or property (including software);
(iii) Unexpected or collateral damage as a result of test;
(iv) Failure of mission;
(v) Loss of system availability; and/or
(vi) Damage to the environment.
(3) Project Managers shall establish safety and mission success activities as a part of the continuous risk management process early in the project formulation process. Specifically, the Project Manager shall:
(i) Incorporate health and safety principles in all planning.
(ii) Perform formal assessment and documentation of each hazard.
(iii) Control each hazard in accordance with the reduction protocol in NPR 8715.3, NASA Safety Manual.
(iv) Perform a safety assessment or readiness for flight or other operations, explicitly noting any exceptions arising from safety issues and concerns.
(v) Utilize a quality management system in compliance with NPD 1280.1, NASA Management Systems, and with appropriate supplier assessment and surveillance.
(vi) Provide a reliability, maintainability, and parts assurance program appropriate to the needs of the project.
(4) Each project that uses radioactive materials must have an internal NASA process in place for effective intra-Agency and interagency coordination in obtaining launch approval. Therefore:
(i) Each project shall ensure that system designs that use radioactive materials reduce public and worker exposure to radiation and radioactive materials to levels that are as low as reasonably achievable.
(ii) Radiological contingency plans, commensurate with the potential health risk to the public, shall be developed for missions carrying radioactive materials in accordance with NPD 1820.1, NASA Environmental Health Program, and NPR 8715.3, NASA Safety Manual.
(iii) Each project proposing to launch radioactive materials shall fully adhere to the NASA and Executive branch interagency coordination processes for nuclear launch safety approval in accordance with NPD 1820.1, NASA Environmental Health Program, and NPR 8715.3, NASA Safety Manual.
(iv) The Project Manager shall support the NASA Headquarters Office of Safety and Mission Assurance (OSMA) and the Office of Security and Program Protection in obtaining nuclear launch safety approval.
3.2.1.2.j Complete the Education and Public Outreach Plan. The Project Manager shall develop a plan that document linkages between science, engineering, technology, and mathematics (STEM), and the unique project content. Specifically, the plan shall incorporate elements that:
(1) Demonstrate a compelling benefit to the public.
(2) Show how each project demonstrates contributions to developing a pipeline promoting STEM careers and/or cultivating a workforce in science and technology.(3) Are designed to respond to a need identified by the education community, a customer, or a customer group (customer focus).(4) Demonstrate the connection to NASA missions and other activities that inspire and motivate the Nation's students and teachers, to educate the public, and to advance scientific and technological capabilities of the Nation.
3.2.1.2.k Complete the Environmental Management Plan.
(1) With the support of the cognizant Environmental Management Office (EMO), and in accordance with NPR 8580.1, Implementing the National Environmental Policy Act and Executive Order 12114, the Project Manager shall complete the Environmental Management Plan and incorporate it into the Project Plan, Part 3, Environmental Management.
(i) The development of the Environmental Management Plan shall be integrated with the installation Environmental Management System so as to ensure appropriate approvals, permits, and consultations are made, and mission delay impacts are avoided or minimized.
(ii) The Project Manager shall integrate public, intergovernmental, and interagency involvement with the Education and Public Outreach Plan.
(2) Environmental planning needs to be integrated into project planning efforts early in formulation, as environmental protection compliance processes can be lengthy. These efforts are accomplished with the support of the cognizant EMO. Specifically:
(i) The Project Manager shall support the Mission Directorate (or Mission Support Office) to ensure the completion of the NEPA process prior to taking any action which would either (1) have an adverse environmental impact; or (2) limit the choice of reasonable alternatives. In all cases, the Project Manager shall ensure the NEPA process, as explained in NPR 8580.1, Implementing the NEPA and Executive Order 12114, is completed prior to project implementation. The Project Manager should allow 6 to 18 months on average to complete the required NEPA documentation.
(ii) The project schedule shall include specific milestones for the completion of other documentation required by nuclear launch safety, and other pertinent NASA regulations, environmental statutes and regulations, and Executive Orders.
(iii) This documentation shall include an orbital debris assessment, if applicable.
(iv) The Project Manager shall, with the EMO, ensure that all required permits, waivers, documents, approvals or concurrences are obtained to ensure compliance with all applicable Federal, State, Tribal government, and local environmental regulations.
(3) The Project Manager shall comply with the applicable provisions of directives implementing NASA's planetary protection policy in NPD 8020.7, Biological Contamination Control for Outbound and inbound Planetary Spacecraft, and NPR 8020.12, Planetary Protection Provisions for Robotic Extraterrestrial Missions.
3.2.1.2.l Ensure the security of personnel and physical resources under the control of the project.
(1) The Project Manager shall work with the Chief of Center Security to identify and control threats to personnel, monitor the level of security-cleared personnel, and employ access control devices and other safeguards.
(2) The Project Manager shall employ the recommendations of the Chiefs of Center Security that address physical security and loss-prevention measures within program and project facilities.
(3) The Project Manager shall ensure that emergency response, mitigation, and recovery plans have been established for the project, in accordance with NPD 8710.1, Emergency Preparedness Program. These plans should be coordinated with the local Emergency Preparedness Office.
(4) Each project shall complete preparations and ensure that response capabilities (to include restoration of program-unique resources and capabilities) are available when needed.
(5) Each project shall ensure that contingency plans are in place to properly secure a mishap site, impound evidence, and provide necessary notification within the program and to designated Agency notification contacts.
3.2.1.2.m Provide for information technology security.
(1) The Project Manager shall take actions (appropriate to the level of sensitivity) to protect the integrity, availability, and confidentiality of project information systems, software applications, data, and information generated within their projects. This includes classified or sensitive information, export-controlled information, industry proprietary data, command, control and communications (C3) information and systems, websites, applications, and information and systems that support NASA's daily business activities (e.g., e-mail management reporting).
(2) Project technical requirements shall include information technology security requirements, in accordance with NPR 1620.1, Security Procedures and Guidelines, NPR 2810.1, Security of Information Technology, and NASA Information Technology Requirements (NITR). Specifically, the Project Manager shall:
(i) Conduct risk assessments, determine and implement risk-mitigating technologies or procedures, and manage residual accepted risks.
(ii) Coordinate project security measures with established Center and Headquarters Boards governing NASA-wide infrastructure security measures.
(iii) Address specific requirements for security of C3 systems and those systems containing or processing export controlled, proprietary, classified or other sensitive information.
(iv) Address requirements for affording or limiting access by citizens of foreign countries involved in the project.
3.2.1.2.n Provide for export control and foreign involvement.
(1) The Project Manager shall comply with the requirements of NPR 2190.1, NASA Export Control Program.
(2) All NASA international agreements contain a clause on transfers of controlled hardware, software technology, and data both from NASA to foreign partners and from foreign partners to NASA. The Project Manager shall comply with the clause when transfers are made from NASA to a partner or a contractor of a foreign country.
(3) The Project Manager shall transfer only technical data, hardware, and software necessary to fulfill NASA responsibilities under international agreements. Specifically:
(i) If foreign contracts are anticipated, the Project Manager shall assure that there is appropriate Headquarters review when required, and that such contracts are prepared with appropriate export control provisions.
(ii) Applicable contracts with U.S. industry that support an international project shall also include appropriate provisions related to export control requirements.
(4) Export control requirements and milestones shall be included in project plans.
(5) When foreign nationals are involved, the Project Manager shall plan for internal technology transfer controls.
(6) The Project Manager shall identify export license requirements and shall obtain any required export licenses prior to exporting.
(7) As applicable, the Project Manager shall instruct contractors and partners of NASA obligations under international agreements, and of their responsibility for obtaining proper authority for any contractor and partner exports.
(8) The Project Manager shall advise foreign partners of the sensitive nature of export controlled hardware, software, and data prior to transfer.
3.2.2 Cost Estimation
3.2.2.2 Requirements: The Project Manager and the project team shall:
3.2.2.2.a Develop an initial Life Cycle Cost Estimate (LCCE).
(1) The Project Manager shall develop an initial LCCE consistent with the project WBS, schedule, and performance parameters to form the project estimate (to be included in the initial Project Plan, Part 2, Resources.)
(i) All cost and workforce estimates shall be summarized according to the NASA standard product line WBS and time phased by Government Fiscal Year (GFY).
(ii) The project estimate shall always use the latest available full cost accounting initiative guidance and practices.
(2) The project estimate shall include reserves, along with the level of confidence provided by the reserves.
(3) Upon completion of the initial LCCE, the Project Manager shall provide it to the Program Manager.
3.2.2.2.b Prior to the NAR, update the project estimate.
(1) The Project Manager shall ensure that all elements of the project LCCE are internally consistent and have been updated in time for the NAR (at which time it is designated the NAR estimate).
(2) In the event that the (Category I and II) project LCCE and ICE do not agree and cannot be reconciled, the OCFO Cost Analysis Division will provide a recommended cost position to the MDAA (or MSOD), Chief Financial Officer, and Chief Engineer, who together will make a recommendation to the Agency or Mission Directorate PMC. The Project Manager shall defer to their decision.
3.2.3 Systems Engineering
3.2.3.3 Requirements: The Project Manager and the project team shall:
3.2.3.3.a Plan systems engineering tasks.
(1) The Project Manager shall establish the project's overall systems engineering scope and approach, and document it in the Project Plan, Part 3, Systems Engineering.
(i) The Systems Engineering Plan shall comply with an Agency-approved systems engineering standard.
(ii) The Systems Engineering Plan shall describe how the standard's systems engineering processes will be instantiated by the project, including metrics, and shall identify any deviations and waivers from the standard.
(2) The Project Manager shall identify and plan a series of cost-performance trade studies.
(i) These trade studies shall, as a minimum, consider safety, performance, life cycle costs, project risks, technology alternatives, schedule, environmental concerns, operations and logistics, and infrastructure issues.
(ii) In performing these trade studies, the Project Manager shall evaluate the advantages and risks of securing elements of the project from outside sources including partnerships and co-ventures with other government agencies, academia, industry, and foreign organizations.
(3) The Project Manager shall plan software engineering tasks per NPR 7150.2, Software Engineering Requirements and NASA Standard 8739.8, Software Assurance Standard.
3.2.3.3.b Define, validate, and manage project requirements. The Project Manager and project team shall flow down program requirements to define a validated set of high-level project requirements prior to entering implementation.
3.2.3.3.c Perform system analyses. The Project Manager and project team shall complete planned cost-performance trades, such as Analysis of Alternatives (AoA) studies, Cost as An Independent Variable (CAIV) assessments, mission success probability assessment, and other systems analyses. (Reference L.2.a(8) provides useful detailed information on planning and conducting a formal AoA.)
(1) Early in formulation, and in cooperation with the customer, the Project Manager shall define key performance parameters (KPPs) for the project that are selected on the basis of their close relationship with mission success criteria. These KPPs should appear in trade studies as measures of effectiveness and/or measures of performance.
(2) As a result of these studies and analyses, but prior to the end of formulation, the Project Manager shall specify quantitative values (a goal value and a threshold value) for each KPP, which will then be incorporated into the Project Baseline (along with the related mission success criteria, schedule, and LCCE) and which will be used to evaluate project performance. For each KPP, the goal is the performance level that the project team is striving for, and the threshold is the minimum performance level that the MDAA (or MSOD) and Program Manager agree is acceptable for the system-of-interest or end item deliverable.
(3) As a result of these studies and analyses, the Project Manager shall also establish a close link between each KPP and project technical performance requirements.
(4) The Project Manager shall provide the final quantitative values of each KPP to the independent assessment (IA) organization as part of the NAR Baseline.
3.2.3.3.d Define a preferred system design. The Project Manager and project team shall collect and allocate project requirements into an implementable architecture. This activity typically leads to a preliminary design of the system(s) to be developed.
3.2.3.3.e Plan verification and validation efforts. The Project Manager and the project team shall complete the Verification and Validation (V&V) Plan and incorporate it into the Project Plan, Part 3, Test and Verification.
(1) The V&V Plan shall clearly identify the approach to the verification of each requirement.
(2) The V&V Plan shall include software/hardware integration and appropriate independent verification and validation of software.
(3) The V&V Plan shall clearly identify the approach to system validation.
3.2.4 Independent Technical Authority
3.2.4.3 Requirements: During formulation:
3.2.4.3.a Early in project formulation, the Project Manager, in consultation with the MDAA (or MSOD), shall recommend a Technical Warrant Holder. The NASA Chief Engineer selects the Technical Warrant Holder.
3.2.4.3.b Once the high-level requirements have been defined by the Mission Directorate (or Mission Support Office), the Project Manager shall support the TWH in the establishment and maintenance of the subordinate technical requirements.
(i) The Project Manager shall defer to the TWH in determining which standards and requirements affect safe and reliable operations involving human safety.
(ii) The Project Manager shall only accept variances regarding technical standards and requirements affecting safe and reliable operations involving human safety when approved by the TWH. This does not preclude the Project Manager from requiring more extensive investigation.
3.2.4.3.c The Project Manager shall communicate unresolved conflicts with the TWH to the Program Manager, and then to the appropriate MDAA (or MSOD) if required. Likewise, the TWH reports unresolved conflicts with the Program/Project Manager to the NASA Technical Authority (NASA Chief Engineer).
3.2.5.2 Requirements: The Project Manager and the project team shall:
3.2.5.2.a Begin to execute the Project Control Plan as early as practical in formulation.
(1) The Project Manager shall review the EVM guidance provided in paragraph 3.4.3.2 to determine the appropriate application of EVM to the project.
(2) The Project Manager shall develop a Project Control Plan, and incorporate it into the Project Plan, Part 3, Project Control.
(3) The Project Manager shall ensure that all elements of the Project Control Plan are fully operational prior to the NAR.
3.2.5.2.b Establish and conduct a continuum of technical and management reviews.
(1) Reviews provide a venue for communication, coordination, and integration of project activities. The Project Manager shall develop a Project Review Plan, and incorporate it into the Project Plan, Part 3, Reviews.
(2) The Project Manager shall conduct the formulation phase internal reviews, as specified in the Project Review Plan, to ascertain the status of the project, and to provide an integrated, independent technical assessment of the project's technical risk, and its readiness to proceed to the next level of maturation.
(3) At each such review, the Project Manager shall synthesize and document engineering and management inputs, issues, and recommendations (e.g., Review Item Discrepancies, Requests for Actions).
(i) All such review inputs shall be subsequently analyzed, and recommendations/action items tracked and dispositioned.
(ii) An index of review inputs and recommendations shall be maintained, and made available at all subsequent reviews.
3.2.5.2.c Establish and implement configuration management. The Project Manager shall develop a Configuration Management Plan, and incorporate it into the Project Plan, Part 3, Configuration Management.
3.2.5.2.d Put in place a comprehensive risk management decision making process.
(1) In accordance with NPR 8000.4, Risk Management Procedures and Guidelines, the Project Manager shall establish a continuous risk management (CRM) process that identifies risks; analyzes their impact and prioritizes them; develops and carries out plans for risk mitigation or acceptance; tracks risks and the implementation of mitigation plans; supports informed, timely, and effective decisions to control risks and mitigation plans; and assures that risk information is communicated and documented. (The CRM process is shown in Figure 2-1.)
(2) The Project Manager and project team shall develop a Risk Management Plan that meets the program requirements for CRM processes as described in paragraph 2.2.2.d, and incorporate it into the Project Plan, Part 3, Risk Management.
(3) Risk identification shall involve the entire project team to assess all identifiable risks and project constraints up front. If an Independent Assessment (IA) has been performed, the project shall include the risks identified during the assessment as input.
(4) Each project shall follow the CRM process steps as shown in Figure 3-2; this process is iterated throughout the project life cycle. Specifically, the Project Manager and the project team shall:
(i) Identify. Develop the risk statements in terms of condition and consequence(s); capture the context of the risk scenario; e.g., what, when, where, how, and why. Tools such as Failure Modes and Effect Analyses (FMEA), Probabilistic Risk Assessment (PRA), and Fault Tree Analyses (FTA) can be used to identify risks. During engineering product development, risk will be identified and addressed in the final product as part of a risk management plan, in accordance with systems safety engineering practices.
(ii) Analyze. Evaluate risk probability, impact/severity, and timeframe (when action needs to be taken); classify/group with similar/related risks; and prioritize. Tools such as Probabilistic Risk Assessment (PRA) can be used to analyze risk.
(iii) Plan. Assign responsibility, determine approach (accept, mitigate, or watch); if risk will be mitigated, define mitigation level (e.g., action item list or more detailed task plan) and goal and include budget estimates.
(iv) Track. Acquire/update, compile, analyze, and organize risk data; report results; and verify and validate mitigation actions.
(v) Control. Analyze results, decide how to proceed (replan, close the risk, invoke contingency plans, continue tracking); execute the control decisions.
(vi) Communicate and document. Essential risk status is to be communicated on a regular basis to the entire project team, as well as to the GPMC. A system for documentation and tracking of risk decisions will be implemented.
(5) The Project Manager shall use the risk management process as a basis for decisions to mitigate cost, schedule, technical, environmental, security, or safety risk. Examples include, but are not limited to mission success criteria; development schedule; budget limits; launch window and vehicle availability; international partner participation; critical single-source suppliers; security or environmental concerns; human space flight safety issues; "fail ops/fail safe" requirements; facilities and infrastructure limitations; technology readiness; surveillance requirements; and amount and type of testing.
(6) For each primary risk, the project shall develop and maintain the following in accordance with the Risk Management Plan, and as appropriate, in the PCA.
(i) Description of the risk, including primary causes and contributors, actions embedded in the program/project to date to reduce or control it, and information collected for tracking purposes.
(ii) Identify primary consequences (including effects on safety, project cost, schedule, and performance), should the undesired event occur.
(iii) Estimate of the probability (qualitative or quantitative) of occurrence together with the uncertainty of the estimate. The probability of occurrence should take into account the effectiveness of any implemented risk mitigation measures.
(iv) Characterization of the risk as "acceptable" or "unacceptable" with supporting rationale.
(7) Characterization of a primary risk as "acceptable" shall be supported by the rationale, with the concurrence of the GPMC, that all reasonable mitigation options (within cost, schedule, and technical constraints) have been instituted. Moreover, the GPMC must concur that, given the risks and their impact on the probability of the project meeting its requirements, the expected value of the project is still sufficient to justify the costs of undertaking it.
3.2.5.2.e Identify project standards and practices.
(1) The Project Manager shall document the technical standards and any intended variances from NASA Preferred Standards as identified by the TWH in the Project Plan, Part 3, Standards and Practices.
(2) The Project Manager shall acquire approvals from the Technical Warrant Holder, and other authorities as appropriate, before executing any variances from mandatory NASA standards or specifications as established in Section 3.2.4.
(3) In accordance with the Standards and Practices section of the Project Plan, the Project Manager shall ensure that designs utilize the International System of Units (SI, metric measurement system), in concurrence with NPD 8010.2, Use of the SI (Metric) System of Measurement in NASA Programs.
3.3 Project Approval
3.3.3 Requirements: In support of GPMC decision review meetings during project approval:
3.3.3.a The Project Manager shall support evaluation by the IA organization in accordance with the project evaluation process. (See Section 3.5.)
3.3.3.b The Project Manager shall prepare a project readiness overview briefing for presentation at the GPMC milestone decision review meeting to include a summary of the project, the status of project documentation and products, concurrence of TWH on technical requirements (including all variances), and significant risks, all appropriate to the level of project maturity.
3.3.3.c The Project Manager shall prepare (and/or submit) the project documents and products described in Table 3-1.
3.3.3.d At that meeting, the IA results and findings, including an ICE for Category I and II projects, will also be presented. The Project Manager shall then follow with a presentation of responses to the IA findings.
3.4 Project Implementation
3.4.3.2 Requirements: The Project Manager and the project team shall:
3.4.3.2.a Execute the Project Control Plan. The intent of this requirement is to maintain close configuration control of requirements, to assess the cost, technical and schedule status of the project relative to the NAR Baseline. Therefore:
(1) EVM principles as defined by EIA-748-A shall be applied to all projects (contractor and civil service) exceeding $20M total project cost. However, the MDAA (or MSOD) can require EVM principles be applied to any project or activity.
(2) A fully validated EVM system as defined by EIA-748-A shall be applied to all projects (contractor and civil service) exceeding $50M total project cost. However, the MDAA (or MSOD) can require a fully validated EVM system be applied to any project or activity.
(3) In implementing (1) and (2) above, the Project Manager shall ensure (for all applicable procurements) the appropriate provisions and clauses are included in solicitations and contracts.
(4) For projects requiring EVM, the Project Manager shall conduct and complete Integrated Baseline Reviews (IBRs) on projects to ensure the validity of the baseline.
(i) The IBR shall be accomplished within six months after contract award or after approval of the Project Plan by the MDAA (or MSOD).
(ii) The IBR shall be accomplished within two months after definitization of significant scope changes or after budget realignment.
(5) Surveillance of contractor EVM systems is normally delegated to the Defense Contract Management Agency (DCMA) in accordance with the NASA/DCMA Memorandum of Understanding (MOU) for Earned Value Management System Acceptance/Surveillance and Earned Value Management Project Surveillance. When such surveillance is to be delegated, the Project Manager shall, in coordination with the Contracting Officer, initiate the action for the Contracting Officer to issue a letter of delegation to the responsible DCMA activity. The letter of delegation shall define the specific support, products, services, etc. to be provided by the DCMA. (See FAR Part 42.2.)
(6) Expenditures shall be accumulated according to the WBS established for the project, and in as near-real time as possible. Consistent with Continuous Cost-Risk Management (see reference L.2.a(1)), in addition to standard WBS-level performance measurement reporting, performance measurement of medium- and high-risk WBS elements identified during life cycle cost estimation shall be provided to the Project Manager through specification in the Cost Performance Report (CPR) Data Requirements Description (DRD) and/or the Project Plan.
(7) The full cost of civil service labor shall also be accumulated according to the WBS to permit later integration into full cost accounting and reporting.
(8) Use of EVM is optional in contracts with research institutes and in grants of any type. In such cases, when EVM is appropriate to the project but not to such project components, the Project Manager shall include in the Project Plan, Part 3, Control, the strategy for integrating cost and schedule aspects of those project components.
3.4.3.2.b Manage reserves.
(1) Project Managers have the authority to make decisions, allocate reserves, and modify the implementation path in response to new information. The Project Manager shall closely monitor the application of project reserves.
(2) The Project Manager shall treat all program transfers to the project during implementation, other than planned project reserve funds being held by the Program Manager, as augmentations to the Project Baseline. This includes the use of civil service labor above the staffing plan provided by the project. Such transfers may not imply an impending breach, but the Project Manager must follow paragraph 3.4.3.2e.
3.4.3.2.c Perform continuous risk management.
(1) The Project Manager and project team shall perform the five-step continuous risk management process of Figure 3-2 during implementation.
(2) The Project Manager shall ensure that all elements of the Risk Management Plan are followed.
(3) The Project Manager shall communicate risk mitigation actions taken, the effectiveness of risk mitigation activities, and residual risks to the Program Manager for QSR briefings.
(4) All risks shall be dispositioned before the transition to operations or the equivalent for an advanced technology project.
3.4.3.2.d Conduct the implementation phase reviews specified in the Project Review Plan.
(1) The Project Manager shall conduct the implementation phase internal reviews, as specified in the Project Review Plan, to ascertain the status of the project, and to provide an integrated, independent technical assessment of the project's technical risk, and its readiness to proceed to the next level of maturation.
(2) For each review, the Project Manager shall synthesize and document engineering and management inputs, issues, and recommendations (e.g., Review Item Discrepancies, Requests for Actions).
(i) All such review inputs shall be subsequently analyzed, and recommendations/action items tracked and dispositioned.
(ii) An index of review inputs and recommendations/action items shall be maintained, and made available at all subsequent reviews.
3.4.3.2.e Provide information and data regarding a breach of the NAR Baseline.
(1) The Project Manager shall monitor project performance and provide trending data to the Program Manager.
(i) For the cost metric, cost growth shall be measured after project approval using the latest project cost Estimate at Completion (EAC) against the NAR cost baseline (the approved NAR estimate). (Since the NAR estimate contains project reserves, cost growth occurs only when these reserves are exhausted.)
(ii) For the schedule metric, schedule growth shall be measured after project approval using the latest project schedule Estimate at Completion (EAC) against the NAR schedule baseline. The schedule baseline shall start from the date of project FAD approval and shall extend through project completion (considered to be end of prime mission for long-lived projects).
(iii) KPP changes shall be measured using the latest project performance against the NAR threshold values.
(2) The Project Manager shall report to the Program Manager when the results of surveillance reviews conducted by IA organizations indicate that a breach is to be expected.
(3) When projected cost or schedule performance exceeds the NAR Baseline by ten percent (10%), or a KPP breaches its threshold value, the Project Manager shall report the breach to the Program Manager and the information shall be presented to the GPMC.
(4) The Project Manager shall coordinate with the Program Manager to provide a proposed continuation or termination plan to the GPMC.
3.4.3.2.f Evaluate and coordinate actions related to changes in project scope, requirements, schedules, funding, or anticipated progress. Changes to the Project Baseline that lead to commensurate changes in the procurement requirements and deliveries shall be quickly communicated in the form of procurement change documentation.
3.4.3.2.g Maintain configuration management.
(1) The Project Manager shall ensure that baselined project documents are maintained under configuration management.
(i) The Project Manager shall maintain configuration management on all drawings, design specifications, part selections, and other means of documenting aspects of the design (e.g., close-out photographs).
(ii) Final versions of design documentation shall reflect the "as-built," "as-delivered," or "as-deployed" configuration of the system/asset.
(2) The Project Manager shall place all dimensions of the Project Baseline (cost, schedule, and KPPs) under configuration management, retaining the Project Baseline at the time of the NAR (the NAR Baseline) as the datum against which changes are measured.
3.4.3.2.h Maintain project team awareness of emergency response plans and procedures. Specifically, the Project Manager shall test those procedures at planned intervals during project implementation.
3.4.3.2.i Protect intellectual property and technology. The Project Manager shall protect contractor proprietary data provided in support of Government analyses and reviews, and maintain required non-disclosure agreements (NDAs).
3.4.4 Customer Advocacy
3.4.4.2 Requirements: The Project Manager and the project team shall:
3.4.4.2.a Maintain close customer interactions per the Project Plan. Specifically, the Project Manager shall proactively consult and involve customers in implementation activities, especially efforts that impact requirements and KPPs.
3.4.4.2.b Involve customers as an integral part of evaluating progress against commitments.
3.4.5 Systems Engineering
3.4.5.2 Requirements: The Project Manager and project team shall:
3.4.5.2.a Define, validate, and manage project requirements.
(1) Throughout implementation, the Project Manager shall maintain a well-documented hierarchy of validated project requirements.
(2) The Project Manager shall ensure that the hierarchy of requirements and the resulting end-item specifications, including those for software, GFE, and operations, are maintained under configuration management, and that modifications to requirements are recorded in a change log as part of overall project configuration management mechanisms.
(3) The Project Manager shall evaluate changes in requirements that impact safety, quality, cost, schedule, and performance, and incorporate the impacts as changes to the Project Baseline.
3.4.5.2.b Manage technical resource margins (e.g., mass, volume, power). The Project Manager shall manage all technical resource margins and apply project-level technical reserves as needed during design maturation.
3.4.5.2.c Implement the closed loop problem tracking process developed during formulation. (See paragraph 3.2.1.2.d(2)(iv).)
3.4.5.2.d Comply with the Standards and Practices section of the Project Plan.
(1) The Project Manager shall ensure that standards and practices identified in the Project Plan are implemented.
(2) The Project Manager shall acquire approvals from the Technical Warrant Holder, and other authorities as appropriate, before executing any variances from mandatory NASA standards or specifications as established in Section 3.2.4.
3.4.5.2.e Complete verification and validation (V&V) activities.
(1) The Project Manager shall implement the V&V strategy outlined in the V&V Plan. The Project Manager and project team should be ready to adjust the plan during implementation to deal with unexpected events and the need for additional verification.
(2) The Project Manager shall be responsible for assuring that proper inspection, testing, screening, and/or other verifications have been performed.
(i) Test plans shall include acceptance criteria.
(ii) Test data shall be fully documented and maintained to support downstream analyses of project products and services, and of any operational anomalies and mishaps, if needed.
(3) Deliverable products/services shall be verified prior to transfer for operations.
3.4.6 Design, Develop, Transition-To-Use, and Operations
3.4.6.2 Requirements: The Project Manager and the project team shall:
3.4.6.2.a Implement the technology strategy.
(1) The Project Manager shall closely monitor the readiness of advanced technology developments occurring within the project or being supplied under partnering agreements, as per the technology strategy, for the purpose of exercising alternative technology options before the project's cost and schedule are at risk. Technologies supplied by outside sources should be tracked as high risk deliveries until such time that objective data can confirm that lower risk levels are appropriate.
(2) The Project Manager shall ensure that adequate resources are made available to document the design, development, certification, and validation of technologies created under project auspices.
(3) The Project Manager shall periodically update the appropriate Center and Headquarters commercialization offices with information relevant to the commercialization of project-developed intellectual property (i.e., technologies, discoveries, innovations, tools, processes, or software) by U.S. industry.
3.4.6.2.b Generate a procurement package for each acquisition action.
(1) The Project Manager shall generate a procurement package that contains a statement of work including performance standards, specifications, documentation deliverables, and other applicable data.
(2) In this process, the Project Manager shall use a Draft Request for Proposals (DRFP) as required by NFS 1815.201, Exchanges with Industry Before Receipt of Proposals, to ensure that comments on acquisition requirements (from contractors and other potential providers) are obtained. When a DRFP is not required, the Project Manager should consider a less formal method for obtaining industry comment.
3.4.6.2.c Develop and execute contracts and non-procurement instruments.
(1) In collaboration with the appropriate Center and/or Headquarters offices, the Project Manager shall develop or select the most appropriate acquisition instrument, per the Acquisition Plan, to satisfy program and project goals.
(2) The Project Manager shall assist the Contracting Officer in the solicitation and award of contracts, and in the development of a plan to ensure appropriate surveillance, monitoring, and reporting of activities related to contracts and non-procurement instruments in accordance with Federal law and regulations.
(3) If systems being acquired contain software, the Project Manager shall ensure compliance with the software contract requirements in NPR 7150.2, NASA Software Engineering Requirements.
3.4.6.2.d Closely monitor contractor performance.
(1) The Project Manager shall ensure that adequate contract mechanisms are in place to ensure timely and complete receipt of contractor (or grantee) financial and progress reports throughout the contract life cycle.
(2) With the aid of the Contracting Officer (or other cognizant acquisition specialist), the Project Manager shall continually assess the performance of each contractor (or grantee). The Project Manager has a responsibility to ensure that the value of items or services received remains commensurate with the plan for funds expended.
(i) EVM shall be used as a tool to monitor contractor performance as described in paragraph 3.4.3.2.
(ii) Records of contractor and grantee performance shall be maintained in accordance with Government, Agency, Mission Directorate, and Center policies to support future source selection activities.
(iii) The Project Manager and the Contracting Officer shall report the Government's assessment of performance to the contractor (or grantee).
(3) In cases where the Defense Contract Management Agency (DCMA) conducts or supports the performance monitoring function, the Project Manager shall ensure that DCMA responds to requests for information in a timely fashion.
(4) The Project Manager and the Contracting Officer shall perform surveillance of contractor safety and mission assurance performance in accordance with NPR 8735.2, Management of Government Safety and Mission Assurance Surveillance Functions for NASA Contracts.
3.4.6.2.e Ensure that safety and reliability are an integral part of the product/service design, development, production, and operations. Specifically, where the safety of the public, NASA or contractor personnel is at risk, the Project Manager shall reinforce NASA's first core value, Safety, and emphasize to the project team that safety of the public, NASA flight crews, government and contractor employees, and Agency critical assets is of paramount importance.
3.4.6.2.f Ensure compliance with property control rules and regulations.
(1) The Project Manager shall ensure that property control rules and regulations are carefully followed. Specifically, the Project Manager shall ensure that:
(i) Property is safeguarded at all times.
(ii) Equipment, systems, components, and other elements of hardware and software developed under contract(s) and/or grant(s) are not transported without required documentation being executed.
(iii) Parts, equipments, and components under NASA control are stored in secure facilities with environmental controls and location tracking appropriate to the value of the property.
(2) The Project Manager shall also ensure that NASA personnel follow property control rules and regulations when accessing parts and equipment under property control by contractors.
(3) The Project Manager shall ensure that NASA personnel follow Agency guidance in procuring spare parts per NPR 5900.1, NASA Spare Parts Acquisition.
3.4.6.2.g Execute Quality Assurance Plans.
(1) The Project Manager shall ensure that government, contractor, and grantee personnel follow design, development, manufacturing, and fabrication quality assurance practices matched to the investment that the project represents.
(2) The Project Manager shall ensure the completeness and integrity of Quality Assurance Plans or other documentation developed to measure the quality of products and services delivered by the project.
3.4.6.2.h Transition the system/asset to the end-user for operations.
(1) The Project Manager shall establish and maintain an integrated logistics support capability to enable continued operations consistent with the system/asset's intended use.
(2) The Project Manager shall ensure that adequate checkout of the system/asset is performed, and that formal acceptance of the delivered item(s) is secured at the appropriate transition point.
3.4.6.2.i As part of sustaining engineering, perform trend analyses.
(1) The Project Manager, with the TWH, shall monitor system incidents, problems, and anomalies, as well as system margins to ensure that deployed project systems function as intended.
(2) Adverse trends shall be carefully evaluated and alerts shall be issued to the Program Manager, if adverse trends cannot be reversed.
(3) The Project Manager shall ensure that project engineering data related to failures, anomalies, evaluations, problems, incidents, and Requests for Action (RFAs) are captured, retained, and made available to the NESC upon request.
3.4.6.2.j Ensure the orderly disposition of the system/asset at the end of its useful life.
(1) The Project Manager shall ensure that all requirements are met for archiving, preserving, transferring, and/or disposing of data, information, hardware, and software components.
(2) Records shall be maintained that track disposed assets.
(3) For assets with retained value, an asset valuation shall be performed prior to final disposition.
3.4.7.2 Requirements: During implementation, the Project Manager and the project team shall:
3.4.7.2.a Include the Technical Warrant Holders (TWHs) as a part of the Project Manager's analysis, evaluation, and technical decision-making processes.
3.4.7.2.b Ensure that variances from technical standards and requirements affecting safe and reliable operations have been approved by the TWH and other authorities as appropriate.
3.4.7.2.c Communicate unresolved conflicts with the TWH to the appropriate MDAA (or MSOD). Likewise, the TWH reports unresolved conflicts with the Program/Project Manager to the NASA Technical Authority (NASA Chief Engineer).
3.4.7.2.d Obtain the technical approval of the cognizant TWH for the guiding technical requirements governing the conduct of risk assessments and analysis.
3.4.8 Capture Knowledge
3.4.8.2 Requirements: The Project Manager and the project team shall:
3.4.8.2.a Ensure that project engineering and cost data, technical management information, and official project records (collectively called the project library) are captured electronically, retained, secured, disseminated, and managed in accordance with agreements, the Project Plan, and program, Center, and Agency policies.
3.4.8.2.b Provide the OCE with inputs to the Lessons Learned Information System in the form of captured experiences and lessons learned by the project team throughout the project lifecycle, for example, at major milestones.
3.5 Project Evaluation
3.5.8 Requirements: To accomplish the project evaluation process, the Project Manager shall:
3.5.8.a Plan project team and schedule resources to support IA for the NAR decision review. For initial planning purposes, the Project Manager should consult Table H-3 in Appendix H. The project's planning schedule may be modified through negotiation with the IA organization.
3.5.8.b Comply with the evaluation Terms of Reference (ToR) or equivalent for all independent reviews.
(1) The ToR or equivalent is prepared by the IA organization through negotiation with the Project Manager and Program Manager, MD (or MSO) point-of-contact, or appropriate organization. The ToR is approved by the OCE and the MDAA (or MSOD). The ToR (or equivalent) specifies the details of conducting site field review events, including the schedule, deliverable items and areas of project risk. For IAs performed by IPAO or SMO, if the negotiating parties cannot agree on the ToR scope and content, the OCE shall be the final decision authority.
(2) The final schedule shall be documented in the evaluation Terms of Reference (ToR).
3.5.8.c Prepare project briefings and material demonstrating the project's readiness to continue, and present them at the IA organization site field review. These briefings shall include a project cost estimate. The Project Manager should consult Table H-1 in Appendix H for other assessment criteria.
3.5.8.d Review the initial IA organization briefing's findings, facts, and assumptions, and provide a formal response to the IA organization.
3.5.8.e Comply with external requests for evaluation and audit (e.g., the Congress, OMB, the NASA Inspector General, GAO, etc.).
3.5.8.f Support any additional independent reviews or technical assessments that may be required during formulation and implementation as directed by the Administrator, GPMC, MDAA, the OCE (including the NESC), or the Office of Safety and Mission Assurance. The Project Manager shall provide formal responses to action items/recommendations from these reviews for closure.
3.5.8.g Ensure that project engineering data related to failures, anomalies, evaluations, problems, incidents, and Requests for Action (RFAs) are captured, retained, and made available to the NESC upon request.
3.5.8.h In cases where a major project milestone (as identified in the Project Plan, Part 2, Schedules) slips but may not appear to breach the overall project completion, the Project Manager shall notify the Program Manager and GPMC. In order to understand the consequences of the slip, the GPMC may direct an independent assessment to determine the impact on project completion schedule, cost, safety, technical performance, and residual risks.
3.5.8.i Provide support for a Safety and Mission Assurance Readiness Review (SMARR) prior to any launch or safety critical event or other activity selected by the Chief SMA Officer.
4 CHAPTER 4. Basic and Applied Research Portfolios
4.2 Portfolio Formulation
4.2.b During formulation, the Portfolio Manager performs and orchestrates the following activities:
4.2.1 Portfolio Planning Requirements: The MDAA- or MSOD-designated Portfolio Manager shall:
4.2.1.a Prepare a Portfolio Process Plan.
(1) At a minimum, the Portfolio Process Plan shall:
(i) Define and document portfolio objectives that support Agency, Theme, and program goals. The Portfolio Manager coordinates with the cognizant MDAA (or MSOD) and Program Manager.
(ii) Define a process for the solicitation, evaluation, and selection of proposals (including identifying Selection Official(s)).
(iii) Establish evaluation criteria including considerations of quality, relevance to NASA missions and strategic goals, and performance.
(iv) Include an integrated portfolio budget typically for three or five years (including appropriate WBS elements).
(v) Include a multi-year schedule for the portfolio.
(vi) Include portfolio evaluation processes.
(2) Create a management and control structure to implement the Portfolio Process Plan.
4.2.1.b Obtain approval of the Portfolio Process Plan. The Portfolio Manager shall forward the Portfolio Process Plan to the Program Manager for approval.
4.2.2 Proposal Solicitation, Evaluation, and Selection Requirements: The Portfolio Manager shall:
4.2.2.a Initiate solicitation and receipt of proposals through the issuance of a Broad Agency Announcement following the process established in the approved Portfolio Process Plan. Prospective PIs participate in portfolio formulation by preparing and submitting proposals in response to a solicitation. Research proposals for individual investigations include proposed research designs, budgets, schedules, and expected outcomes.
4.2.2.b Using peer review processes established in NPR 1080.1, Science Management, evaluate proposals based on the criteria established in the solicitation.
4.2.2.c Recommend proposals for selection. Specifically, the Portfolio Manager shall:
(1) Review findings from peer review and other factors, and recommend selections for approval by the Selection Official.
(2) Include the rationale for selection or non-selection of each proposal evaluated.
(3) Include a description of all research activities within the portfolio including activities that are continued from previous years.
4.3 Portfolio Approval
4.3.1 The MDAA (or MSOD) through the designated Selection Official shall review the recommendations and supporting information, and if acceptable, approve the selection of investigations for award.
4.4 Portfolio Implementation
4.4.2 Requirements: The Portfolio Manager shall:
4.4.2.a Initiate funding for selected investigations.
4.4.2.b Update the portfolio to include the specific details of the new research investigations that have been selected.
4.4.2.c Encourage PIs to communicate their results through activities such as:
(1) Submitting progress reports (at least on an annual basis) that summarize research results to date.
(2) Publishing research results in peer-reviewed publications, participating in scientific and technical society meetings, major conferences, workshops, and carrying out other similar efforts.
4.4.2.d Maintain and report performance metrics in electronic form as required by NPR 1080.1, Science Management, and report it to the NASA Office of the Chief Scientist (OCS).
4.5 Portfolio Evaluation
4.5.2 Requirements: Evaluation is a multi-level process in which the Portfolio Manager shall:
4.5.2.a Evaluate investigations within a portfolio largely during peer review following solicitation and during performance of the investigation by review of progress reports submitted by the PI during implementation.
4.5.2.b Review portfolio scope annually, describe changes in portfolio scope in solicitations, and report changes in annual evaluations.
4.5.2.c Provide information to support evaluation of portfolio performance as specified in the Program Plan.
5 CHAPTER 5. Advanced Technology Development Projects
5.2 Project Formulation
5.2.2 Requirements: The ATD Project Manager and the project team shall:
5.2.2.a Perform technology portfolio analyses. The Project Manager shall ensure that portfolio analysis studies are conducted to justify technology selections. Techniques such as Alignment Matrices, ROI vs. Risk Matrices, Technology S-curve Maps, etc. can be used to determine the best mix of technologies that will balance the project's risk posture.
5.2.2.b Identify a set of project KPPs (a goal value and a threshold value for each).
(1) These KPPs shall be defined as the performance parameters associated with the end item delivery of the technology to the application community. The KPPs must consist of measurable engineering parameters that would be readily understood and used by engineers concerned with the ultimate application of the technology. For each KPP, the goal is the performance level that the project team is striving for, and the threshold is the minimum performance level that users agree is acceptable for the end item deliverable. Typically the threshold KPPs values are set beyond the current state-of-the art to warrant investment in the project.
(2) When the ATD project contains multiple tasks and end items deliverables, KPPs shall be identified for each task or end item deliverable.
5.2.2.c Complete the project estimate.
(1) With the cognizant Program Manager, the Project Manager shall establish a project cost estimate based on the delivery of technology end items with the agreed-upon KPPs at the required end TRL.
(2) The basis of cost and schedule estimates, including defined reserves, shall be defined in relation to the goal and threshold KPP values.
5.2.2.d Prepare a Project Plan containing the elements described in Appendix D, with the following modifications:
(1) In Part 2, Resources, the Project Manager shall employ the standard WBS template for the overall structure of the project.
(2) In Part 2, Performance, the Project Manager shall describe the project's KPPs and establish the quantitative value for each to be achieved at each project milestone. This relationship can be in the form of a matrix that shows the KPP range (goal and threshold) and TRL to be achieved at each planned major demonstration or test.
(3) In Part 2, Schedule, the Project Manager shall include a detailed schedule showing project milestones or planned major events. Managers are encouraged to identify alternative development paths in order to maximize the probability of success.
(4) Only Project Managers of Category I and II ATD projects are required to complete Part 2, Acquisition Project Baseline.
(5) Part 3, Technology Strategy shall be replaced with Part 3, Technology Insertion, and the Project Manager shall describe how the technology end item deliverable(s) (product or service) will transition to application or user adoption (i.e., a technology transfer strategy). In this section of the Project Plan, the Project Manager shall maintain close integration with the application community, and provide an exit strategy following technology transfer.
(6) Part 3, Reviews shall include a description of planned Continuation Reviews for technology pull projects. The Continuation Reviews are decision points for the users to determine if the technology maturation is still viable to meet the users' requirements. The Continuation Reviews shall have users' concurrence on their schedule frequency, participants, and review criteria.
5.3 Project Approval
5.3.1 To secure approval for ATD projects, the Project Manager shall ensure that project deliverables are clearly defined and that proposed plans allow for quantitative measurements of performance that can be objectively assessed. ATD projects, like other projects, are subject to a NAR with an independent cost estimate (for Category I and II projects) prior to implementation. ATD Project Managers are expected to update the Project Baseline for the NAR; upon approval, the project's NAR Baseline is formally established. The requirements of Section 3.3 apply to ATD projects with the modifications in Section 5.2 above.
5.4 Project Implementation
5.4.2 Requirements: During implementation, the ATD Project Manager and the project team shall:
5.4.2.a Monitor cost and schedule for breaches as required by paragraph 3.4.3.2e. A breach for ATD projects is measured against cost and schedule growth. The Project Manager shall provide notification to the Program Manager, the MDAA, and the GPMC when the growth in the projected (or actual) cost and schedule needed to deliver the threshold KPPs exceeds ten percent (10%).
5.4.2.b Communicate progress to the Program Manager and user/application community.
(1) The maturation progress of a technology at project milestones shall be measured using KPPs and TRLs.
(2) The Project Manager shall ensure that internal technical reviews of progress are conducted at each project milestone to validate achieved values for each KPP. The Project Manager should secure concurrence from the internal review team that the project has met the quantitative values for each KPP at the milestone prior to reporting progress to the Program Manager. The Program Manager reports maturation progress for each ATD project to the GPMC.
5.4.2.c The Project Manager shall ensure that changes to threshold KPPs established in the NAR Baseline are captured as part of updates to the Project Baseline.
6 CHAPTER 6. Flight Systems and Ground Support Projects
6.1 Four-Part Project Management Process
6.1.h Flight systems and ground support projects shall meet the requirements of the four-part management process described in Chapter 3 and the requirements in this chapter. For projects for which the concept of operations requires activities such as extensive refurbishment of a flight system, extensive re-supply or maintenance (ground and on-orbit), additional requirements are imposed to cover additional planning, analysis and other activities necessary for a successful Phase E. These will generally be preceded with the phrase "For projects with long-term operations and sustainment" in italics. These additional requirements are not intended for projects with extended cruise time.
6.2 Project Formulation
6.2.1 Project Planning Requirements: The Project Manager and the project team shall:
6.2.1.a Structure the detailed product-based project WBS and WBS dictionary based on the standard WBS in Appendix J, or shall obtain approval for WBS tailoring from the OCFO and OCE.
6.2.1.b Generate a Contract WBS that supports cost/schedule control requirements for each contract following contractor selection or authority to proceed to implementation (see paragraph 3.4.3.2 for detailed EVM requirements).
6.2.1.c Generate and maintain an Integrated Master Schedule (IMS) in the form of a detailed, logic-driven, highly-integrated network schedule using an automated project management (automated time phasing of tasks, critical path determination, schedule assessment, trend analysis, sort, select, and summarization capabilities, etc.) tool.
(1) The project's progress against the IMS shall be assessed and updated monthly, or more often as required, to meet the program/project needs for assessment, control and communication.
(2) The IMS baseline shall be managed through an established schedule change control process.
(3) Schedule reporting during the project shall be done in accordance with the authorizing documents (e.g., Project Plan, Data Requirements Description (DRD), Schedule Management Plan (SMP)).
(4) For projects with long-term operations and sustainment, identify the Initial Operational Capability (IOC) and Full Operational Capability (FOC) dates in the Integrated Master Schedule.
6.2.1.d Obtain the additional approval of the cognizant MDAA for the Project Plan, at the discretion of the Mission Directorate.
6.2.1.e Develop a Software Management Plan in accordance with NPR 7150.2, NASA Software Engineering Requirements.
6.2.1.f Form an operations team organization compatible with the operations portion of the WBS and the project's flight and ground operations concept. This team shall include expertise in the following areas: flight operations, ground operations, safety, mission assurance, logistics, sustaining engineering, and any other expertise required for a successful Phase E, and/or Phase F.
(1) For projects with long-term operations and sustainment, the Communications Plan shall discuss safety and problem reporting during long-term operations.
(2) For projects with long-term operations and sustainment, the operations team shall conduct operational planning and analyses to support the flight systems and ground support project and to prepare for the transition of flight assets to long-term operations.
6.2.1.g Assure that the project team seeks to learn and apply relevant lessons from successful flight systems and ground support projects, mission anomalies and mishaps.
6.2.1.h Maintain the project team awareness of emergency response plans and procedures. The Project Manager and project team shall develop, maintain and test their project-specific plans (e.g., ground and mission emergency/contingency/failure plans) to ensure the team is adequately trained and prepared.
6.2.2 Cost Estimation Requirements: The following requirements apply to both AO-driven and non-AO-driven flight systems and ground support projects, with exceptions for AO-driven projects noted:
6.2.2.a For Category I and II projects, the Project Manager shall complete a preliminary CADRe (Parts A and B), in accordance with Table H-4 in Appendix H. Appendix E contains the initial CADRe DRD, but the latest CADRe DRD, available in the on-line NASA Cost Estimation Handbook (), should be used. For AO-driven projects, the requirement for a preliminary end-of-Phase A CADRe is waived in lieu of the submission of a copy of the winning proposal and concept study report.
6.2.2.b For Category I and II projects, the Project Manager shall develop a risk-based LCCE (including a project cost S-curve) consistent with the preliminary CADRe for presentation at the preliminary NAR. This LCCE is called the project estimate and is appended to the CADRe as Part C.
6.2.2.c For Category I and II projects, the Project Manager shall develop a Baseline CADRe and a risk-based LCCE (including a project cost S-curve) consistent with the Baseline CADRe for presentation at the NAR. This LCCE is called the NAR estimate and is appended to the CADRe as Part C. AO-driven Category I and II projects shall develop a risk-based LCCE (including a project cost S-curve) consistent with the Baseline CADRe for presentation at their Confirmation Review. This LCCE is called the CR estimate and is appended to the CADRe as Part C.
6.2.2.d Category I and II projects shall provide updated CADRe submissions (all parts) at:
(1) Critical Design Review (CDR),
(2) Approximately six months after launch (to capture the project's technical definition and its Phase A through D costs), and
(3) At the end of the planned project lifecycle (to capture final Phase E through F costs).
6.2.2.e For projects with long-term operations and sustainment, the Project Manager shall work with the OCFO to establish a nominal project end date for the purpose of estimating operations and sustainment costs.
6.2.3 Systems Engineering Requirements: The Project Manager and the project team shall:
6.2.3.a Working with the Mission Directorate, Program Manager, customers and stakeholders, define a validated set of project requirements that are levied by the program and that include mission success criteria. These high-level project requirements shall be placed under configuration control in Phase A.
6.2.3.b Develop operations scenarios and concepts, mission profiles, and mission operational modes for the purpose of fostering a better understanding of operational requirements, including LCC drivers for logistics and maintenance. The concept of operations describes the "who, what, when, where, and how" of the system.
6.2.3.c Define the internal and external operational environments for the flight system.
6.2.3.d For projects with long-term operations and sustainment, the concept of operations shall include the operational KPPs; the sustaining engineering, mission operations, ground operations, and integrated logistics support (e.g., maintenance concepts(s), sparing philosophy) concepts necessary for a successful Phase E.
6.2.3.e For projects with long-term operations and sustainment, complete planned cost-performance trades, Analysis of Alternatives (AoA) studies, Cost As an Independent Variable (CAIV) assessments, and other systems analyses that include these operational KPPs as measures of effectiveness/measures of performance.
(1) As a result of these studies and analyses, but prior to the end of formulation, the Project Manager shall specify quantitative values for each operational KPP, which will then be incorporated into the Project Baseline (along with the related project success criteria, schedule, and LCCE) and which will be used to evaluate project performance.
(2) As a result of these studies and analyses, the Project Manager shall also establish a close link between each operational KPP and project operational performance requirements.
6.2.3.f Define a validated set of flight and ground system requirements, including interface requirements and specialty engineering (e.g., safety, reliability) requirements.
6.2.3.g Define a validated set of enabling system requirements, especially for integrated logistics support. (See NPD 7500.1, Program and Project Logistics Policy.)
6.2.3.h Ensure that the requirements flow hierarchy is consistent with the Work Breakdown Structure.
6.2.3.i Establish and maintain a (configuration-managed) requirements baseline in an established database.
6.2.3.j Evaluate major changes to the requirements baseline through the systems analysis process as needed prior to any approval of such changes.
6.2.3.k Ensure that trade studies are documented as part of the project library.
6.2.3.l Ensure that models and simulations used to support these trade studies have been validated. Early in formulation, the project team should identify, develop, or otherwise acquire and implement the models (including prototypes and simulations) needed to accomplish all trade studies.
6.2.3.m Identify and plan a series of trade studies to determine the most cost-effective means of meeting requirements for communications, tracking, data processing, and mission operations, including commercial options.
6.2.3.n For Category I flight systems and ground support projects, complete an initial Probabilistic Risk Assessment (PRA) during formulation. NPR 8000.4, Risk Management Procedural Requirements, provides general criteria for selecting the scope of the PRA, while NPR 8705.5, Probabilistic Risk Assessment Procedures for NASA Programs and Projects, provides detailed procedures for performing a PRA.
6.2.3.o Develop a technical resource margin management approach, and implement a tracking and reporting process to support it.
6.2.4 Project Assessment and Control Requirements: The Project Manager and the project team shall:
6.2.4.a Monitor changes in the project estimate presented at the preliminary NAR, and immediately inform the Program Manager if it increases by more than 25% in Phase B. The Project Manager should make every effort to produce a project cost estimate that contains an adequate cost-risk margin. During Phase B, life cycle cost growth beyond 25% of the preliminary NAR project estimate may result in a Termination Review initiated by the Program Manager or MDAA.
6.2.4.b Provide the MDAA a Project Status Report (PSR) in formats ready for reporting to the OCFO when required to do so, as defined in GAO Report B-237602, "Project Status Reports." The OCFO will validate the PSR and forward it, through the Office of Legislative Affairs, to the appropriate congressional committees.
6.3 Project Approval
6.3.1 Purpose: The project approval process for flight systems and ground support projects is an on-going effort by senior NASA management to determine the project's readiness (at key milestones) to proceed to the next project phase or to implementation. To secure approval for a flight systems and ground support project, the Project Manager shall prepare (or revise) key project management documents (Project Plan, etc.) and present them to the GPMC at a decision review meeting.
6.3.4 Requirements: In support of GPMC decision review meetings during project approval:
6.3.4.a The Project Manager shall support evaluation by the IA organization in accordance with the project evaluation process. (See Section 6.5.)
6.3.4.b The Project Manager shall prepare a project overview briefing for presentation at the GPMC milestone decision review meeting to include a summary of the project, the status of project documentation and products, and significant risks, all appropriate to the level of project maturity.
6.3.4.c The Project Manager shall ensure that the project documents and products described in Table 6-2 are available at the GPMC decision review.
6.3.4.d At that meeting, the IA results and findings, including the results of an ICE or ICA, will also be presented. The Project Manager shall then follow with a presentation of responses to the IA findings.
6.4 Project Implementation
6.4.a Project implementation entails continued execution of the Project Plan and all activities leading up to the successful delivery of the product or service that meets the original requirements. Successful project implementation relies on close interaction between the project team and the user and/or customer of the product or service. The Project Manager shall comply with the requirements in Section 3.4, and shall meet additional requirements in the following activities:
a. Project assessment and control
b. Systems engineering
c. Design, develop, transition-to-use, and operations
d. Capture knowledge.
6.4.1 Project Assessment and Control Requirements: The Project Manager and the project team shall:
6.4.1.a Determine and implement appropriate means for observing the project in all phases where technical risks have been identified, along with a means for collecting, trending, archiving, and analyzing data for post-anomaly investigation.
6.4.1.b Implement a system to access "as-built" configurations, including photographic records and engineering drawings of all critical subsystem modifications, to assist in real-time troubleshooting.
6.4.2 Systems Engineering Requirements: The Project Manager and the project team shall:
6.4.2.a For Category I projects, ensure that the PRA is updated throughout implementation. The Project Manager should integrate PRA results into system design and operational risk mitigation trades.
6.4.2.b Track and report project technical resource margins periodically throughout implementation.
6.4.2.c Conduct Physical and Functional Configuration Audits.
6.4.2.d For projects with long-term operations and sustainment, evaluate (using the systems analysis process) upgrades or modifications to deployed project systems, alternative product improvement investments, and decommissioning/disposal alternatives, as needed.
6.4.3 Design, Develop, Transition-to-Use, and Operations Requirements: The Project Manager and the project team shall:
6.4.3.a Deliver, deploy, and transition-to-use project flight and ground systems.
6.4.3.b Deliver new technology through data, information, products, and services.
6.4.3.c Execute acceptance/turnover agreements and data for those products requiring transfer of custodial responsibility.
6.4.3.d Establish and maintain an integrated logistics support capability, including spares, ground support equipment, system maintenance and operating procedures, in order to sustain deployed hardware and software systems, consistent with mission requirements and plans.
6.4.3.e Establish and maintain other enabling systems, as needed, so as to ensure that critical facilities, equipment, materials, training, simulation support, and other services are available when needed.
6.4.3.f Provide sustaining engineering to promote efficiency enhancements, safety enhancements, and accommodate obsolescence.
6.4.3.g Refine and implement plans for disposition/decommissioning of project assets (flight and ground) after the end of their useful life.
6.4.3.h For projects with long-term operations and sustainment, the project during Phase E refines its operations success criteria, operations concept and plans to meet mission objectives specified in the Program and Project Plans, but the focus is on the tactical execution of the next mission increment, launch, or mission epoch. As the project produces its intended products and services, it continually explores new operations and sustainment options to meet the overall objectives, reduce operations costs and operational risks; fine tunes the internal management control functions that will be used throughout the remaining life of the project; assesses new technologies, modifications, and upgrades that potentially increase safety and performance, and lower operations costs; and tracks operational margins and reserves consistent with project safety requirements. If necessary, agreements (Program and Project Plans) are modified, and approved in accordance with the approval process. In order to accomplish this, the Project Manager and the project team shall:
(1) Refine program/project goals, objectives, and success criteria as a part of the ongoing validation of the deployed project systems, and ensure that these flow down as appropriate to lower-level operations plans.
(2) As applicable, refine and incorporate updated mission plans and technology upgrade strategies, infrastructure plans, acquisition strategies, technical and management implementation plans, space operations service agreements, launch services agreements, and other internal agreements into the Project Plan.
(3) Continually examine opportunities to exploit promising product improvement technologies that could reduce program/project operational risk, reduce LCC, gain performance, correct newly uncovered design defects, or overcome operational constraints. The Project Manager should make recommendations regarding which product improvement technologies should be funded by the project, and which should be considered for funding at higher levels.
(4) Continue to work with the Office of External Relations and the MDAA to identify potential non-NASA partners and necessary agreements for international or interagency; all activities and documentation must be consistent with policy and with program or Agency-level agreements with partners.
(5) Ensure that the deployed project systems continue to function as intended, perform trend analyses as needed of:
(i) System incidents, waivers/deviations, problem reports, and anomalies
(ii) Key performance parameters (KPPs) for operations and sustainment
(iii) Project technical resource margins.
6.4.4 Capture Knowledge Requirements: The Project Manager and the project team shall:
6.4.4.a Capture and forward summaries of project costs as a function of the WBS, and other performance information, to the OCFO Cost Analysis Division for inclusion in the ONCE database using the CADRe format.
6.4.4.b Archive all relevant project records and data (drawings, analyses, reports, etc.) in the project library in electronic format.
6.5 Project Evaluation
6.5.3 Requirements: To accomplish the project evaluation process, the Project Manager shall:
6.5.3.a Prepare project briefings and material demonstrating the project's readiness to continue, and present them at the IA organization site field review. The Project Manager should consult Table H-1 in Appendix H for other assessment criteria.
6.5.3.b Following the NAR approval, provide the IA organization access to project information databases, performance data, meetings, and NASA and contractor sites in accordance with the ToR. This includes access to project cost-performance evaluations, including EVM data for Category I and II projects.
7 CHAPTER 7. Institutional Projects
7.2 Project Formulation
7.2.2 Requirements: This document recognizes that different development models and historical practices apply. IT and OFI projects often take the form of spiral or incremental developments with a sustained level-of-effort throughout development. CoF and ECR projects, on the other hand, are usually waterfall developments following tried-and-tested construction practices. Therefore, separate requirements are identified below.
7.2.2.1 For CoF projects, the FPM shall comply with the requirements of NPR 8820.2, Facility Project Implementation Guide, rather than Section 3.2 of this document. For ECR projects, the EPM shall comply with the requirements of NPR 8590.1, Environmental Compliance and Restoration Program Implementation, rather than Section 3.2 of this document.
7.2.2.2 For IT and OFI projects, the Project Manager and the project team shall:
7.2.2.2.a Comply with the requirements of Section 3.2.
7.2.2.2.b Prepare a Project Plan containing the elements described in Appendix D with the following modifications:
(1) In Part 2, Resources, the Project Manager shall employ the appropriate WBS template for the overall structure of the project.
(2) Project IT investments shall be separately planned for, evaluated in terms of Return on Investment (ROI), budgeted, and managed.
(i) Planning shall cover the life cycle of the project and be sufficient to provide for data recovery, contingency facilities, and reconstitution of critical IT resources.
(ii) The IT Project Manager shall conduct risk assessments in accordance with NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems, and prepare an IT Security Plan in accordance with NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems.
7.2.2.2.c The Project Manager shall comply with the requirements of NPR 7150.2, NASA Software Engineering Requirements, for software elements.
7.2.2.3 Because of the nature of institutional projects, the duration of the project may be substantially shorter than the life of the asset created. The Project Plan shall address the transition of responsibility for the asset to the receiving operations and sustainment organization.
7.3 Project Approval
7.3.3 For all other institutional projects, the Project Manager shall meet the requirements of paragraph 3.3.3. Institutional projects, like other projects, are subject to a NAR prior to implementation and an ICE, if warranted by project category. As a part of securing approval, all projects with IT elements shall be assessed against compliance with the current approved version of the NASA Enterprise Architecture (EA). This means that the CIO must have access to mission Program and Project Plans when they contain IT elements. Approval of such plans is provided by the OCIO through participation in the IC and GPMC structures.
7.4 Project Implementation
7.4.2 During CoF project implementation, the FPM shall comply with the requirements of NPR 8820.2, Facility Project Implementation Guide, rather than Section 3.4 of this document. During ECR project implementation, the EPM shall comply with the requirements of NPR 8590.1, Environmental Compliance and Restoration Program Implementation, rather than Section 3.4 of this document.
7.4.3 During IT and OFI project implementation, the Project Manager shall:
7.4.3.a Comply with the requirements of Section 3.4.
7.4.3.b Monitor changes to security plans and procedures to ensure that the project's security controls and implementation activities are well-matched to threat assessments related to physical and information security.
7.4.3.c Prepare user operational training and familiarization documentation to ensure a smooth transition-to-use, customer acceptance, and high utilization of the product or service under development.
7.4.3.d For IT investments, utilize NASA software assurance personnel and the requirements found in NASA-STD-8739.8, Software Assurance Standard, and when indicated or selected, use the NASA IV&V capabilities.
7.4.3.e Provide the MSOD a Project Status Report (PSR) in formats ready for reporting to the OCFO when required to do so, as defined in GAO Report B-237602, "Project Status Reports." The OCFO will validate the PSR and forward it, through the Office of Legislative Affairs, to the appropriate congressional committees.
7.5 Project Evaluation
7.5.1 Agency visibility into the progress of institutional projects will occur through independent project reviews, program reviews by the governing authority, and biennial (every two years) PIRs conducted by the IPAO. CoF projects are evaluated using the criteria outlined in NPR 8820.2, Facility Project Implementation Guide, and ECR projects in accordance with NPR 8590.1, Environmental Compliance and Restoration Program Implementation. To support evaluation, all other institutional Project Managers shall comply with the requirements of Section 3.5.3.
7.5.2 IT projects shall be assessed throughout their lifecycle to evaluate their effectiveness in supporting program/project objectives. Assessments shall be made against appropriate metrics and benchmarks to evaluate the cost and performance of IT investments.
8 APPENDIX J: Flight Systems and Ground Support Project Work Breakdown Structure (WBS)
J.3.2 Requirements: For flight systems and ground support projects:
a. The standard flight systems and ground support project WBS shall be applied to new projects established from June 1, 2005 forward. It is not intended to be applied retroactively to existing projects.
b. The standard flight systems and ground support project WBS shall apply to the entire life cycle of the project, including disposal and decommissioning.
c. The standard flight systems and ground support project WBS shall apply to both crewed and robotic projects.
d. Flight systems and ground support projects shall use the standard Level 1/2 WBS elements (See Section J.5.). Specifically:
(1) The Project Name shall be WBS Level 1.
(2) The title of each WBS Level 2 element can be modified to facilitate project-unique titles, but the content of each must remain the same. If the linkage of the standard and the project-unique title are not intuitive, the project-unique title shall be cross-referenced to the standard title and provided to the WBS Review Team.
(3) The set of standard WBS Level 2 elements do not comprise an exhaustive or exclusive set of WBS elements. Additional WBS elements may be added horizontally (i.e., at Level 2) as long as the content of which does not fit into the content of any existing standard WBS elements.
(4) For each standard WBS Level 2 element, the subordinate (children) WBS elements at Level 3 and lower shall be determined by the project.
(5) The Level 3 and lower elements can differ from project to project, but shall include only work that rolls up to the standard WBS Dictionary definition of the Level 2 element. (See Section J.6.)
(6) If there is no work to fit into a standard WBS element, then an inactive placeholder element (and an inactive placeholder financial code) shall be established.
(7) The financial WBS shall align with the technical WBS.
(8) The management assigned to each WBS element may differ from project to project.
e. Changes to the standard flight systems and ground support project WBS shall be governed by the WBS Review Team.
f. Other changes can be made to the standard flight systems and ground support project WBS, but must be approved by WBS Review Team. Requested changes shall be made on a waiver form via the Meta Data Manager (to be in operation June 1, 2005) and submitted to the WBS Review Team, whereby a stringent review process occurs ensuring valid rationale is used to support the changes.

APPENDIX L: References


L.1 References

  1. External Legislation and Governing Documents
  1. 42 U.S.C. 2473(c)(1), Section 203(c) (1) of the National Aeronautics and Space Act of 1958, as amended
  2. 40 U.S.C. 1401 et seq., the Clinger-Cohen Act of 1996 (Section 808 of Pub. L. 104-208; renaming, in pertinent part, the Information Technology Management Reform Act, Division E of Pub. L. 104-106).
  3. 40 U.S.C. 1441 et seq., the Computer Security Act of 1987 (Pub. Law 100-235 of January 8, 1988), as amended.
  4. 44 U.S.C. 3501 et seq., The Paperwork Reduction Act of 1995 (Pub. L. 104-13 of May 22, 1995), as amended.
  5. The Government Performance and Results Act of 1993 (Pub. L. 103-62 of August 3, 1993).
  6. Executive Order 12088, Federal Compliance with Pollution Control Standards.
  7. 14 CFR Part 1203, Information Security Program.
  8. 14 CFR Part 1216, Environmental Quality.
  9. 15 CFR Parts 730-774, Export Administration Regulation.
  10. 22 CFR Parts 120-130, International Traffic in Arms Regulations.
  11. 48 CFR Chapter 1, Federal Acquisition Regulation (FAR).
  12. 48 CFR Chapter 18, NASA Federal Acquisition Regulation (FAR) Supplement (NFS).
  13. National Defense Authorization Act for FY 2001, Division A, Title X, Subtitle G, Government Information Security Reform, Public Law 106-398.
  14. NSTISSP No.12, National Security Telecommunications and Information Systems Security Policy No.12, National Information Assurance (IA) Policy for U.S. Space Systems.
  15. OMB Circular A-11, Preparation and Submission of Budget Estimates
  16. OMB Circular A-11, Supplement to Part 7, Capital Programming Guide
  17. OMB Circular A-94, Guidelines and Discount Rates for Cost-Benefit Analysis of Federal Programs.
  18. OMB Circular A-130, Appendix III, Management of Federal Information Resources.
  19. Presidential Directive/National Security Council Memorandum No. 25 (PD/NSC-25), Scientific or Technological Experiments with Possible Large-Scale Adverse Environmental Effects and Launch of Nuclear Systems into Space
  1. NASA Policy Directives and NASA Procedural Requirements
  1. NPD 1000.1, NASA Strategic Plan
  2. NPR 1000.2, NASA Strategic Management Handbook
  3. NPD 1000.3, The NASA Organization w/Change 2
  4. NPD 1050.1, Authority to Enter Into Space Act Agreements.
  5. NPD 1080.1, NASA Science Policy.
  6. NPR 1080.1, Science Management
  7. NPR 1240.1, NASA Technical Warrant System
  8. NPD 1240.4, NASA Technical Authority
  9. NPD 1280.1, NASA Management System Policy
  10. NPD 1360.2, Initiation and Development of International Cooperation in Space and Aeronautics Programs.
  11. NPR 1371.2, Procedures and Guidelines for Processing Requests for Access to NASA by Foreign Nationals or Representatives.
  12. NPD 1371.5, Coordination and Authorization of Access by Foreign Nationals and Foreign Representatives to NASA.
  13. NPR 1382.17, Privacy Act - Internal NASA Direction in Furtherance of NASA Regulation.
  14. NPD 1440.6, NASA Records Management.
  15. NPR 1441.1, NASA Records Retention Schedules.
  16. NPD 1600.2, NASA Security Policy.
  17. NPR 1600.6, Communications Security Procedures and Guidelines.
  18. NPR 1620.1, Security Procedures and Guidelines
  19. NPD 1800.2, NASA Occupational Health Program.
  20. NPD 1820.1, NASA Environmental Health Program.
  21. NPD 2190.1, NASA Export Control Program.
  22. NPR 2190.1, NASA Export Control Program.
  23. NPR 2200.2, Guidelines for Documentation, Approval, Dissemination of NASA Scientific and Technical Information
  24. NPD 2800.1, Managing Information Technology.
  25. NPR 2800.1, Managing Information Technology
  26. NPD 2810.1, NASA Information Security Policy.
  27. NPR 2810.1, Security of Information Technology
  28. NPD 2820.1, NASA Software Policies
  29. NPD 3000.1, Management of Human Resources
  30. NPD 3410.2, Employee and Organizational Development
  31. NPR 3451.1, NASA Awards and Recognition Program
  32. NPD 5101.32, Procurement.
  33. NPR 5101.33, Procurement Advocacy Program.
  34. NPR 5800.1, Grant and Cooperative Agreement Handbook.
  35. NPR 5900.1, NASA Spare Parts Acquisition
  36. NPD 7000.3, Allocation and Control of Agency Resources.
  37. NPD 7100.8, Protection of Human Research Subjects.
  38. NPD 7120.4, Program/Project Management
  39. NPR 7150.2, NASA Software Engineering Requirements
  40. NPD 7330.1, Approval Authorities for Facility Projects.
  41. NPD 7500.1, Program and Project Logistics Policy
  42. NPR 7900.3, Aircraft Management Operations
  43. NPD 7900.4, Aircraft Management Operations
  44. NPR 8000.4, Risk Management Procedural Requirements
  45. NPD 8010.2, Use of the SI (Metric) System of Measurement in NASA Programs
  46. NPD 8020.7, Biological Contamination Control for Outbound and Inbound Planetary Spacecraft
  47. NPR 8020.12, Planetary Protection Provisions for Robotic Extraterrestrial Missions
  48. NPD 8070.6, Technical Standards.
  49. NPD 8500.1, NASA Environmental Management.
  50. NPR 8553.1, NASA Environmental Management System (EMS).
  51. NPR 8570.1, Energy Efficiency and Water Conservation Technologies and Practices.
  52. NPR 8580.1, Implementing the National Environmental Policy Act and Executive Order 12114.
  53. NPR 8590.1, Environmental Compliance and Restoration Program Implementation
  54. NPD 8610.7, Launch Services Risk Mitigation Policy for NASA-Owned or NASA-Sponsored Payloads
  55. NPD 8610.12, Office of Space Operations (OSO) Space Transportation Services for NASA and NASA-Sponsored Payloads
  56. NPD 8621.1, NASA Mishap Reporting and Investigation Policy.
  57. NPD 8700.1, NASA Policy for Safety and Mission Success
  58. NPD 8700.3, Safety and Mission Assurance (SMA) Policy for NASA Spacecraft, Instruments, and Launch Services
  59. NPR 8705.2, Human Rating Requirements and Guidelines for Space Flight Systems
  60. NPR 8705.4, Risk Classification of NASA Payloads
  61. NPR 8705.5, Probabilistic Risk Assessment Procedures for NASA Programs and Projects
  62. NPD 8710.1, Emergency Preparedness Program
  63. NPD 8710.2, NASA Safety and Health Program Policy
  64. NPR 8715.3, NASA Safety Manual
  65. NPD 8720.1, NASA Reliability and Maintainability (R&M) Program Policy
  66. NPD 8730.2, NASA Parts Policy
  67. NPD 8730.3, NASA Quality Management System Policy (ISO 9000)
  68. NPD 8730.4, Software Independent Verification and Validation (IV&V) Policy
  69. NPR 8735.1, Procedures for Exchanging Parts, Materials, and Safety Problem Data Utilizing the Government-Industry Data Exchange Program and NASA Advisories
  70. NPR 8735.2, Management of Government Safety and Mission Assurance Surveillance Functions for NASA Contracts.
  71. NASA Standard 8739.8, Software Assurance Standard
  72. NPD 8820.2, Design and Construction of Facilities
  73. NPR 8820.2, Facility Project Implementation Guide
  74. NPR 8820.3, Pollution Prevention.
  75. NPR 8830.1, Affirmative Procurement Plan for Environmentally Preferable Products.
  76. NPR 8850.1, Environmental Investigation and Remediation - Potentially Responsible Party Identification and Analysis.
  77. NPD 8900.1, Medical Operations Responsibilities for Human Space Flight Programs.
  78. NPD 9050.3, Administrative Control of Appropriations and Funds.
  79. NPD 9501.1, NASA Contractor Financial Management Reporting System.
  80. NPR 9501.2, NASA Contractor Financial Management Reporting.
  81. NPD 9501.3, Earned Value Management
  82. NPR 9501.3, Earned Value Management Implementation on NASA Contracts.

L.2 Related References (Informational Only)

  1. External Standards and Guides
  1. ISO/IEC 15288, Systems Engineering - Systems life cycle processes (2003)
  2. ANSI/EIA-632-1998, Processes for Engineering a System (1998)
  3. IEEE-1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process (1998)
  4. ANSI/EIA 748-A, Industry Guidelines for Earned Value Management Systems
  5. SP-6105, NASA Systems Engineering Handbook (1995)
  6. NTIS#: AD-A319533KKG, DTIC#: AD-A319 533\6\XAB, Software Engineering Institute at Carnegie Mellon University, Continuous Risk Management Guidebook (1996)
  7. Defense Acquisition University, Ft. Belvoir, VA, Systems Engineering Fundamentals (2000)
  8. Air Force Materiel Command, Office of Aerospace Studies (AFMC) OAS/DR, AoA Handbook: A Guide for Performing an Analysis of Alternatives (July 2002).
  9. MIL-STD-881, Work Breakdown Structures for Defense Material Items.
  10. MIL-HDBK-245, Preparation of Statement of Work.
  11. ANSI/ISO/ASQ-Q9001-2000.
  12. NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems
  13. NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems
  14. AS9100, Quality Systems Aerospace Model for Quality Assurance in Design, Development, Production, Installation and Servicing.
  15. DoD 5000.4M, Cost Analysis Guidance and Procedures (December 1992)
  16. DoD 5000.2M, Cost Performance Reports
  1. Manuals and Reports
  1. GAO Report B-237602, Project Status Reports
  2. NASA Financial Management Manual, Volumes 9000, 9100, and 9300.
  1. Websites
  1. NASA Cost Estimating Handbook (2004), http://www.ceh.nasa.gov
  2. Office of Procurement Home Page: http://www.hq.nasa.gov/office/procurement
  3. NASA Standards homepage, http://standards.nasa.gov
  4. Erasmus homepage https://erasmus.ifmp.nasa.gov
  5. NASA Lessons Learned Information System (LLIS), http://llis.gsfc.nasa.gov
  6. NASA Continuous Risk Management Course, http://crm.nasa.gov
  7. Academy of Program and Project Leadership (APPL) website: http://appl.nasa.gov
  8. NASA Technology Inventory Database, http://inventory.gsfc.nasa.gov
  9. DD 2734 Cost Performance Report (CPR), http://www.dior.whs.mil
  10. NASA Online Directives Information System (NODIS), http://nodis3.gsfc.nasa.gov
  11. Volume 7 of the NASA Financial Management Requirements, http://www.hq.nasa.gov/cfo/internal/fmr

APPENDIX M. Definitions


Acceptable Risk. The risk that is understood and agreed to by the program/project, GPMC, Mission Directorate (or Mission Support Office), the TWH (for safe and reliable operations), and other customer(s) sufficient to achieve the defined success criteria within the approved level of resources.

Acquisition. The acquiring, by contract, of supplies or services (including construction) through purchase or lease, whether the supplies or services are already in existence or must be created, developed, demonstrated, or evaluated. Acquisition begins at the point when Agency needs are established and includes the description of requirements to satisfy Agency needs, solicitation, and selection of sources, award of contracts, contract financing, performance, administration, technical, and management functions directly related to the process of fulfilling Agency needs by contract.

Acquisition Team. All participants in Government acquisition, including not only representatives of the technical, supply, and procurement communities, but also the customers they serve.

Activity. Any of the program and project management components that are executed in order to complete the four-part management process.

Advocacy Chain. Any person that has a vested interest in the outcome of a particular program or project.

Agency Program Management Committee (Agency PMC). The senior management group, chaired by the Deputy Administrator or the Administrator's designee, responsible for reviewing program formulation performance, recommending approval of proposed programs, and overseeing implementation of designated programs and projects according to Agency commitments, priorities, and policies.

Allowance for Program Adjustment (APA). Fiscal resources available for approved changes in program objectives or scope that are documented in the PCA, the resolution of unforeseen major problems, program/project stretch outs from Agency funding shortfalls, and similar fiscal events.

Analysis of Alternatives. A formal analysis method that compares alternatives by estimating their ability to satisfy mission requirements through an effectiveness analysis and by estimating their life cycle costs (LCC) through a cost analysis. The results of these two analyses are used together to produce a cost-effectiveness comparison that allows decision-makers to assess cost and effectiveness simultaneously. An AoA broadly examines multiple elements of program/ project alternatives (including technical performance, risk, LCC, and programmatic aspects), and is typically an important part of formulation studies. The terms, trade studies, trades, and tradeoff analyses, are often used in lieu of AoA, when the scope of the analysis is more limited.

Anomaly. An unexpected event, hardware or software damage, a departure from established procedures or performance, or a deviation of system, subsystem, and/or hardware or software performance outside certified or approved design/performance specification limits.

Approval. The process used to initially decide on a program/project's readiness to proceed from formulation into implementation and subsequently used to approve changes to the program/project baseline.

Assure. Making certain that specified activities performed by others are performed in accordance with specified requirements.

Baseline. The technical performance and content, technology application, schedule milestones, and budget (including contingency and APA) which are documented in the approved Program and Project Plans.

Breach. Project growth above 10% of the NAR Baseline or a failure to meet a KPP. Commercialization. Identify opportunities for establishing partnerships with the private sector, academia, and other government organizations to conduct dual-use research, develop mutually beneficial technologies, and transfer results into NASA for mission use and the private sector for commercial application. Component Facilities. Complexes that are geographically separated from the NASA Center or institution to which it is assigned.

Configuration Management. A management discipline applied over the product's life cycle to provide visibility and to control performance and functional and physical characteristics.

Confirmation Review. The equivalent of the NAR for AO-driven flight development projects.

Contingency. Reserves, including funding, schedule, performance, manpower, and services, allocated to and managed by the Program/Project Manager for the resolution of problems normally encountered to mitigate risks while ensuring compliance to the specified program/project scope.

Continuous Cost-Risk Management (CCRM). A multi-step approach to cost estimating and project cost management that seeks to integrate the various project management activities that involve cost and cost risk. CCRM encompasses the following: cost-effectiveness trades (where CAIV is a subset), detailed project definitions (CADRe development) and probabilistic, risk-based Life Cycle Cost Estimates (project cost S-curve) documented in the CADRe; disciplined cost and schedule rebaselining; Earned Value Management for continuous management and reporting of risky WBS elements; periodic updates of the CADRe for continual reassessment of project cost performance; and end-of-project data collection and storage in the One NASA Cost Engineering (ONCE) database for cost analysis improvement. CCRM emphasizes that the high-risk elements in the WBS most likely to cause adverse cost and schedule impacts are the common focus of these activities.

Continuous Risk Management (CRM). The process that identifies risk; analyzes their impact and prioritizes them; develops and carries out plans for risk mitigation or acceptance; tracks risk and the implementation of plans; supports informed, timely, and effective decisions to control risks and mitigation plans; and assures that risk information is communicated and documented.

Contract. A mutually binding legal relationship obligating the seller to furnish the supplies or services (including construction) and the buyer to pay for them. In addition to bilateral instruments, contracts include, but are not limited to, awards and notices of awards; job orders or task letters initiated under basic ordering agreements; letter contracts; orders, such as purchase orders, under which the contract becomes effective by written acceptance or performance; and bilateral contract modifications.

Cost Analysis Data Requirement (CADRe). A formal document to understand the cost and cost risk of space flight projects. The CADRe consists of a Part A "Narrative", a Part B "Technical Data" in tabular form, and a Part C "Project Life Cycle Cost Estimate." Part C is not provided to the ICE team.

Crosscutting Technology. That which is generally applicable to multi-missions and focuses on the earlier stages of the life cycle.

Customer. Any individual, organization, or other entity to which a program or project provides a product(s) and/or service(s).

Data Requirement Description (DRD). A document inserted into an RFP and contract requiring data (e.g., EVM Contract Performance Report (CPR); CADRe; IMS; Risk Management Plans and Reports; etc.). A DRD can describe tailoring to a standard (e.g., EVM CPR Data Item Description (DI-MGMT-81466 ) or be a stand-alone data requirement if there is no underlying standard (e.g., CADRe).

Deviation. A documented agreement intentionally releasing a program or project from meeting a requirement. (Some Centers use deviations prior to Implementation, and waivers during Implementation.)

Earned Value Management (EVM). A tool for measuring and assessing project performance through the integration of technical scope with schedule and cost objectives during the execution of the project. EVM provides quantification of technical progress, enabling management to gain insight to project status and project completion costs and schedules. Two essential characteristics of successful EVM are EVM system data integrity and carefully targeted monthly EVM data analyses (i.e., risky WBS elements).

Enabling Systems. Those systems that while not a functioning part of the intended system- of- interest are nevertheless required for its proper achievement. Enabling systems (e.g., the production system, deployment system, training system, and maintenance system) facilitate the progression of the system-of-interest through its life cycle. Since the system-of-interest and its enabling systems are interdependent, they can also be viewed as a system. Program/project responsibility thus extends to responsibility for acquiring services from the relevant enabling systems in each life- cycle phase. When a suitable enabling system does not already exist, the program/project that is responsible for the system-of-interest can also be responsible for creating and using the enabling system.

Ensure. Performing specified activities in accordance with requirements for that activity.

Enterprise Architecture. An explicit description and documentation of the current and desired relationships among business and management processes and information technology. An Enterprise Architecture includes principles, an architecture framework, a technical standards profile, current and target architectures, and a transition strategy to move from the current to target architecture.

Environmental Impact. The direct, indirect, or cumulative beneficial or adverse effect of an action on the environment.

Environmental Management. The activity of ensuring that program and project actions and decisions which potentially impact or damage the environment are assessed/evaluated during the formulation/planning phase and reevaluated throughout implementation and performed according to all NASA policy and Federal, state, and local environmental laws and regulations.

Estimate at Completion. The sum of project actual costs to date, estimated costs to complete (ETC), and reserves. Contractor financial information is included in the project Estimate at Completion.

Evaluation. The process used to provide independent assessments of the continuing ability of the program/project to meet its technical and programmatic commitments. Evaluation also provides value-added assistance to the program/project managers.

Evolutionary Acquisition. A strategy for rapid acquisition of mature technology. An evolutionary acquisition approach delivers a functional capability in increments, recognizing upfront the need for future capability improvements. The objective of the approach is to balance needs and current capability against resources, and to put additional capability into use quickly. Spiral development is one way to execute an evolutionary acquisition strategy.

Formulation. The process used to define the program/project concept and plan to meet customer requirements.

Formulation Authorization Document (FAD). The document issued by the MDAA (or MSOD) to authorize the level of formulation of a program whose goals will fulfill part of the Agency's Strategic Plan, Mission Directorate Strategies, or Mission Support Office Functional Leadership Plans. In addition, a FAD or equivalent is used to authorize the level of formulation of a project.

Full Cost. The entire cost to the Agency to conduct a program or project. Full cost includes not only directly attributable costs such as cost of a program's associated contracts but also an appropriate share of Center and Agency-wide overhead costs and the costs of any shared services that the program or project uses. Full cost budgeting, managing, and accounting increases management's visibility over available resources and promotes informed tradeoffs within the overall budget envelope to maximize program and project results.

Full Operational Capability (FOC). The full attainment of the capabilities to employ an item of equipment, or system of approved specific characteristics, operated and supported by a trained workforce.

Goal Value. The quantitative KPP performance level that the project team is striving for.

Governing Program Management Committee (GPMC). The highest level PMC that has the responsibility to regularly review a program or project.

Implementation. The process used to deliver the products and capabilities specified in the approved Program/Project Plan.

Independent Assessment (IA). The general term referring to an evaluation of a program or project conducted by experts outside the advocacy chain. The evaluation results in an assessment of the program's or project's readiness (technical, schedule, cost, risk) to proceed to the next phase in the lifecycle that is reported to a GPMC.

Independent Cost Analysis (ICA). An independent analysis of program/project resources associated with the program/project content, conducted by an impartial body independent from the management or advocacy of the program/project. ICA includes, but not limited to, the assessment of cost estimates, budget, and schedule in relation to program/project technical performance and risk. ICA may include an independent cost estimate (ICE), assessment of resource distribution and planning, and verification of cost estimating methodologies.

Independent Cost Estimate (ICE). A program/project cost estimate prepared by an office or other entity that is not under the supervision, direction, advocacy, or control of the program/project that is responsible for carrying out the development or acquisition of the program/project. An ICE is bounded by the program/project scope, schedule, technical content, risk, ground rules and assumptions and conducted with objectivity and the preservation of integrity of the cost estimate.

Independent Program Assessment Office (IPAO). The NASA organization responsible for scheduling, organizing, and conducting the independent reviews (Concept Decision Review, Preliminary Non-Advocate Review, Non-Advocate Review, and Production Review) for programs and projects reporting to the Agency PMC.

Independent Review Team. The general term used to refer to an independent group of individuals outside the advocacy chain of a program or project that is charged with conducting an independent program or project review. The IRT can refer to an IPAO, SMO or third party team.

Independent Technical Authority (ITA). Technical Authority is the authority, responsibility, and accountability to establish, approve, and maintain technical requirements, processes, and policy. The execution of technical authority in support of mission-related programs and projects without organizational or financial control by such program and/or projects.

Independent Verification and Validation (IV&V). A process whereby the products and processes of the software development life-cycle phases are reviewed, verified, and validated by an organization that is neither the developer nor the purchaser of the software, which is defined by two parameters - technical independence and managerial independence. Technical independence engages personnel who are not involved in the development activities. Managerial independence requires responsibility for the IV&V effort to be vested in an organization separate from the organization responsible for development.

Information Technology. Hardware and software operated by a Federal agency or by a contractor of a Federal agency or other organization that processes information on behalf of the Federal Government to accomplish a Federal function, regardless of the technology involved, whether by computers, telecommunications systems, automatic data processing equipment, or other.

Infrastructure Requirements. The real property/facilities, aircraft, personal property/equipment, and information technology resources, that are required to support programs and projects. Utilization of the capability afforded by the infrastructure includes full lifecycle cost, including operations, sustainment, disposal, environmental impacts and other liabilities it presents.

In-House Project. One that is conducted onsite or in the immediate vicinity of a NASA Center in which most major technical, business, and management tasks are performed primarily by the Center's civil service workforce.

Initial Operating Capability (IOC). The first attainment of the capability to employ an item of equipment, or a system of approved specific characteristics, operated and supported by a trained workforce.

Institutional Requirements. Infrastructure and workforce required to support programs and projects. Specifically, the human resources, real property/facilities, aircraft, personal property/equipment, and information technology resources required to support programs and projects.

Integrated Baseline Review (IBR). An IBR is a formal project-level review that includes total project (contracted as well as in-house NASA) efforts. It is conducted jointly with personnel responsible for the efforts. Specifically, an IBR verifies that the technical content of the performance measurement baseline is consistent with the contract scope, work breakdown structure, and actual budget and schedule; ensures that effort personnel have identified all risks and are aware of their responsibilities for their management; ensures that there is a logical sequence of effort planned consistent with the contract schedule; ensures the disciplined implementation of all project Earned Value Management Systems (EVMS); establishes a forum through which the Program/Project Manager and the technical staff gain a sense of ownership of the cost/schedule management process; and establishes the baseline for the life of the contract.

Integrated Master Schedule. An IMS includes a baseline master schedule and derivative schedules which provide the framework for time phasing and coordinating all project efforts into a master plan to ensure that objectives are accomplished within program or project commitments. The IMS baseline also serves as the basis for development of the Performance Measurement Baseline (PMB) utilized in earned value management (EVM).

Investigation. A research activity that is directed by a PI according to an approved research design.

Iterative Processes. A systems engineering concept in which any or all of the systems engineering processes may need to be performed repetitively during a system's lifecycle. For example, requirements definition may occur at a high level during formulation, and again at progressively lower levels in implementation. Even though it occurs at different phases in the system lifecycle, the same process is applied.

Key Performance Parameters (KPPs). Those capabilities or characteristics (typically engineering-based or related to safety or operational performance) considered most essential for successful mission accomplishment. Failure to meet a KPP threshold can be cause for the project, system, or advanced technology development to be reevaluated or terminated. Failure to meet a KPP threshold can be cause for the system-of-systems concept to be reassessed or the contributions of the individual systems to be reassessed. A project's KPPs are identified and quantified in the Project Baseline.

Lesson Learned. The significant knowledge or understanding gained through past or current programs and projects that is documented and collected to benefit current and future programs and projects.

Life-Cycle Cost (LCC). The total of the direct, indirect, recurring, nonrecurring, and other related expenses incurred, or estimated to be incurred, in the design, development, verification, production, operation, maintenance, support, and disposal of a project. Life-cycle cost (LCC) of a project or system can also be defined as the total cost of ownership over the project's or system's life cycle from formulation through implementation. It includes all design, development, deployment, operation and maintenance, and disposal costs.

Logistics. The management, engineering activities, and analysis associated with design requirements definition, material procurement and distribution, maintenance, supply replacement, transportation, and disposal which are identified by flight and ground systems supportability objectives.

Margin. The allowances carried in budget, projected schedules, and technical performance parameters (e.g., weight, power, or memory) to account for uncertainties and risks. Margin allocations are baselined in the formulation process, based on assessments of risks, and are typically consumed as the program/project proceeds through the life cycle.

Metric. A measurement taken over a period of time that communicates vital information about a process or activity. A metric should drive appropriate action.

Mission. A major activity required to accomplish an Agency goal or to effectively pursue a scientific, technological, or engineering opportunity directly related to an Agency goal. Mission needs are independent of any particular system or technological solution.

Mission Assurance (Activities). The activities that are necessary to 1) check whether a product or service being developed meets specified mission technical requirements, and 2) to provide confidence in the program or project's ability to achieve mission success.

Mission Success (Activities). Those activities performed in line and under the control of the program or project that are necessary to provide assurance that the program or project will achieve its objectives. The mission success activities will typically include risk assessments, system safety engineering, reliability analysis, quality assurance, electronic and mechanical parts control, software validation, failure reporting/resolution, and other activities that are normally part of a program or project work structure.

Mission Success Criteria. Standards against which the program or project will be deemed a success. Mission success criteria may be both qualitative and quantitative, and may cover mission cost, schedule, and performance results as well as actual mission outcomes.

Non-Advocate Review (NAR). The analysis of a proposed program or project by a (non-advocate) team composed of management, technical, and budget experts (personnel) from outside the advocacy chain of the proposed program or project. It provides Agency management with an independent assessment of the readiness of the program/project to proceed into implementation.

NAR Baseline. Final quantitative values of each key performance parameter, funding, and schedule established at the NAR approval of a project.

Occupational Health. The promotion and maintenance of physical and mental health in the work environment.

Peer Review. Peer review means independent evaluation by internal or external subject matter experts who do not have a conflict of interest.

Performance-Based Contracting. Structuring all aspects of an acquisition around the purpose of the work to be performed as opposed to either the manner by which the work is to be performed or broad and imprecise statements of work.

Performance Measurement Baseline. The time-phased budget plan against which contract execution is measured. It is formed by the budgets assigned to scheduled control accounts and the applicable indirect budgets. For future effort, not planned to the control account level, it also includes budgets assigned to higher level contractor work breakdown structure elements and undistributed budgets. It equals the total allocated budget less management reserves.

Portfolio. A collection of investments in strategies, such as R&D investigations, managed to further a common goal or goals. Primary Risks. Those undesirable events having both high probability and high impact/severity.

Principal Investigator. Leader of relatively small basic or applied research activity which is part of a larger portfolio of research investments. In some cases, principal investigators from industry and academia act as project managers for development efforts with NASA personnel providing oversight.

Probabilistic Risk Assessment (PRA). A comprehensive, structured, and logical analysis method aimed at identifying and assessing risks in complex technological systems for the purpose of cost-effectively improving their safety and performance in the face of uncertainties. PRA assesses risk metrics and associated uncertainties relating to likelihood and severity of events adverse to safety or mission.

Program. A strategic investment by a Mission Directorate (or Mission Support Office) that has defined goals, objectives, architecture, funding level, and a management structure that supports one or more projects.

Program Commitment Agreement (PCA). The contract between the Administrator and the cognizant MDAA (or MSOD) for implementation of a program.

Program Implementation Review (PIR). A program review conducted by the IPAO after the NAR approval that assesses the program's continued consistency with NAR Baseline commitments (performance, safety, cost, and schedule) in a PCA, Program Plan, and/or Project Plans. The results of this review are reported to the Agency PMC. PIRs are nominally scheduled at approximately two-year intervals during implementation.

Program (or Project) Management Committee (PMC). One of the hierarchy of forums, composed of senior management, that assesses program or project planning and implementation, and provides oversight and direction as appropriate. These are established at the Agency, Mission Directorate, Center, and lower levels.

Program Operating Plan (POP). A document produced by a Center in response to Headquarters-directed budget guidelines, including requested budgets by program or project.

Program Plan. The document that establishes the baseline for implementation, signed by the MDAA (or MSOD), Center Director, and Program Manager.

Program (Project) Team. All participants in program (project) formulation and implementation. This includes all direct reports and others that support meeting program (project) responsibilities.

Project. A specific investment identified in a Program Plan having defined goals, objectives, requirements, life-cycle cost, a beginning, and an end.

Project Plan. The document that establishes the baseline for implementation, signed by the cognizant Program Manager, Center Director, and Project Manager.

Quality Assurance. A planned and systematic set of actions necessary to provide confidence that the products or services conform to documented requirements.

Requirements Review (RR). An assessment, during the formulation process, of the completeness, consistency, and achievability of the project objectives and requirements, including those specified in the FAD. The RR covers, as applicable, mission, project, science, operational, flight system and ground system requirements, including cost and schedule. The RR is conducted prior to the initiation of preliminary design.

Reserves. The APA and contingency resources.

Resources Management. A function that is composed of planning and monitoring implementation of cost, workforce, and facility requirements; correlating these requirements to technical and schedule performance; and comparing these parameters to baselines established for the program and projects. This function establishes, monitors, and updates budget development and execution and contractor financial reporting.

Risk. The combination of the probability that a program or project will experience an undesired event (some examples include a cost overrun, schedule slippage, safety mishap, health problem, malicious activities, environmental impact, failure to achieve a needed scientific or technological breakthrough or mission success criteria) and the consequences, impact, or severity of the undesired event, were it to occur. Both the probability and consequences may have associated uncertainties.

Risk Assessment. An evaluation of a risk item that determines (1) what can go wrong, (2) how likely is it to occur, and (3) what the consequences are.

Risk Management. An organized, systematic decision making process that efficiently identifies, analyzes, plans, tracks, controls, communicates, and documents risk to increase the likelihood of achieving program/project goals.

Root Cause. One of multiple factors (events, conditions, or organizational factors) that contributed to or created the proximate cause and subsequent undesired outcome and, if eliminated or modified, would have prevented the undesired outcome. Typically, multiple root causes contribute to an undesired outcome.

Safety. Freedom from those conditions that can cause death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment.

Schedule Management. The establishment, monitoring, and maintenance of the baseline master schedule and derivative detailed schedules. It is composed of the establishment and operation of the system and includes (1) definition of format, content, symbology, and control processes, and (2) selection of key progress milestones and indices for measuring program and project performance and indicating problems.

Security. Protection of people, property, and information assets owned by NASA which covers physical assets, personnel, IT, communications, and operations.

Spiral Development. A form of evolutionary acquisition in which a desired goal or functional capability is identified, but the end-state requirements are not known at the outset. Those requirements are refined through test and demonstration, risk management, and continual user/operator feedback. Each spiral is an incremental step toward the desired goal or functional capability. Spiral development is seen as an approach to rapidly field systems incorporating the latest available technologies resulting from technology maturation investments. In spiral development, the product to be delivered is not specified at the outset, but instead, contractors and the Agency work in partnership to find the best way to meet the desired goal or functional capability.

Stakeholder. An individual or organization having an interest (or stake) in the outcome or deliverable of a program or project.

Success Criteria. That portion of the top-level requirements that define what will be achieved to successfully satisfy the Strategic Plan objectives addressed by the program, project, or technology demonstration.

Surveillance (Project Evaluation Context). An on-going assessment after the NAR approval conducted by the designated IA organization that examines project performance against the NAR Baseline. Adverse trends are reported to the GPMC.

Surveillance (Acquisition Context). The continual monitoring and verification of status of an entity and analysis of records to ensure that specified requirements are being met. Surveillance can be performed in an insight, oversight, or a combined mode, using a risk-based decision process.

System. The combination of elements that function together to produce the capability required to meet a need. The elements include all hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose.

System-of-Interest. A system whose life-cycle engineering and technical management processes are the subjects of this document. The definition of a particular system- of-interest to be engineered depends on the practitioner's responsibilities, scope of assignment, and interest. For example, within a hierarchy of systems, one person's system-of-interest may be viewed as an element in another person's higher-level system-of-interest.

Systems Engineering. A disciplined approach for the definition, implementation, integration and operation of a system (product or service). The emphasis is on achieving stakeholder functional, physical and operational performance requirements in the intended use environments over its planned life within cost and schedule constraints. Systems engineering includes the engineering processes and technical management processes that consider the interface relationships across all elements of the system, other systems or as a part of a larger system.

System-of-Systems. A set or arrangement of independent systems that are related or connected to provide a given capability. The loss of any part of the system (-of-systems) will degrade the performance or capabilities of the whole. Typically a system will be called a system-of-systems when the component systems achieve well-substantiated purposes in their own right even if detached from the overall system; and when the component systems are managed in large part for their own purposes rather than the purposes of the whole.

Systems Management Office. The Center organization responsible for independent review and assessment of programs and projects during formulation and implementation, whose findings are reported to the Center GPMC.

Tailoring. The documentation and approval of the adaptation of the process and approach to complying with requirements underlying the specific program or projects. The results of this activity are documented in the FAD, PCA, Program Plan, and/or Project Plan.

Technical Warrant Holder. The person authorized to exercise delegated Technical Authority from the NASA Chief Engineer.

Termination Review. An analysis by the GPMC or by an independent assessment board, i.e., IPAO or SMO, for the purpose of securing a recommendation as to whether to continue or terminate a program or project. Exceeding the parameters or levels specified in controlling documents will result in GPMC consideration of a termination review.

Terms of Reference. A formal agreement between a Mission Directorate (or Mission Support Office) and an IA organization specifying the nature, scope, schedule, and ground rules for a program or project independent assessment.

Threshold Value. The minimum quantitative KPP performance level that the MDAA (or MSOD) and Program Manager agree is acceptable for the system-of-interest or end item deliverable.

Trade Study. A technique for comparing alternatives for the purpose of deciding which of them is preferred. Trade studies (also known as trade-off analyses) support decisions throughout the systems engineering process, including (but not limited to) functional allocation choices, performance requirements definition, physical architecture and design choices, technology selection, and risk management. Trade studies may be formal, as in the case of an Analysis of Alternatives (AoA), or informal using engineering judgment or "back-of-the-envelope" analyses, but in either case, the selection of the preferred alternative is based on specific quantitative criteria.

Trusted Agent. A NASA civil servant (or JPL employee) chosen by a System Technical Warrant Holder to assist on technical decisions, deviations, and waivers affecting safe and reliable operations.

Validated Requirements. A set of requirements that are well-formed (clear and unambiguous), complete (agrees with customer and stakeholder needs and expectations) and consistent (conflict-free); and each requirement is verifiable and traceable to a higher-level requirement or goal.

Validation. Proof that the product accomplishes the intended purpose. May be determined by a combination of test, analysis, and demonstration.

Verification. Proof of compliance with specifications. May be determined by a combination of test, analysis, demonstration, and inspection.

Waiver. A documented agreement intentionally releasing a program or project from meeting a requirement. (Some Centers use deviations prior to Implementation, and waivers during Implementation.)

Work Breakdown Structure (WBS). A product-oriented hierarchical division of the hardware, software, services, and data required to produce the program/project's end product(s), structured according to the way the work will be performed, and reflective of the way in which program/ project costs, schedule, technical and risk data are to be accumulated, summarized, and reported.


APPENDIX N. Acronyms


AO Announcement of Opportunity
AoA Analysis of Alternatives
APA Allowance for Program Adjustment
APPL Academy of Program and Project Leadership
ATD Advanced Technology Development
BAA Broad Agency Announcement
BAC Budget At Complete
CADRe Cost Analysis Data Requirement
CAIB Columbia Accident Investigation Board
CAIV Cost as An Independent Variable
CAN Cooperative Agreement Notice
CARD Cost Analysis Requirements Description (DoD)
CCRM Continuous Cost Risk Management
CD Center Director
CDR Critical Design Review
CEO Chief Education Officer
CERT Cost Estimation Reconciliation Team
CIO Chief Information Officer
CMP Center Real Property Master Plan
CoF Construction of Facilities
ConOps Concept of Operations
CPR Cost Performance Report
CRADA Commercial Research and Development Agreement
CRM Continuous Risk Management
CS Civil Service
DCMA Defense Contract Management Agency
DoD Department of Defense
DRD Data Requirement Description
DRFP Draft Request for Proposal
EA Enterprise Architecture
EA Environmental Assessment
EAC Estimate At Completion
ECR Environmental Compliance and Restoration
EVM Earned Value Management
EVMS Earned Value Management System
FAD Formulation Authorization Document
FAR Federal Acquisition Regulation
FMEA Failure Modes and Effects Analysis
FOC Full Operational Capability
FOIA Freedom of Information Act
FPM Facility Project Manager
FTA Fault Tree Analysis
FTE Full-Time Equivalent
FY Fiscal Year
GAO Government Accountability Office
GFE Government Furnished Equipment
GFY Government Fiscal Year
GPMC Governing Program Management Council
GPRA Government Performance and Results Act
HBCU Historically Black Colleges and Universities
IA Independent Assessment
IBPD Integrated Budget and Performance Document
IBR Integrated Baseline Review
IC Institutional Committee
ICA Independent Cost Analysis
ICE Independent Cost Estimate
IDP Individual Development Plans
IFMS Integrated Financial Management System
ILCCA Independent Life-Cycle Cost Analysis
ILS Integrated Logistics Support
IMS Integrated Master Schedule
IOC Initial Operational Capability
IRAD In-house Research and Development
ISO International Standards Organization
IPAO Independent Program Assessment Office
IRT Independent Review Team
IT Information Technology
ITA Independent Technical Authority
IV&V Independent Verification & Validation
KPP Key Performance Parameter
LCC Life-Cycle Cost
LCCE Life-Cycle Cost Estimate
LLIS Lessons Learned Information System
MDAA Mission Directorate Associate Administrator
MO&DA Mission Operations and Data Analysis
MSOD Mission Support Office Director
NAR Non-Advocate Review
NDA Non-Disclosure Agreement
NEPA National Environmental Policy Act
NESC NASA Engineering and Safety Center
NFS NASA Federal Acquisition Regulation (FAR) Supplement
NOA New Obligational Authority
NODIS NASA On-Line Directives Information System
NPD NASA Policy Directive
NPG NASA Procedures and Guidelines
NPR NASA Procedural Requirements
NRA NASA Research Announcement
OAIT Office Automation and Infrastructure Technology
OCE Office of the Chief Engineer
OCFO Office of the Chief Financial Officer
OCIO Office of the Chief Information Officer
OCS Office of the Chief Scientist
OFI Other Functional Initiative
OMB Office of Management and Budget
ONCE One NASA Cost Engineering
OSHA Occupational Safety and Health Administration
OSMA Office of Safety and Mission Assurance
PA&R Program Audit and Review (OSMA)
P3I Pre-planned Product Improvement
PCA Program Commitment Agreement
PDR Preliminary Design Review
PI Principal Investigator
PIR Program Implementation Review
PMC Program Management Committee
POP Program Operating Plan
PRA Probabilistic Risk Assessment
PSR Project Status Report
QSR Quarterly Status Report
RFP Request for Proposal
ROI Return On Investment
RR Requirements Review
SBIR Small Business Innovation Research
SI International System of Units measurement system (Systeme Internationale)
SMA Safety and Mission Assurance
SMAR Safety and Mission Assurance Readiness Review
SMO Systems Management Office
SMP Schedule Management Plan
SOMD Space Operations Mission Directorate
SoS System-of-Systems
STEM Science, Technology, Engineering, and Mathematics
SWH System Warrant Holder
ToR Terms of Reference
TRL Technology Readiness Level
TWH Technical Warrant Holder
V&V Verification and Validation
WBS Work-Breakdown Structure

APPENDIX O. NPR 7120.5C Requirements Deviations and Waivers


This Appendix provides information to guide requests for deviations or waivers to requirements provided in this document.

Requests for deviations or waivers to NPR 7120.5 requirements shall be documented and submitted for approval by the Project Manager, the Program Manager, and the Governing PMC. The GPMC for Category I projects is the Agency PMC. For Category II projects the GPMC is the Mission Directorate PMC. The Center PMC is the GPMC for Category III projects.

Prior to the NAR, these requests shall be documented in the NPR 7120.5 compliance matrix and attached to a single deviation or waiver to assure proper routing and control. Deviations or waivers impacting formulation or requiring long lead-time shall be submitted individually early in formulation. Following the NAR, deviations or waivers must be submitted individually to the appropriate authority.



DISTRIBUTION:
NODIS


This Document is Obsolete and Is No Longer Used.
Check the NODIS Library to access the current version:
http://nodis3.gsfc.nasa.gov