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.5E
Effective Date: August 14, 2012
Cancellation Date:
Responsible Office: KA

NID 7120.130, NASA Space Flight Program and Project Management Requirements - Space Systems Protection Standard Update

NID 7120.122, Joint Cost and Schedule Confidence Level (JCL) Requirements Updates

NASA Standing Review Board Handbook

NASA Space Flight Program and Project Management Handbook

Table of Contents

Change Log

Preface

P.1 Purpose
P.2 Applicability
P.3 Authority
P.4 Applicable Documents and Forms
P.5 Measurment/Verification
P.6 Cancellation

Chapter 1. Introduction

1.1 Key Policy Changes in this NPR
1.2 Background
1.3 Overview of Management Process
1.4 Acquisition
1.5 Document Structure

Chapter 2. NASA Life Cycles for Space Flight Programs and Projects

2.1 Programs and Projects
2.2 Program and Project Life Cycles
2.3 Program and Project Oversight and Approval
2.4 Approving and Maintaining Program and Project Plans, Baselines, and Commitments

Chapter 3. Program and Project Management Roles and Responsibilities

3.1 Governance
3.2 Roles and Responsibilities
3.3 Technical Authority
3.4 Process for Handling Dissenting Opinion
3.5 Principles Related to Tailoring Requirements
3.6 Reimbursable Space Flight Work
3.7 Use of the Metric System

Appendix A. Definitions
Appendix B. Acronyms
Appendix C. Compliance Matrix
Appendix D. Program Commitment Agreement Template
Appendix E. Formulation Authorization Document Template
Appendix F. Project Formulation Agreement Template
Appendix G. Program Plan Template
Appendix H. Project Plan Template
Appendix I. Program and Project Products by Phase
Appendix J. References

List of Tables

Table 1-1 Programmatic Requirements Hierarchy
Table 2-1 Project Categorization Guidelines
Table 2-2 Convening Authorities for Standing Review Board
Table 2-3 Expected Maturity State Through the Life Cycle of Uncoupled and Loosely Coupled Programs
Table 2-4 Expected Maturity State Through the Life Cycle of Tightly Coupled Programs
Table 2-5 Expected Maturity State Through the Life Cycle of Projects and Single-Project Programs
Table 2-6 Objectives for Other Reviews
Table 3-1 Waiver Approval Authority for NPR 7120.5 Requirements
Table D-1 Sample Program Commitment Agreement Activities Log
Table I-1 Uncoupled and Loosely Coupled Program Milestone Products and Control Plans Maturity Matrix
Table I-2 Tightly Coupled Program Milestone Products Maturity Matrix
Table I-3 Tightly Coupled Program Plan Control Plan Maturity Matrix
Table I-4 Project Milestone Products Maturity Matrix
Table I-5 Project Plan Control Plan Maturity Matrix
Table I-6 Single-Project Program Milestone Products Maturity Matrix
Table I-7 Single-Project Program Plan Control Plans Maturity Matrix

List of Figures

Figure 1-1 Institutional Requirements Flow Down
Figure 2-1 Programmatic Authority Organizational Hierarchy
Figure 2-2 NASA Uncoupled and Loosely Coupled Program Life Cycle
Figure 2-3 NASA Tightly Coupled Program Life Cycle
Figure 2-4 NASA Single-Project Program Life Cycle
Figure 2-5 NASA Project Life Cycle
Figure 2-6 Example of Agreements and Commitments in Terms of Cost for Projects
Figure D-1 Program Commitment Agreement Title Page
Figure E-1 Program Formulation Authorization Document Title Page
Figure E-2 Project Formulation Authorization Document Title Page
Figure F-1 Formulation Agreement Title Page
Figure G-1 Program Plan Title Page
Figure H-1 Project Plan Title Page
Figure H-2 Standard Level 2 WBS Elements for Space Flight Projects

Change Log

Preface

P.1 Purpose

This document establishes the requirements by which NASA formulates and implements space flight programs and projects, consistent with the governance model contained in NASA Policy Directive (NPD) 1000.0, NASA Governance and Strategic Management Handbook.

P.2 Applicability

a. This NASA Procedural Requirements (NPR) is applicable to NASA Headquarters and NASA Centers, including Component Facilities and Technical and Service Support Centers. This language applies to the Jet Propulsion Laboratory, a Federally Funded Research and Development Center, other contractors, grant recipients, or parties to agreements only to the extent specified or referenced in the appropriate contracts, grants, or agreements.

b. This NPR applies to all NASA space flight programs and projects (including spacecraft, launch vehicles, instruments developed for space flight programs and projects, research and technology developments funded by and to be incorporated into space flight programs and projects, critical technical facilities specifically developed or significantly modified for space flight systems, highly specialized Information Technology (IT) acquired as a part of space flight programs and projects (non-highly specialized IT is subject to NPR 7120.7), and ground systems that are in direct support of space flight operations). This NPR also applies to reimbursable space flight programs and projects performed for non-NASA sponsors and to NASA contributions to space flight programs and projects performed with international and interagency partners.

c. For existing programs and projects, the requirements of this NPR apply to their current and future phases as determined by the responsible Mission Directorate, approved by the NASA Chief Engineer (or as delegated), and concurred with by the Decision Authority.

d. This NPR can be applied to other NASA investments at the discretion of the responsible manager or the NASA Associate Administrator.

e. In this directive, all mandatory actions (i.e., requirements) are denoted by statements containing the term "shall." The terms "may" or "can" denote discretionary privilege or permission, "should" denotes a good practice and is recommended but not required, "will" denotes expected outcome, and "are/is" denotes descriptive material.

f. In this directive, all document citations are assumed to be the latest version unless otherwise noted.

P.3 Authority

a. The National Aeronautics and Space Act, as amended, 51 U.S.C. § 20113(a).

b. NPD 1000.0, NASA Governance and Strategic Management Handbook.

c. NPD 1000.3, The NASA Organization.

d. NPD 1000.5, Policy for NASA Acquisition.

e. NPD 7120.4, NASA Engineering and Program/Project Management Policy.

P.4 Applicable Documents And Forms

a. Federal Participation in the Development and Use of Voluntary Consensus Standards and in Conformity Assessment Activities, OMB Circular No. A-119.

b. NPD 1001.0, NASA Strategic Plan.

c. NPD 1200.1, NASA Internal Control.

d. NPD 1210.2, NASA Surveys, Audits, and Reviews Policy.

e. NPR 7120.10, Technical Standards for NASA Programs and Projects.

f. NPR 7123.1, NASA Systems Engineering Processes and Requirements.

g. NPR 8705.4, Risk Classification for NASA Payloads.

h. NPR 8715.3, NASA General Safety Program Requirements.

i. NPR 8900.1, Health and Medical Requirements for Human Space Exploration.

j. NASA-STD-8709.20, Management of Safety and Mission Assurance Technical Authority (SMA TA) Requirements.

k. ANSI/EIA-748, Standard for Earned Value Management Systems.

P.5 Measurement/Verification

a. Compliance with this document is verified by submission to responsible NASA officials of the gate products identified in this document at Key Decision Points (KDPs), by submission of milestone products and control plans due at life-cycle reviews, and by internal and external controls. Internal controls are consistent with processes defined in NPD 1200.1, NASA Internal Control. Internal controls include surveys, audits, and reviews conducted in accordance with NPD 1210.2, NASA Surveys, Audits, and Reviews Policy. External controls may include external surveys, audits, and reporting requirements.

b. Compliance is also documented by appending a completed Compliance Matrix for this NPR (see Appendix C) to the Formulation Agreement for projects in Formulation and/or the Program Plan or Project Plan (see appendices G or H) for programs or projects entering or in Implementation. A copy of the Compliance Matrix is forwarded to the Office of the Chief Engineer.

P.6 Cancellation

a. NPR 7120.5D, NASA Space Flight Program and Project Management Requirements, dated March 6, 2007.

b. NID 7120-97, NASA Interim Directive (NID): NASA Space Flight Program and Project Management Requirement, dated, September 28, 2011.

/S/
Mike Ryschkewitsch
NASA Chief Engineer

Chapter 1. Introduction

1.1 Key Policy Changes in this NPR

1.1.1 This NASA Procedural Requirements (NPR) has been substantially restructured to streamline the requirements for space flight programs and projects and place complementary guidance and contextual information into a companion handbook. The NASA Space Flight Program and Project Management Handbook describes how programs and projects are managed in NASA and contains explanatory material to help understand the requirements of this NPR. The Handbook can be found on the "Other Policy Documents" menu in the NASA On-Line Directives Information System (NODIS) under the tab for Office of the Chief Engineer. The requirements of this NPR may be tailored in accordance with Section 3.5.

1.1.2 NASA Centers, Mission Directorates, and other organizations that have programs or projects shall develop appropriate documentation to implement the requirements of this document.

1.1.3 For existing programs and projects, this NPR's requirements apply to their current and future phases as determined by the responsible Mission Directorate, approved by the NASA Chief Engineer (or as delegated), and concurred with by the Decision Authority. The Mission Directorate shall submit their plan for phased tailoring of the requirements of this NPR within 60 days of the NPR's effective date.

1.2 Background

1.2.1 NASA space flight programs and projects develop and operate a wide variety of spacecraft, launch vehicles, in-space facilities, communications networks, instruments, and supporting ground systems.¹ This document establishes a standard of uniformity for the process by which NASA formulates and implements space flight programs and projects.

¹ NASA space flight programs and projects often need to mature technologies to meet mission goals. These enabling and/or enhancing technologies are also covered by this NPR.

1.2.2 NASA approaches the formulation and implementation of programs and projects through a governance model that balances different perspectives from different elements of the organization. The cornerstone of program and project governance is the organizational separation of the Mission Directorates and their respective programs and projects (Programmatic Authorities) from the Headquarters Mission Support Offices, the Center organizations that are aligned with these Mission Support Offices, and the Center Directors (Institutional Authorities). (See NASA Policy Directives (NPD) 1000.0, NASA Governance and Strategic Management Handbook and the NASA Space Flight Program and Project Management Handbook.)

1.2.3 This NPR distinguishes between "programmatic requirements" and "institutional requirements." Both categories of requirements ultimately need to be satisfied in program and project Formulation and Implementation.

1.2.3.1 Programmatic requirements are the responsibility of the Programmatic Authorities. Programmatic requirements focus on the products to be developed and delivered and specifically relate to the goals and objectives of a particular NASA program or project. These programmatic requirements flow down from the Agency's strategic planning process. Table 1-1 shows this flow down from Agency strategic planning through Agency, directorate, program, and project requirement levels to the systems that will be implemented to achieve the Agency goals.

Table 1-1 Programmatic Requirements Hierarchy

1.2.3.2 Institutional requirements are the responsibility of the Institutional Authorities. (See Section 3.3 for details on Technical Authority.) They focus on how NASA does business and are independent of any particular program or project. These requirements are issued by NASA Headquarters (including the Office of the Administrator and Mission Support Offices) and by Center organizations. Institutional requirements may respond to Federal statute, regulation, treaty, or Executive Order. They are normally documented in NPDs, NPRs, NASA Standards, Center Policy Directives (CPDs), Center Procedural Requirements (CPRs), and Mission Directorate requirements.

1.2.4 This NPR is focused on improving program and project performance against internal and external commitments. Figure 1-1 shows the flow down from NPD 1000.0, NASA Governance and Strategic Management Handbook through Program and Project Plans. The figure identifies the five types of institutional requirements that flow down to these plans: engineering, program/project management, safety and mission assurance, health and medical, and Mission Support Office (MSO) functional requirements. These terms are defined in Appendix A.

Figure 1-1 Institutional Requirements Flow Down

1.3 Overview of Management Process

1.3.1 Although this document emphasizes program and project management based on life cycles, Key Decision Points (KDPs), and evolving products during each life-cycle phase, these are embedded in NASA's four-part process for managing programs and projects, which consists of:

a. Formulation—identifying how the program or project supports the Agency's strategic goals; assessing feasibility, technology, concepts, and performance of trade studies; risk assessment and possible risk mitigations based on risk-informed decision making (RIDM) and continuous risk management (CRM) processes; team building; development of operations concepts and acquisition strategies; establishing high-level requirements, requirements flow down, and success criteria; assessing the relevant industrial base/supply chain to ensure program or project success; preparing plans, cost estimates, budget submissions, and schedules essential to the success of a program or project; and establishing control systems to ensure performance of those plans and alignment with current Agency strategies.

b. Approval (for Implementation)—acknowledgment by the Decision Authority (see Appendix A for definition of "Decision Authority") that the program/project has met Formulation requirements and is ready to proceed to Implementation. By approving a program/project, the Decision Authority commits to the time-phased cost plan based on technical scope and schedule necessary to continue into Implementation.

c. Implementation—execution of approved plans for the development and operation of the program/project, and use of control systems to ensure performance to approved plans and requirements and continued alignment with the Agency's strategic goals.

d. Evaluation—continual self- and independent assessment of the performance of a program or project and incorporation of the assessment findings to ensure adequacy of planning and execution according to approved plans and requirements.

1.4 Acquisition

1.4.1 NASA's program and project support of its overall mission is long term in nature, but the environments in which these programs and projects are conducted are dynamic. In recognition of this, NPD 1000.0, NASA Governance and Strategic Management Handbook and NPD 1000.5, Policy for NASA Acquisition have put in place a framework for ensuring that NASA's strategic vision, programs and projects, and resources remain properly aligned. The acquisition process and annual strategic resource planning form a continuous process to oversee this alignment. At the program and project level, the Acquisition Strategy Meeting (ASM) and the Procurement Strategy Meeting (PSM) support the Agency's acquisition process, which includes strategic planning, as well as procurement. The PSM is in NASA FAR Supplement (NFS) 1807.170. The PSM guide is at http://prod.nais.nasa.gov/portals/pl/documents/PSMs_091611.html.

1.5 Document Structure

1.5.1 Chapter 2 defines the different types of programs and projects, their documents, and how they mature through their different life cycles. It also describes how to establish baselines and approval processes. Chapter 3 describes roles and responsibilities relevant to program and project managers, the governance structure, Technical Authority, the dissenting opinion process, and how to tailor requirements. Appendix C contains the Compliance Matrix. Templates for required program and project documents are contained in appendices D through H. Appendix I encompasses the tables of program and project products by phase. Appendix J provides a list of references.

Chapter 2. NASA Life Cycles for Space Flight Programs and Projects

2.1 Programs and Projects

2.1.1 Space flight programs and projects flow from the implementation of national priorities, defined in the Agency's Strategic Plan, through the Agency's Mission Directorates, as part of the Agency's general work breakdown hierarchy shown in Figure 2-1.

Figure 2-1 Programmatic Authority Organizational Hierarchy

This hierarchical relationship of programs to projects shows that programs and projects are different and their management involves different activities and focus. The following definitions are used to distinguish the two:

a. Program - a strategic investment by a Mission Directorate or Mission Support Office that has a defined architecture and/or technical approach, requirements, funding level, and a management structure that initiates and directs one or more projects. A program implements a strategic direction that the Agency has identified as needed to accomplish Agency goals and objectives.

b. Project - space flight projects are a specific investment identified in a Program Plan having defined requirements, a life-cycle cost, a beginning, and an end. A project also has a management structure and may have interfaces to other projects, agencies, and international partners. A project yields new or revised products that directly address NASA's strategic goals.

Regardless of the structure of a program or project meeting the criteria of Section P.2, this NPR shall apply to the full scope of the program or project and all the activities under it. Specific NPR 7120.5 requirements are flowed down to these activities to the extent necessary for the program or project to ensure compliance and mission success. See Section 3.5.6.1 for the process of obtaining any required deviations or waivers.

2.1.2 NASA Programs

2.1.2.1 NASA space flight programs are initiated and implemented to accomplish scientific or exploration goals that generally require a collection of mutually supporting projects. Programs integrate and manage these projects over time and provide ongoing enabling systems, activities, methods, technology developments, and feedback to projects and stakeholders. Programs are generally created by a Mission Directorate with a long-term time horizon in mind, though as the Agency's strategic direction or circumstances change, a Mission Directorate occasionally needs to replan its programs or combine related programs to increase effectiveness. Programs are generally executed at NASA Centers under the direction of the Mission Directorate and are assigned to Centers based on decisions made by Agency senior management consistent with the results of the Agency's strategic acquisition planning process. Because the scientific and exploration goals of programs vary significantly, different program implementation strategies are required, ranging from very simple to very complex. To accommodate these differences, NASA identifies four basic types of programs (defined in Appendix A) that may be employed: single-project programs, uncoupled programs, loosely coupled programs, and tightly coupled programs.

2.1.3 Single-Project Programs

2.1.3.1 Single-project programs are programs that implement their program objectives and requirements through one of two management approaches: (1) separate program and project structures or (2) a combined structure. The requirements for both programs and projects apply to single-project programs as described in the NPR.

2.1.4 NASA Projects

2.1.4.1 As with programs, projects vary in scope and complexity and thus require varying levels of management requirements and Agency attention and oversight. Consequently, project categorization defines Agency expectations of project managers by determining both the oversight council and the specific approval requirements. Projects are Category 1, 2, or 3 and shall be assigned to a category based initially on: (1) the project life-cycle cost (LCC) estimate, the inclusion of significant radioactive material ² , and whether or not the system being developed is for human space flight; and (2) the priority level, which is related to the importance of the activity to NASA, the extent of international participation (or joint effort with other government agencies), the degree of uncertainty surrounding the application of new or untested technologies, and spacecraft/payload development risk classification. (See NPR 8705.4, Risk Classification for NASA Payloads.) Guidelines for determining project categorization are shown in Table 2-1, but categorization may be changed based on recommendations by the Mission Directorate Associate Administrator (MDAA) that consider additional risk factors facing the project. The NASA Associate Administrator (AA) approves the final project categorization. The Office of the Chief Engineer (OCE) is responsible for the official listing of NASA programs and projects. ³ For purposes of project categorization, the project life-cycle cost estimate includes phases A through F and all Work Breakdown Structure (WBS) Level 2 elements and is measured in real-year (nominal) dollars.

² Nuclear safety launch approval is required by the Administrator or Executive Office of the President when significant radioactive materials are included on board the spacecraft and/or launch vehicle. (Levels are defined in NPR 8715.3, NASA General Safety Program Requirements.)

³ This data is maintained by the Office of Chief Financial Officer in a database called the Meta-Data Manager (MdM). This database is the basis for the Agency's work breakdown and forms the structure for program and project status reporting across all Mission Directorates and Mission Support Offices.

Table 2-1 Project Categorization Guidelines

Note: Small Category 3, Class D projects with a life-cycle cost of under $150 million should refer to guidance on tailoring NPR 7120.5 requirements from the NASA AA, which can be found on the OCE tab in NODIS under "Other Policy Documents" at http/nodis3.gsfc.nasa.gov/OCE_docs/OCE_25.pdf.

2.1.4.2 When projects are initiated, they are assigned to a NASA Center or implementing organization by the MDAA consistent with direction and guidance from the strategic planning process. They are either assigned directly to a Center by the Mission Directorate or are selected through a competitive process such as an Announcement of Opportunity (AO). ⁴ For Category 1 projects, the assignment shall be with the concurrence of the NASA AA.

⁴ As part of the process of assigning projects to NASA Centers, the affected program manager may recommend project assignments to the MDAA.

2.1.5 Program and Project Manager Certification

2.1.5.1 Programs and projects with a life-cycle cost greater than $250 million will be managed by program and project managers who have been certified in compliance with Office of Management and Budget (OMB)'s promulgated Federal acquisition program/project management certification requirements. This certification is required within one year of appointment. Further information on how NASA is implementing program and project manager certification can be found in the NASA Space Flight Program and Project Management Handbook.

2.2 Program and Project Life Cycles

2.2.1 Programs and projects shall follow their appropriate life cycle, which includes life-cycle phases; life-cycle gates and major events, including KDPs; major life-cycle reviews (LCRs); principal documents that govern the conduct of each phase; and the process of recycling through Formulation when program changes warrant such action. Uncoupled and loosely coupled programs follow the life cycle depicted in Figure 2-2. Tightly coupled programs follow the life cycle shown in Figure 2-3. Single-project programs follow the life cycle shown in Figure 2-4. Projects follow the life cycle shown in Figure 2-5.

2.2.2 Each program and project performs the work required for each phase, which is described in the NASA Space Flight Program and Project Management Handbook; the NASA Project Planning and Control Handbook, which covers the functions and activities of the planning and control community; and NPR 7123.1. This work shall be organized by a product-based WBS developed in accordance with the Program and Project Plan templates (appendices G and H). When an alternate approach provides for better program/project implementation, the program/project manager should tailor the requirement as noted in the Compliance Matrix. (See Appendix C.)

2.2.3 The documents shown on the life-cycle figures and described below shall be prepared in accordance with the templates in appendices D, E, F, G, and H.

Figure 2-2 NASA Uncoupled and Loosely Coupled Program Life Cycle

Figure 2-3 NASA Tightly Coupled Program Life Cycle

Figure 2-4 NASA Single-Project Program Life Cycle

Figure 2-5 NASA Project Life Cycle

2.2.3.1 The program Formulation Authorization Document (FAD) (see Appendix E) is prepared by the Mission Directorate and authorizes a program manager to initiate the planning of a new program and to perform the analysis of alternatives required to formulate a sound Program Plan that contains project elements, requirements, schedules, and time-phased cost plans.

2.2.3.2 The PCA (see Appendix D) is an agreement between the MDAA and the NASA AA (the Decision Authority) that authorizes program transition from Formulation to Implementation. The PCA is prepared by the Mission Directorate and documents Agency requirements that flow down to the program, Mission Directorate requirements, program objectives, management and technical approach and associated architecture, technical performance, schedule, time-phased cost plans, safety and risk factors, internal and external agreements, life-cycle reviews, and all attendant top-level program requirements.

2.2.3.3 The Program Plan (see Appendix G) is an agreement between the MDAA (who has final approval authority for the plan), the participating Center Director(s), and the program manager. It documents at a high level the program's objectives and requirements, scope, implementation approach, interfaces with other programs, environment within which the program operates, funding by time-phased cost plans consistent with the approved PCA, and commitments of the program. The Program Plan is prepared by the program.

2.2.3.4 The project FAD (see Appendix E) is prepared by the Mission Directorate. It authorizes a project manager to initiate the planning of a new project and to perform the analysis of alternatives required to formulate a sound Formulation Agreement and subsequent Project Plan and contains requirements, schedules, and project funding requirements.

2.2.3.5 The Formulation Agreement (see Appendix F) is prepared by the project in response to the FAD to establish the technical and acquisition work that needs to be conducted during Formulation and defines the schedule and funding requirements during Phase A and Phase B for that work.

2.2.3.6 The Project Plan (see Appendix H) is an agreement among the MDAA; the program manager; participating Center Director(s); the project manager; and for AO-selected missions, the principal investigator. ⁵ The Project Plan is prepared by the project manager with the support of the project team and defines at a high level the project's objectives, technical and management approach, environment within which the project operates, and commitments of the project to the program.

⁵ A principal investigator is a person who conceives an investigation and is responsible for carrying it out and reporting its results. In some cases, principal investigators from industry and academia act as project managers for smaller development efforts with NASA personnel providing oversight.

2.2.4 Each program and project shall perform the LCRs identified in its respective figure in accordance with NPR 7123.1, applicable Center practices, and the requirements of this document. These reviews provide a periodic assessment of the program's or project's technical and programmatic status and health at key points in the life cycle using six criteria: alignment with and contribution to Agency strategic goals, adequacy of management approach, adequacy of technical approach, adequacy of the integrated cost and schedule estimates and funding strategy, adequacy and availability of resources other than budget, and adequacy of the risk management approach. (See NPR 8000.4 Agency Risk Management Procedural Requirements and NASA/SP-2011-3422 NASA Risk Management Handbook for further requirements and guidance on risk management and the NASA Space Flight Program and Project Management Handbook for further guidance on addressing the expected maturity for each of these criteria). Life-cycle reviews that occur at the end of each life-cycle phase are complete when the governing Program Management Council (PMC) and Decision Authority complete their assessment and sign the Decision Memorandum (see paragraph 2.4.1).

2.2.4.1 The need for a PIR is determined in one of two ways:

a. The NASA AA determines the need for a PIR based on the occurrence of a trigger and discussion with the CAs. The MDAA or an independent team member (TAs, OCFO) report to the NASA AA that a trigger for discussing the need for a PIR has occurred. This is reported at the APMC during the annual review of MD IA Manifests. (For considerations that trigger a discussion on the need for a PIR see Considerations for a PIR in Appendix A.)

b. The NASA AA or MDAA, per their discretion, determine that a PIR is needed.

2.2.5 The program or project and an independent Standing Review Board (SRB) shall conduct the SRR, SDR/MDR, PDR, CDR, SIR, ORR, and PIR LCRs in figures 2-2, 2-3, 2-4, and 2-5. The Decision Authority may request the SRB to conduct other reviews identified on the figures or special reviews identified in paragraph 2.2.9. LCRs that do not require an SRB will be convened by the Center Director (or designee) of the Center responsible for the program or project management. The program or project manager determines whether one- or two-step reviews will be conducted. (See the NASA Standing Review Board Handbook and the NASA Space Flight Program and Project Management Handbook for further guidance on the review processes conducted by the SRB.) Small Category 3, Class D projects with a life-cycle cost of under $150 million should refer to guidance on using an independent review team to perform independent assessments of the project in place of an SRB. Guidance can be found on the OCE tab in NODIS under Other Policy Documents at http/nodis3.gsfc.nasa.gov/OCE_docs/OCE_25.pdf.)

2.2.5.1 NASA accords special importance to the policies and procedures established to ensure the integrity of the SRB's independent review process and to comply with Federal law. The Conflict of Interest (COI) procedures detailed in the NASA Standing Review Board Handbook shall be strictly adhered to.

2.2.5.2 The portion of the LCRs conducted by the SRB shall be convened by the Convening Authorities in accordance with Table 2-2. The scope and requirements for this review will be documented in a Terms of Reference (ToR), for which there is a template in the NASA Standing Review Board Handbook.

Table 2-2 Convening Authorities for Standing Review Board

NASA CE = NASA Chief Engineer

*Concurrence is obtained via coordination with designated MD Chief Engineer
** Concurrence is obtained via coordination with designated MD-embedded OCFO point of contact

NOTE: LCR entrance and success criteria in NPR 7123.1 and the life-cycle phase and KDP information in the NASA Space Flight Program and Project Management Handbook provide specifics for addressing the six criteria required to demonstrate the program or project has met expected maturity state.

2.2.5.3 The program or project manager, the SRB chair, and the Center Director (or designated Engineering Technical Authority representative) shall mutually assess the program's or project's expected readiness for the LCR and report any disagreements to the Decision Authority for final decision. The assessment occurs approximately 30 to 90 calendar days prior to the LCR.

2.2.6 In preparation for these LCRs, the program or project shall generate the appropriate documentation per the Appendix I tables of this document, NPR 7123.1, and Center practices, as necessary, to demonstrate that the program's or project's definition and associated plans are sufficiently mature to execute the follow-on phase(s) with acceptable technical, safety, and programmatic risk.

2.2.6.1 For a single-project program that is implemented through separate program and project structures, the MDAA and single-project program manager will determine which of the documents in the tables are produced by the program and which are produced by the project. In both management approaches, the Program and Project Plans may be combined if approved by the MDAA.

2.2.7 Each program and project proceeds through the KDPs identified in its respective life-cycle figure. A KDP is the event where the Decision Authority determines the readiness of a program or project to progress to the next phase of the life cycle and establishes the content, cost, and schedule commitments for the ensuing phase(s). Transition to the following phase occurs immediately following KDP approval except for the transition from Phase D to E, where transition occurs following on-orbit checkout. KDPs associated with uncoupled, loosely coupled, and tightly coupled programs are designated with Roman numerals and zero. The first KDP is KDP 0; the second is KDP I, etc. KDPs for projects and single-project programs are designated with letters, i.e., KDP A, KDP B, etc.

2.2.7.1 For missions selected as a result of an AO, KDP A is the selection of a Step 1 proposal for concept development. In a one-step AO process, projects enter Phase A after selection (KDP A) and the process becomes conventional. In a two-step AO process, projects are down-selected following evaluation of concept study reports and the down-selection serves as KDP B. Following this selection, the process becomes conventional with the exception that products normally required at KDP B that require Mission Directorate input or approval will be finished as early in Phase B as feasible.

2.2.8 Projects in phases C and D (and programs at the discretion of the MDAA) with a life-cycle cost estimated to be greater than $20 million and Phase E project modifications, enhancements, or upgrades with an estimated development cost greater than $20 million shall perform earned value management (EVM) with an EVM system that complies with the guidelines in ANSI/EIA-748, Standard for Earned Value Management Systems. Small Category 3, Class D projects with a life-cycle cost of under $150 million should refer to guidance on implementing the EVM requirements from the NASA AA, which can be found on the OCE tab in NODIS under Other Policy Documents http/nodis3.gsfc.nasa.gov/OCE_docs/OCE_25.pdf. Use of NASA's EVM capability and processes will ensure compliance with the ANSI standard. This capability allows tailoring to match the individual needs of the program or project, while still meeting the ANSI-748 guidelines. NASA's EVM capability can be found on the Program and Project Management Community of Practice at https://nen.nasa.gov/web/pm/evm.

2.2.8.1 EVM system requirements shall be applied to appropriate suppliers, in accordance with the NASA Federal Acquisition Regulation (FAR) Supplement, and to in-house work elements. For contracts that require EVM, an Integrated Program Management Report (IPMR) and a WBS are required deliverables with the appropriate data requirements descriptions (DRDs) included in the contract and/or agreement.

2.2.8.2 For projects requiring EVM, Mission Directorates shall conduct a pre-approval integrated baseline review as part of their preparations for KDP C to ensure that the project's work is properly linked with its cost, schedule, and risk and that the management processes are in place to conduct project-level EVM.

2.2.9 The Office of the Administrator, MDAA, or the Center Director (or designee) may also convene special reviews as they determine the need. In these cases, the MDAA or the Technical Authority forms a special review team composed of relevant members of the SRB and additional outside expert members as needed. The process followed for these reviews is the same as for other reviews. The special review team is dissolved following resolution of the issue(s) that triggered its formation.

2.2.10 Each program and project shall complete and maintain a Compliance Matrix (see Appendix C) for this NPR and attach it to the Formulation Agreement for projects in Formulation and/or the Program or Project Plan. The program or project will use the Compliance Matrix to demonstrate how it is complying with the requirements of this document and verify the compliance of other responsible parties.

2.3 Program and Project Oversight and Approval

2.3.1 Each program and project shall have a Decision Authority, the Agency's responsible individual who determines whether and how the program or project proceeds through the life cycle and the key program or project cost, schedule, and content parameters that govern the remaining life-cycle activities. For programs and Category 1 projects, the Decision Authority is the NASA AA. The NASA AA may delegate this authority to the MDAA for Category 1 projects. For Category 2 and 3 projects, the Decision Authority is the MDAA. The MDAA may delegate some of their Programmatic Authority to appropriate Mission Directorate staff or to Center Directors. Decision authority may be delegated to a Center Director for determining whether Category 2 and 3 projects may proceed through KDPs into the next phase of the life cycle. However, the MDAA will retain authority for all program-level requirements, funding limits, launch dates, and any external commitments. All delegations are documented and approved in the applicable authority document (PCA or Program Plan) depending on which Decision Authority is delegating.

2.3.1.1 The NASA AA shall approve all Agency Baseline Commitments (ABCs) for programs requiring an ABC and projects with a life-cycle cost greater than $250 million. The NASA Administrator's agreement is required for the ABCs for all programs and projects with a life-cycle cost greater than $1 billion and all Category 1 projects. (See paragraph 2.4.1.5 for more information on ABCs.)

2.3.2 To ensure the appropriate level of management oversight, NASA has established two levels of PMCs-the Agency PMC (APMC) and Mission Directorate PMCs (MDPMCs). The PMCs have the responsibility for periodically evaluating the technical, safety, and programmatic performance (including cost, schedule, risk, and risk mitigation) and content of a program or project under their purview. These evaluations focus on whether the program or project is meeting its commitments to the Agency. Each program and project shall have a governing PMC. For all programs and Category 1 projects, the governing PMC is the APMC; for Category 2 and 3 projects, the governing PMC is the MDPMC. The PMC function may be delegated by the Decision Authority to the Center Management Council (CMC) in the event the Decision Authority is delegated to the Center.

2.3.3 The Center Director (or designee) shall oversee programs and projects usually through the CMC, which monitors and evaluates all program and project work (regardless of category) executed at that Center. The CMC evaluation focuses on whether Center engineering, Safety and Mission Assurance (SMA), health and medical, and management best practices (e.g., program and project management, resource management, procurement, institutional best practices) are being followed by the program or project under review and whether Center resources support program/project requirements. The CMC also assesses program and project risk and evaluates the status and progress of activities to identify and report trends and provide guidance to the Agency and affected programs and projects. The CMC provides its findings and recommendations to program or project managers and to the appropriate PMCs regarding the performance and technical and management viability of the program or project prior to KDPs.

2.3.3.1 For programs and projects that are conducted by multiple Centers, an Integrated Center Management Council (ICMC) should be used where the Center Director (or designee) of each Center with substantial contributions is a member of the ICMC. The ICMC is chaired by the Center Director (or representative) responsible for the program/project management.

2.3.4 Following each LCR, the independent SRB and the program or project shall brief the applicable management councils on the results of the LCR to support the councils' assessments. The final LCR in a given life-cycle phase provides essential information for the KDP, which marks the end of that life-cycle phase except for transition from Phase D to E, where transition occurs following on-orbit checkout and initial operations. To support the Decision Authority's determination of the readiness of a program or project to progress to the next phase of the life cycle, the program manager (for projects in their program), the Center Director, the MDAA (for programs and Category 1 projects), and the governing PMC provide their assessments and recommendations with supporting data, as necessary. Tables 2-3 through 2-6 define for each LCR and each KDP the LCR objectives and the expected maturity state at the subsequent KDP. (The NASA Space Flight Program and Project Management Handbook provides further details.)

Table 2-3 Expected Maturity State Through the Life Cycle of Uncoupled and Loosely Coupled Programs

Table 2-4 Expected Maturity State
Through the Life Cycle of Tightly Coupled Programs

Table 2-5 Expected Maturity State Through the Life Cycle of
Projects and Single-Project Programs

Table 2-6 Objectives for Other Reviews

2.4 Approving and Maintaining Program and Project Plans, Baselines, and Commitments

2.4.1 After reviewing the supporting material and completing discussions with concerned parties, the Decision Authority determines whether and how the program or project proceeds into the next phase and approves any additional actions. These decisions shall be summarized and recorded in the Decision Memorandum signed at the conclusion of the governing PMC by all parties with supporting responsibilities, accepting their respective roles. Once signed, the Decision Memorandum is appended to the project Formulation Agreement, Program Plan, or Project Plan, as appropriate. Decision Memorandum templates may be found at NASA's OCFO community of practice site (https://max.omb. gov/community/pages/viewpage.action?pageId=646907686), which can be reached via the NASA Engineering Network (NEN) Project Planning and Control (PP&C) community of practice site).

2.4.1.1 The Decision Memorandum shall describe the constraints and parameters within which the Agency, the program manager, and the project manager will operate; the extent to which changes in plans may be made without additional approval; any additional actions that came out of the KDP; and the supporting data (e.g., the cost and schedule data sheet) that provide further details. The NASA Space Flight Program and Project Management Handbook provides an example of the Decision Memorandum to illustrate the level and types of information that are documented.

2.4.1.2 The Management Agreement contained within the Decision Memorandum defines the parameters and authorities over which the program or project manager has management control. A program or project manager has the authority to manage within the Management Agreement and is accountable for compliance with the terms of the agreement. The Management Agreement, which is documented at every KDP, may be changed between KDPs as the program or project matures and in response to internal and external events. The Management Agreement should be viewed as a contract between the Agency and the program or project manager. A divergence from the Management Agreement that any party identifies as significant shall be accompanied by an amendment to the Decision Memorandum.

2.4.1.3 During Formulation, the Decision Memorandum shall establish a target life-cycle cost range (and schedule range, if applicable) as well as the Management Agreement addressing the schedule and resources required to complete Formulation.

2.4.1.4 The Decision Memorandum also documents any additional resources beyond those explicitly estimated or requested by the program/project (e.g., additional schedule margin) when the Decision Authority determines that this is appropriate. This includes Unallocated Future Expenses (UFE), which are costs that are expected to be incurred but cannot yet be allocated to a specific WBS subelement of a program's or project's plan. Management control of some UFE may be retained above the level of the project (i.e., Agency, Mission Directorate, or program). (See Figure 2-6, Example of Agreements and Commitments in Terms of Cost for Projects.)

Figure 2-6 Example of Agreements and Commitments in Terms of Cost for Projects

2.4.1.5 All projects and single-project programs shall document the Agency's life-cycle cost estimate and other parameters in the Decision Memorandum for Implementation (KDP C), and this becomes the ABC. The ABC is the baseline against which the Agency's performance is measured during the Implementation Phase. The ABC for projects with a life-cycle cost of $250 million or more forms the basis for the Agency's external commitment to OMB and Congress.

2.4.1.6 Tightly coupled programs shall document their life-cycle cost estimate, in accordance with the life-cycle scope defined in the FAD or PCA, and other parameters in their Decision Memorandum and ABC at KDP I.

2.4.1.7 Programs or projects shall be rebaselined when: (1) the estimated development cost ⁶ exceeds the ABC development cost by 30 percent or more (for projects over $250 million, also that Congress has reauthorized the project); (2) the NASA AA judges that events external to the Agency make a rebaseline appropriate; or (3) the NASA AA judges that the program or project scope defined in the ABC has been changed or the tightly coupled program or project has been interrupted. ABCs for projects are not rebaselined to reflect cost or schedule growth that does not meet one or more of these criteria. When an ABC is rebaselined, the Decision Authority directs that a review of the new baseline be conducted by the SRB or as determined by the Decision Authority.

⁶"Development cost" includes all project costs from authorization to proceed to Implementation (Phase C) through operational readiness at the end of Phase D.

2.4.2 All programs and projects develop cost estimates and planned schedules for the work to be performed in the current and following life-cycle phases (see Appendix I tables). As part of developing these estimates, the program or project shall document the basis of estimate (BOE) in retrievable program or project records.

2.4.3 Tightly coupled and single-project programs (regardless of life-cycle cost) and projects with an estimated life-cycle cost greater than $250 million shall develop probabilistic analyses of cost and schedule estimates to obtain a quantitative measure of the likelihood that the estimate will be met in accordance with the following requirements.

2.4.3.1 Tightly coupled and single-project programs (regardless of life-cycle cost) and projects with an estimated life-cycle cost greater than $250 million shall provide a range of cost and a range for schedule at KDP 0/KDP B, each range (with confidence levels identified for the low and high values of the range) established by a probabilistic analysis and based on identified resources and associated uncertainties by fiscal year. Separate analyses of cost and schedule, each with associated confidence levels, meet the requirement. A joint cost and schedule confidence level (JCL) is not required but may be used at KDP 0 and KDP B.

2.4.3.2 At KDP I/KDP C, tightly coupled and single-project programs (regardless of life-cycle cost) and projects with an estimated life-cycle cost greater than $250 million shall develop a resource-loaded schedule and perform a risk-informed probabilistic analysis that produces a JCL. The JCL is the product of a probabilistic analysis of the coupled cost and schedule to measure the likelihood of completing all remaining work at or below the budgeted levels and on or before the planned completion of Phase D.

2.4.4 Mission Directorates shall plan and budget tightly coupled and single-project programs (regardless of life-cycle cost) and projects with an estimated life-cycle cost greater than $250 million based on a 70 percent joint cost and schedule confidence level, or as approved by the Decision Authority.

2.4.4.1 Any JCL approved by the Decision Authority at less than 70 percent shall be justified and documented.

2.4.4.2 Mission Directorates shall ensure funding for these projects is consistent with the Management Agreement and in no case less than the equivalent of a 50 percent JCL.

2.4.4.3 When a tightly coupled program, single-project program, or project with an estimated life-cycle cost greater than $250M is rebaselined, the JCL should be recalculated and approved as a part of the rebaselining approval process.

2.4.5 Loosely coupled and uncoupled programs are not required to develop program cost and schedule confidence levels. These programs shall provide analysis that provides a status of the program's risk posture that is presented to the governing PMC as each new project reaches KDP B and C or when a project's ABC is rebaselined.

Chapter 3. Program and Project Management Roles and Responsibilities

3.1 Governance

3.1.1 The fundamental principles of NASA governance are defined in NPD 1000.0, NASA Governance and Strategic Management Handbook. The governance model prescribes a management structure that employs checks and balances among key organizations to ensure that decisions have the benefit of different points of view and are not made in isolation. This structure is made up of two authorities: Programmatic and Institutional. Programmatic Authority consists of the Mission Directorates and their respective programs and projects. The Institutional Authority consists of those organizations not in the Programmatic Authority. As part of Institutional Authority, NASA established the Technical Authority process as a system of checks and balances to provide independent oversight of programs and projects in support of safety and mission success through the selection of specific individuals with delegated levels of authority. Individuals with these formal delegations are Technical Authorities. The requirements related to Technical Authority are contained in Section 3.3.

3.2 Roles and Responsibilities

3.2.1 The roles and responsibilities of NASA management are defined in NPD 1000.0, NASA Governance and Strategic Management Handbook, and further outlined in NPD 1000.3, The NASA Organization. The key roles and responsibilities specific to programs and projects can be summarized as follows:

a. The Administrator leads the Agency and is accountable to the President for all aspects of the Agency's mission, including establishing and articulating the Agency's vision and strategic priorities and ensuring successful implementation of supporting policies, programs, and performance assessments. The Administrator performs all necessary functions to govern NASA operations and exercises the powers vested in NASA by law.

b. The NASA Associate Administrator is responsible for the technical and programmatic integration of programs at the Agency level and serves as the Decision Authority for programs and Category 1 projects with the advice of the APMC. He or she monitors the status and performance of the programs and projects via reports from the MDAA; Center Director; and through Agency-level review, such as the APMC and the Baseline Performance Review (BPR) process. The NASA AA may delegate Decision Authority to MDAAs.

c. MDAAs are responsible for Programmatic Authority in managing programs and projects within their Mission Directorate. They establish directorate policies applicable to programs, projects, and supporting elements; support the Agency's strategic acquisition process; initiate new programs and projects; recommend assignment of programs and Category 1 projects to Centers; assign Category 2 and 3 projects to Centers; serve as the KDP Decision Authority for Category 2 and 3 projects; are responsible for all program-level requirements; establish program and project budgets; approve Formulation Agreements and Program and Project Plans; oversee program and project performance via the MDPMC; and approve launch readiness. The MDAAs may delegate some of their Programmatic Authority to deputy associate administrators, division directors, or their equivalent, such as program directors, and Center Directors. The MDAAs also plan and manage independent reviews with support from Centers for the Mission Directorate program and project portfolio, organize and staff the independent review teams, monitor execution of the reviews, and capture lessons learned with support from Centers, the Office of the Chief Financial Officer, and OCE⁷. The MDAAs proactively work with Center Directors to develop constructive solutions for the formulation and implementation of programs and projects conducted at their Centers and to resolve issues as they arise.

d. Center Directors are responsible and accountable for all activities assigned to their Center. They are responsible for the institutional activities and for ensuring the proper planning for and assuring the proper execution of programs and projects assigned to the Center. This includes:

(1) Performing their delegated Technical Authority duties in accordance with Section 3.3;

(2) Ensuring the Center is capable of accomplishing the programs, projects, and other activities assigned to it in accordance with Agency policy and the Center's best practices and institutional policies by establishing, developing, and maintaining institutional capabilities (processes and procedures, human capital - including trained/certified program/project personnel, facilities, and infrastructure) required for the execution of programs and projects;

(3) Establishing and maintaining ongoing processes and forums, including the CMC, to monitor the status and progress of programs and projects at their Center;

(4) Performing periodic program and project reviews to assess technical and programmatic progress to ensure performance in accordance with their Center's and the Agency's requirements, procedures, processes, etc.;

(5) Reporting the executability of all aspects of their programs and projects (programmatic, technical, and all others) along with major risks, mitigation strategies, and significant concerns to the Decision Authority and other appropriate forums;

(6) Working with the Mission Directorate and the programs and project managers, once assigned, to assemble the program/project team(s) and to provide needed Center resources;

(7) Providing support and guidance to programs and projects in resolving technical and programmatic issues and risks;

(8) Concurring on the adequacy of cost/schedule estimates and the consistency of these estimates with Agency requirements, workforce, and other resources stipulated in proposed Program and Project Plans;

(9) Working proactively with the Mission Directorates, programs, projects, and other Institutional Authorities to find constructive solutions to problems to benefit both the programs and projects and the overall Agency long-term health; and

(10) Certifying that programs and/or projects have been accomplished properly as part of the launch approval process.

(11) Supporting Mission Directorates to plan and manage independent reviews.

e. The program manager is responsible for the formulation and implementation of the program as described in this document and NPR 7123.1. This includes responsibility and accountability for the program safety; technical integrity; technical, cost, and schedule performance; and mission success. (Refer to the NASA Space Flight Program and Project Management Handbook and the NASA Project Planning and Control Handbook for additional information.)

f. The project manager is responsible for the formulation and implementation of the project as described in this document and NPR 7123.1. This includes responsibility and accountability for the project safety; technical integrity; technical, cost, and schedule performance; and mission success. (Refer to the NASA Space Flight Program and Project Management Handbook and the NASA Project Planning and Control Handbook for additional information)

g. The Chief Financial Officer oversees all financial management, budget, strategic planning, and performance activities relating to the programs and operations of the Agency. The Office of the Chief Financial Officer provides Agency programmatic (cost and schedule) analysis capability leadership; establishes cost and schedule analyses policies, methods, and standards; and assists in identification of personnel with analytical expertise to support in-line programmatic activities of NASA programs and projects, as well as independent programmatic assessments (e.g., SRB).

h. The NASA Chief Engineer establishes policy, oversight, and assessment of the NASA engineering and program/project management processes; implements the Engineering Technical Authority process; and serves as principal advisor to the Administrator and other senior officials on matters pertaining to the technical capability and readiness of NASA programs and projects to execute according to plans. The Chief Engineer directs the NASA Engineering and Safety Center (NESC) and ensures that programs/projects respond to requests from the NESC for data and information needed to make independent technical assessments and then respond to NESC assessments. The Chief Engineer leads the mission and program/project performance assessment for the BPR; ensures that space asset protection functional support is provided to NASA missions and management, including at a minimum, preparation of project protection plans; and co-chairs the SMSR with the Office of Safety and Mission Assurance (OSMA).

i. The Chief, Safety and Mission Assurance ensures the existence of robust safety and mission assurance processes and activities through the development, implementation, assessment, and functional oversight of Agency-wide safety, reliability, maintainability, quality, and risk management policies and procedures. The Chief, SMA serves as principal advisor to the Administrator and other senior officials on Agency-wide safety, reliability, maintainability, and quality; performs independent program and project compliance verification audits; implements the SMA Technical Authority process; monitors, collects, and assesses Agency-wide safety and mission assurance financial and performance results; oversees the prompt investigation of NASA mishaps and assures the appropriate closure; and co-chairs the Safety and Mission Success Review (SMSR) with the OCE.

j. The Chief Health and Medical Officer establishes policy, oversight, and assessment on all health and medical matters associated with NASA missions, is responsible for implementation of the Health and Medical Technical Authority process, and serves as principal advisor to the Administrator and other senior officials on health and medical issues related to the Agency workforce.

k. The Mission Support Directorate (MSD) Associate Administrator establishes policy and procedures for institutional oversight for mission support functional areas (e.g., procurement).

l. Roles and responsibilities for other NASA organizations can be found in NPD 1000.3.

3.3 Technical Authority

3.3.1 Programs and projects shall follow the Technical Authority (TA) process established in this Section 3.3. NASA established this process as part of its system of checks and balances to provide independent oversight of programs and projects in support of safety and mission success through the selection of specific individuals with delegated levels of authority. These individuals are the Technical Authorities. In this document, the term TA is used to refer to such an individual, but is also used to refer to elements of the TA process. The responsibilities of a program or project manager are not diminished by the implementation of TA. The program or project manager is ultimately responsible for the safe conduct and successful outcome of the program or project in conformance with governing requirements. This includes meeting programmatic, institutional, technical, safety, cost, and schedule commitments.

3.3.1.1 TA originates with the Administrator and is formally delegated to the NASA AA and then to the NASA Chief Engineer for Engineering Technical Authority; the Chief, Safety and Mission Assurance for SMA Technical Authority; and then to the Center Directors. The Administrator delegates Health and Medical Technical Authority (HMTA) to the NASA Chief Health and Medical Officer. HMTA may then be delegated to the Center Chief Medical Officer with the concurrence of the Center Director. Subsequent TA delegations are made to selected individuals who are funded independent of the Programmatic Authority. Such delegations are formal and traceable to the Administrator. TAs located at Centers remain part of their Center organization, and their personnel performance appraisal is signed by the management of that Center organization. The Center Director (or designee) is responsible for establishing and maintaining Center TA policies and practices, consistent with Agency policies and standards.

3.3.2 Other Technical Authority Roles

3.3.2.1 Top-level documents developed by a program detailing Agency-level requirements for human-rated systems are signed by the Administrator or his/her formally delegated designee.

3.3.2.2 On decisions related to technical and operational matters involving safety and mission success residual risk, formal concurrence by the responsible TAs (Engineering, Safety and Mission Assurance, and/or Health and Medical) is required. This concurrence is to be based on the technical merits of the case. For residual risks to personnel or high-value hardware, the cognizant safety organization needs to agree that the risk is acceptable. For matters involving human safety risk, the actual risk taker(s) (or official spokesperson(s) and their supervisory chain) need to formally consent to taking the risk and the responsible program, project, or operations manager needs to formally accept the risk.

3.3.3 At the program or project level, the responsibilities common to each of the individuals with delegated TA (Engineering Technical Authority (ETA), SMA TA, and HMTA) are delineated below. (See paragraphs 3.3.6 to 3.3.9 for unique aspects of each of the TAs.) These individuals:

a. Serve as members of program or project control boards, change boards, and internal review boards.

b. Work with the Center management and other TA personnel, as necessary, to ensure that the quality and integrity of program or project processes, products, and standards of performance related to engineering, SMA, and health and medical reflect the level of excellence expected by the Center or, where appropriate, by the NASA TA community.

c. Ensure that requests for waivers or deviations from TA requirements are submitted to and acted on by the appropriate level of TA. ("Technical Authority requirements" is defined in Appendix A.)

d. Assist the program or project in making risk-informed decisions that properly balance technical merit, cost, schedule, and safety across the system.

e. Provide the program or project with the TA view of matters based on their knowledge and experience and raise a Dissenting Opinion (see Section 3.4) on a decision or action, when appropriate.

f. Serve as an effective part of NASA's overall system of checks and balances.

3.3.3.1 At all Centers (except Johnson Space Center, where the chief medical officer serves this function), the program/project-level ETA and SMA TA are responsible to serve as the awareness and communication links for potential HMTA issues and to inform the appropriate level of HMTA, the program/project manager, and Center management of potential HMTA issues. (See NPR 7120.11, NASA Health and Medical Technical Authority (HMTA) Implementation.)

3.3.4 The day-to-day involvement of the TAs in program/project activities ensures that significant views from the TAs will be available to the program/project in a timely manner and should be handled during the normal program/project processes. TAs are expected to keep their discipline chain of authority informed of issues as they are arise, including direct communication between the Center's engineering director, SMA director (or equivalent), and chief medical officer with their counterparts at NASA Headquaters.

3.3.5 Infrequent circumstances may arise when a TA and the program or project manager disagree on a proposed programmatic or technical action and judge that the issue rises to a level of significance that should be brought to the attention of the next higher level of management (i.e., a Dissenting Opinion exists). In such circumstances:

a. Resolution occurs prior to Implementation whenever possible. However, if considered to be in the best interest of the program/project, the program/project manager has the authority to proceed at risk in parallel with the pursuit of a resolution. In such circumstances, the next higher level of Programmatic and TA is informed of the decision to proceed at risk.

b. Resolution is jointly attempted at successively higher levels of Programmatic Authority and TA until resolved. Final appeals are made to the NASA Administrator.

3.3.6 The Engineering Technical Authority (ETA) establishes and is responsible for the engineering design processes, specifications, rules, best practices, etc., necessary to fulfill programmatic mission performance requirements.

3.3.6.1 The NASA Chief Engineer provides overall leadership for the ETA process for programs and projects, including Agency engineering policy direction, requirements, and standards. The NASA Chief Engineer approves the appointment of the Center engineering directors (or equivalent) and of ETAs on programs and Category 1 projects and is notified of the appointment of other Engineering TAs. The NASA Chief Engineer hears appeals of engineering decisions when they cannot be resolved at lower levels.

3.3.6.2 The Center Director (or designee) develops the Center's ETA policies and practices, consistent with Agency policies and standards. The following individuals are responsible for implementing ETA at the Center:

a. Center Director - The Center Director (or the Center engineering director or designee) is the Center ETA responsible for Center engineering design processes, specifications, rules, best practices, etc., necessary to fulfill mission performance requirements for programs, projects, and/or major systems implemented by the Center. The Center Director delegates Center ETA implementation responsibility to an individual in the Center's engineering leadership. The Center ETA supports the TAs in processing changes to and waivers or deviations from requirements that are the responsibility of the ETA. This includes all applicable Agency and Center engineering directives, requirements, procedures, and standards. The Center Director appoints, with the approval of the NASA Chief Engineer, individuals for the position of Center engineering director (or equivalent) and for the ETA positions down to and including program chief engineers and Category 1 project chief engineers (or equivalents). ⁷ The Center Director appoints Category 2 and 3 project chief engineers and lead discipline engineers.

⁷ Centers may use an equivalent term for these positions, such as Program/Project Systems Engineer.

b. Program/Project Chief Engineer (PCE) - The PCE is the position to which the program/project-level ETA has been delegated. Different Centers use different titles for this position.

c. Lead Discipline Engineer (LDE) - The LDE is a senior technical engineer in a specific discipline at the Center. Different Centers use different titles for this position. The LDE assists the program/project through direct involvement with working-level engineers to identify engineering requirements in accordance with NPR 7120.10, Technical Standards for NASA Programs and Projects and other documents, and develop solutions that comply with the requirements. The LDE works through and with the PCE to ensure the proper application and management of discipline-specific engineering requirements and Agency standards.

3.3.6.3 The ETA for the program or project leads and manages the engineering activities, including systems engineering, design, development, sustaining engineering, and operations. A Center may have more than one engineering organization and delegates ETA to different areas as needed. To support the program/project and maintain ETA independence and an effective check and balance system:

a. The program/project manager concurs in the appointment of the program/project-level ETAs.

b. The ETA cannot approve a request for relief from a non-technical derived requirement established by a Programmatic Authority.

c. An ETA may approve a request for relief from a technical derived requirement if he/she ensures that the appropriate independent Institutional Authority subject matter expert who is the steward for the involved technology has concurred in the decision to approve the requirement relief.

3.3.7 Although a limited number of individuals make up the ETAs, their work is enabled by the contributions of the program's or project's working-level engineers and other supporting personnel (e.g., contracting officers). The working-level engineers do not have formally delegated TA and consequently may not serve in an ETA capacity. These engineers perform the detailed engineering and analysis for the program/project with guidance from their Center management and/or LDEs and support from the Center engineering infrastructure. They deliver the program/project products (e.g., hardware, software, designs, analysis, and technical alternatives) that conform to applicable programmatic, Agency, and Center requirements. They are responsible for raising issues to the program/project manager, Center engineering management, and/or the PCE, as appropriate, and are a key resource for resolving these issues.

3.3.8 The Safety and Mission Assurance (SMA) TA establishes and is responsible for the SMA processes, specifications, rules, best practices, etc., necessary to fulfill safety and programmatic mission performance requirements. (Refer to NASA-STD-8709.20, Management of Safety and Mission Assurance Technical Authority (SMA TA) Requirements. The following individuals are responsible for implementing SMA TA at the Center:

3.3.8.1 The Chief, SMA hears appeals of SMA decisions when issues cannot be resolved below the Agency level.

3.3.8.2 The Center Director (or the Center SMA director or designee) is the Center SMA TA responsible for Center safety and mission assurance processes, specifications, rules, best practices, etc., necessary to fulfill mission performance requirements for programs, projects, and/or major systems implemented by the Center. The Center Director (or designee) also monitors, collects, and assesses institutional, program, and project SMA financial metrics and performance results. The Center Director delegates Center SMA TA implementation responsibility to an individual in the Center's safety and mission assurance leadership. The Center SMA TA supports the lower level SMA TAs in processing changes to and waivers or deviations from requirements that are the responsibility of the SMA TA. This includes all applicable Agency and Center SMA directives, requirements, procedures, and standards. The Center Director appoints, with the approval of the NASA Chief, SMA, individuals for the position of Center SMA director (or equivalent). The Center SMA director, in consultation with the NASA Chief, SMA, appoints program- and project-level chief safety and mission assurance officers (CSOs) to exercise the TA role within programs and projects.

3.3.9 The Health and Medical Technical Authority (HMTA) is the NASA Chief Health and Medical Officer (CHMO). The CHMO establishes and is responsible for the health and medical Agency-level requirements, specifications, rules, best practices, etc., necessary to fulfill programmatic mission performance requirements.

3.3.9.1 Due to Center infrastructure differences, the flow down of HMTA processes and responsibilities from the CHMO varies between Centers. Additionally, the CHMO entered into an agreement with SMA and OCE to have engineering and safety TA personnel serve as awareness and communication links for HMTA. The HMTA flow down and communication processes, including roles and responsibilities, are specified in NPR 7120.11, Health and Medical Technical Authority Implementation, and further described in the Center HMTA implementation plan. This NPR recognizes that medical staff have a special obligation to protect the handling and dissemination of an individual's medical information and the necessity of respecting these restrictions.

3.3.9.2 When applicable, the Program Plan or Project Plan will describe how the program or project will comply with HMTA requirements and processes as described in NPR 7120.11. The CHMO hears appeals of HMTA decisions when issues cannot be resolved below the Agency level.

3.4 Process for Handling Dissenting Opinions

3.4.1 Programs and projects shall follow the Dissenting Opinion process in this Section 3.4. NASA teams have full and open discussions, with all facts made available, to understand and assess issues. Diverse views are to be fostered and respected in an environment of integrity and trust with no suppression or retribution. In the team environment in which NASA operates, team members often have to determine where they stand on a decision. In assessing a decision or action, a member has three choices: agree, disagree but be willing to fully support the decision, or disagree and raise a Dissenting Opinion. Unresolved issues of any nature (e.g., programmatic, safety, engineering, health and medical, acquisition, accounting) within a team should be quickly elevated to achieve resolution at the appropriate level.

3.4.2 When time permits, the disagreeing parties jointly document the issue, including agreed-to facts, discussion of the differing positions with rationale and impacts, and the parties' recommendations. The joint documentation needs to be approved by the representative of each view, concurred with by affected parties, and provided to the next higher level of the involved authorities with notification to the second higher level of management. This may involve a single authority (e.g., the Programmatic Authority) or multiple authorities (e.g., Programmatic and TAs). In cases of urgency, the disagreeing parties may jointly present the information stated above orally with all affected organizations represented, advance notification to the second-higher level of management, and documentation follow up.

3.4.3 Management's decision on the dissent memorandum (or oral presentation) is documented and provided to the dissenter and to the notified managers and becomes part of the program or project record. If the dissenter is not satisfied with the process or outcome, the dissenter may appeal to the next higher level of management. The dissenter has the right to take the issue upward in the organization, even to the NASA Administrator, if necessary.

3.5 Principles Related to Tailoring Requirements

3.5.1 Programs and projects shall follow the tailoring process in this Section.

3.5.2 It is NASA policy that all prescribed requirements (requirements levied on a lower organizational level by a higher organizational level) are complied with unless relief is formally granted. Policy also recognizes that each program or project has unique aspects that must be accommodated to achieve mission success in an efficient and economical manner. Tailoring is the process used to adjust or seek relief from a prescribed requirement to meet the needs of a specific program or project. Tailoring is both an expected and accepted part of establishing proper requirements. For requests for relief from requirements that are the responsibility of the Chief, SMA, NASA-STD-8709.20 contains the SMA-specific process. Refer to the NASA Space Flight Program and Project Management Handbook for additional explanation and guidance related to the tailoring process.

3.5.3 The evaluation and disposition of requests for tailoring (including Agency-level requirements and standards) comply with the following:

a. The request for relief from a requirement includes the rationale, a risk evaluation, and reference to all material that provides the justification supporting acceptance. The request for requirement relief is referred to as a "deviation" or "waiver" depending on the timing of the request. Deviations apply before a requirement is put under configuration control at the level the requirement will be implemented, and waivers apply after.

b. The organization submitting the tailoring request informs the next higher level of involved management in a timely manner of the tailoring request.

c. The organization at the level that established the requirement dispositions the request for tailoring of that requirement unless this authority has been formally delegated elsewhere. Such delegations will maintain the separation of Programmatic and Institutional Authorities required by governance.

d. The dispositioning organization consults with the other organizations that were involved in the establishment of the specific requirement and obtains the concurrence of those organizations having a substantive interest.

e. Approved tailoring requests become part of the retrievable program or project records.

3.5.4 A prescribed requirement that is not relevant and/or not capable of being applied to a specific program, project, system, or component can be approved as Non-Applicable by the individual who has been delegated oversight authority by the organization that established the requirement. This approval can be granted at the level where the requirement was specified for implementation (e.g., the project-level ETA could approve a Non-Applicable designation for an engineering requirement). The request and approval documentation become part of the retrievable program or project records. No other formal deviation or waiver process is required.

3.5.5 A request for a permanent change to a prescribed requirement in an Agency or Center document that is applicable to all programs and projects shall be submitted as a "change request" to the office responsible for the requirement policy document unless formally delegated elsewhere.

3.5.6 Tailoring NPR 7120.5

3.5.6.1 Tailoring of NPR 7120.5 requirements is dispositioned by the designated officials shown in Table 3-1, unless formally delegated elsewhere. Requests for tailoring may be submitted in the form of the Compliance Matrix (Appendix C) or by using a waiver request (see the NASA Space Flight Program and Project Management Handbook) individually or in groups. Regardless of whether the waiver is documented as a stand-alone document or as part of the Compliance Matrix, the required signatures from the responsible organizations are to be obtained.

Table 3-1 Waiver Approval Authority for NPR 7120.5 Requirements

R = Recommends; C = Concurs; A = Approves; I = Informed

* As applicable

**Unless otherwise delegated

3.6 Reimbursable Space Flight Work

3.6.1 A Center negotiating reimbursable space flight work with another agency shall propose NPR 7120.5 as the basis by which it will perform the space flight work. If the sponsoring agency does not want NPR 7120.5 requirements (or a subset of those requirements) to be followed, then the interagency Memorandum of Understanding/Memorandum of Agreement (MOU/MOA) or the contract needs to explicitly identify those requirements that will not be followed, along with the substitute requirements for equivalent processes and any additional program/project management requirements the sponsoring agency wants. The Center obtains a formal waiver by the NASA Chief Engineer for those NPR 7120.5 requirements that are not to be followed or the Center cannot accept the work.

3.7 Use of the Metric System

3.7.1 The International System of Units (commonly known as the Systeme Internationale (SI) or metric system of measurement) is to be used for all new space flight projects and programs, especially in cooperative efforts with International Partners. 15 U.S.C. §205b and Executive Order 12770 provide relief from this preferential use of SI if it is found that obtaining components in SI units would result in a substantial increase in cost or unacceptable delays in schedule. Each program and project shall perform and document an assessment to determine an approach that maximizes the use of SI. This assessment will document an integration strategy if both SI and U.S. customary units are used in a project or program. The assessment is to be completed and documented in the Program Plan or Project Plan no later than the SDR.

Appendix A. Definitions

Acquisition. The process for obtaining the systems, research, services, construction, and supplies that NASA needs to fulfill its missions. Acquisition--which may include procurement (contracting for products and services)--begins with an idea or proposal that aligns with the NASA Strategic Plan and fulfills an identified need and ends with the completion of the program or project or the final disposition of the product or service.

Acquisition Plan. The integrated acquisition strategy that enables a program or project to meet its mission objectives and provides the best value to NASA. (See a description in Section 3.4 of the Program Plan and Project Plan templates, appendices G and H.)

Acquisition Strategy Meeting. A forum where senior Agency management reviews major acquisitions in programs and projects before authorizing significant budget expenditures. The ASM is held at the Mission Directorate/Mission Support Office level, implementing the decisions that flow out of the earlier Agency acquisition strategy planning. The ASM is typically held early in Formulation, but the timing is determined by the Mission Directorate. The ASM focuses on considerations such as impacting the Agency workforce, maintaining core capabilities and make-or-buy planning, and supporting Center assignments and potential partners.

Agency Baseline Commitment. Establishes and documents an integrated set of project requirements, cost, schedule, technical content, and an agreed-to JCL that forms the basis for NASA's commitment to the external entities of OMB and Congress. Only one official baseline exists for a NASA program or project, and it is the Agency Baseline Commitment.

Agency Program Management Council. The senior management group, chaired by the NASA Associate Administrator or designee that is responsible for reviewing Formulation performance, recommending approval, and overseeing implementation of programs and Category 1 projects according to Agency commitments, priorities, and policies.

Agreement. The statement (oral or written) of an exchange of promises. Parties to a binding agreement can be held accountable for its proper execution and a change to the agreement requires a mutual modification or amendment to the agreement or a new agreement.

Analysis of Alternatives. A formal analysis method that compares alternative approaches by estimating their ability to satisfy mission requirements through an effectiveness analysis and by estimating their life-cycle costs through cost analysis. The results of these two analyses are used together to produce a cost-effectiveness comparison that allows decision makers to assess the relative value or potential programmatic returns of the alternatives. An analysis of alternatives broadly examines multiple elements of program/project alternatives (including technical performance, risk, LCC, and programmatic aspects).

Announcement of Opportunity. An AO is one form of a NASA Broad Agency Announcement, which is a form of public/private competition. NASA solicits, accepts, and evaluates proposals submitted by all categories of proposers in response to an AO, including academia, industry, not-for-profits, Government laboratories, Federally Funded Research and Development Centers (FFRDC), NASA Centers, and the Jet Propulsion Laboratory. Regulatory coverage of AOs appears in NASA Federal Acquisition Regulation (FAR) Supplement (NFS) Part 1872. NASA typically uses a one-step or a two-step AO process. In a one-step AO process, proposals for new projects are evaluated competitively and selected for Formulation in a single step. In two-step competitions, several proposals for new projects may be selected in Step 1 and given time to mature their concepts in a funded concept study before the Step 2 down-selection.

Approval. Authorization by a required management official to proceed with a proposed course of action. Approvals are documented.

Approval (for Implementation). Acknowledgment by the Decision Authority that the program /project has met stakeholder expectations and Formulation requirements and is ready to proceed to Implementation. By approving a program/project, the Decision Authority commits the budget resources necessary to continue into Implementation. Approval (for Implementation) is documented.

Assure. To promise or say with confidence. It is more about saying than doing. (An example is: I assure you that you will be warm enough.)

Architectural Control Document. A configuration-controlled document or series of documents that embodies a cross-Agency mission architecture(s), including the structure, relationships, interfaces, principles, assumptions, and results of the analysis of alternatives that govern the design and implementation of the enabling mission systems.

Baseline (document context). Implies the expectation of a finished product, though updates may be needed as circumstances warrant. All approvals required by Center policies and procedures have been obtained.

Baseline (general context). An agreed-to set of requirements, cost, schedule, designs, documents, etc., that will have changes controlled through a formal approval and monitoring process.

Baseline Performance Review. A monthly Agency-level independent assessment to inform senior leadership of performance and progress toward the Agency's mission and program/project performance. The monthly meeting encompasses a review of crosscutting mission support issues and all NASA mission areas.

Baseline Science Requirements. The mission performance requirements necessary to achieve the full science objectives of the mission. (Also see Threshold Science Requirements.)

Basis of Estimate. The documentation of the ground rules, assumptions, and drivers used in developing the cost and schedule estimates, including applicable model inputs, rationale or justification for analogies, and details supporting cost and schedule estimates. The basis of estimate is contained in material available to the SRB and management as part of the LCR and KDP process.

Budget. A financial plan that provides a formal estimate of future revenues and obligations for a definite period of time for approved programs, projects, and activities. (See NPR 9420.1 and NPR 9470.1 for other related financial management terms and definitions.)

Center Management Council. The council at a Center that performs oversight of programs and projects by evaluating all program and project work executed at that Center.

Change Request. A change to a prescribed requirement set forth in an Agency or Center document intended for all programs and projects for all time.

Compliance Matrix. The Compliance Matrix (Appendix C) documents whether and how the program or project complies with the requirements of NPR 7120.5. It provides rationale and approvals for waivers from requirements and is part of retrievable program and project records.

Component Facilities. Complexes that are geographically separated from the NASA Center or institution to which they are assigned, but are still part of the Agency.

Concept Documentation (formerly Mission Concept Report). Documentation that captures and communicates a feasible concept that meets the goals and objectives of the mission, including results of analyses of alternative concepts, the concept of operations, preliminary risks, and potential descopes. It may include images, tabular data, graphs, and other descriptive material.

Concurrence. A documented agreement by a management official that a proposed course of action is acceptable.

Confidence Level. A probabilistic assessment of the level of confidence of achieving a specific goal.

Configuration Management. A management discipline applied over a product's life cycle to provide visibility into and control changes to performance, functionality, and physical characteristics.

Conflict of Interest. A conflict of interest involves the abuse - actual, apparent, or potential - of the trust that NASA has in its personnel. A conflict of interest is a situation in which financial or other personal considerations have the potential to compromise or bias professional judgment and objectivity. An apparent conflict of interest is one in which a reasonable person would think that the individual's judgment is likely to be compromised. A potential conflict of interest involves a situation that may develop into an actual conflict of interest. A conflict of interest exists whether or not decisions are affected by a personal interest; a conflict of interest implies only the potential for bias, not likelihood.

Considerations for a PIR. Considerations that trigger a discussion on the need for a PIR include significant changes to the program (internally or externally driven) and/or planned outcomes not being achieved that signal the need to assess program performance with respect to expectations and determine the programâ??s ability to execute the implementation plan. Examples of significant changes to the program include:

• Significant changes to Agency policy and direction to ensure continued alignment with Agency goals and objectives and need to evaluate potential adjustments to program objectives/plans to increase support to Agency needs.
• Significant changes to interagency and/or international agreements involving the ability of NASA and/or partners to meet their commitments.
• Significant changes to the acquisition approach, including contractors and Center roles and responsibilities.
• Significant changes to budget profile.
• Significant changes to the programâ??s constituent project(s) that impact the program and other projects.
• Unplanned scope or direction changes such as major changes in operations (e.g., step-up in capability); changes in management approach (e.g., giving mission operations responsibility to a private entity); and transition to extended operations.
• High interest from external stakeholder, advisory committee, and/or audit organizations in the program due to significant changes

Examples of indicators that planned outcomes are not being achieved include:

• Not meeting performance goals, e.g., APGs.
• Risk of not meeting external or internal commitments, e.g., Space Policy Directives, interagency and/or international agreements, cross NASA Center commitments, negative customer and/or partner feedback.
• Exceeding or at risk of exceeding cost or schedule plans.
• Failing to make progress toward or failing to achieve Level 1 requirements.
• Carrying significant unmitigated risks.
• Recurring or unusual requests for additional funding.
• Systemic issues (could be reflection of systemic issues across projects within the program).
• Significant external and/or congressional interest in the program (e.g., heightened external sensitivity, more inquiries than normal to the Agency, significant external stakeholder focus) or actions/recommendations from external advisory committees or audit organizations (e.g., ASAP, NAC, GAO, OIG) identifying areas that need further investigation.

Continuous Risk Management. A systematic and iterative process that efficiently identifies, analyzes, plans, tracks, controls, communicates, and documents risks associated with implementation of designs, plans, and processes.

Contract. A mutually binding legal relationship obligating the seller to furnish the supplies or services (including construction) and the buyer to pay for them. It includes all types of commitments that obligate the Government to an expenditure of appropriated funds and that, except as otherwise authorized, are in writing. In addition to bilateral instruments, contracts include (but are not limited to) awards and notices of awards; job orders or task letters issued 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. Contracts do not include grants and cooperative agreements.

Convening Authority. The management official(s) responsible for convening a program/project review; establishing the Terms of Reference, including review objectives and success criteria; appointing the SRB chair; and concurring in SRB membership. These officials receive the documented results of the review.

Cost Analysis Data Requirement. A formal document designed to help managers understand the cost and cost risk of space flight projects. The Cost Analysis Data Requirement (CADRe) consists of a Part A "Narrative" and a Part B "Technical Data" in tabular form, both provided by the program/project or Cost Analysis Division. Also, the project team produces the project life-cycle cost estimate, schedule, and risk identification, which is appended as Part C.

Decision Authority (program and project context). The individual authorized by the Agency to make important decisions on programs and projects under their authority.

Decision Memorandum. The document that summarizes the decisions made at KDPs or as necessary in between KDPs. The decision memorandum includes the Agency Baseline Commitment (if applicable), Management Agreement cost and schedule, UFE, and schedule margin managed above the project, as well as life-cycle cost and schedule estimates, as required.

Decommissioning. The process of ending an operating mission and the attendant project as a result of a planned end of the mission or project termination. Decommissioning includes final delivery of any remaining project deliverables, disposal of the spacecraft and all its various supporting systems, closeout of contracts and financial obligations, and archiving of project/mission operational and scientific data and artifacts. Decommissioning does not mean that scientific data analysis ceases, only that the project will no longer provide the resources for continued research and analysis.

Derived Requirements. Requirements arising from constraints, consideration of issues implied but not explicitly stated in the high-level direction provided by NASA Headquarters and Center institutional requirements, factors introduced by the selected architecture, and the design. These requirements are finalized through requirements analysis as part of the overall systems engineering process and become part of the program/project requirements baseline. Derived non-technical requirements are established by, and are the responsibility of, the Programmatic Authority. Derived technical requirements are the responsibility of the Institutional Authority.

Design Documentation. A document or series of documents that captures and communicates to others the specific technical aspects of a design. It may include images, tabular data, graphs, and other descriptive material. Design documentation is different from the CADRe, though parts of design documentation may be repeated in the latter.

Development Costs. The total of all costs from the period beginning with the approval to proceed to Implementation at the beginning of Phase C through operational readiness at the end of Phase D.

Deviation. A documented authorization releasing a program or project from meeting a requirement before the requirement is put under configuration control at the level the requirement will be implemented.

Disposal. The process of eliminating a project's assets, including the spacecraft and ground systems. Disposal includes the reorbiting, deorbiting, and/or passivation (i.e., the process of removing stored energy from a space structure at the end of mission that could result in an explosion or deflagration of the space structure) of a spacecraft.

Dissenting Opinion. A disagreement with a decision or action that is based on a sound rationale (not on unyielding opposition) that an individual judges is of sufficient importance that it warrants a specific review and decision by higher-level management, and the individual specifically requests that the dissent be recorded and resolved by the Dissenting Opinion process.

Earned Value Management. 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 into 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 (e.g., identification of risky WBS elements).

Earned Value Management System. An integrated management system and its related subsystems that allow for planning all work scope to completion; assignment of authority and responsibility at the work performance level; integration of the cost, schedule, and technical aspects of the work into a detailed baseline plan; objective measurement of progress (earned value) at the work performance level; accumulation and assignment of actual costs; analysis of variances from plans; summarization and reporting of performance data to higher levels of management for action; forecast of achievement of milestones and completion of events; forecast of final costs; and disciplined baseline maintenance and incorporation of baseline revisions in a timely manner.

Engineering Requirements. Requirements defined to achieve programmatic requirements and relating to the application of engineering principles, applied science, or industrial techniques.

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

Ensure. To do or have what is necessary for success. (An example is: I ensure that you will be warm enough.)

Environmental Management. The activity of ensuring that program and project actions and decisions that may potentially affect or damage the environment are assessed during the Formulation Phase and reevaluated throughout Implementation. This activity is performed according to all NASA policy and Federal, State, Tribal government and local environmental laws and regulations.

Evaluation. The continual self- and independent assessment of the performance of a program or project and incorporation of the evaluation findings to ensure adequacy of planning and execution according to plans.

Final (document context). Implies the expectation of a finished product. All approvals required by Center policies and procedures have been obtained.

Formulation. The identification of how the program or project supports the Agency's strategic goals; the assessment of feasibility, technology, and concepts; risk assessment, team building, development of operations concepts, and acquisition strategies; establishment of high-level requirements and success criteria; the preparation of plans, budgets, and schedules essential to the success of a program or project; and the establishment of control systems to ensure performance to those plans and alignment with current Agency strategies.

Formulation Agreement. The Formulation Agreement is prepared by the project to establish the technical and acquisition work that needs to be conducted during Formulation and defines the schedule and funding requirements during Phase A and Phase B for that work.

Formulation Authorization Document. The document issued by the MDAA to authorize the formulation of a program whose goals will fulfill part of the Agency's Strategic Plan and Mission Directorate strategies and establish the expectations and constraints for activity in the Formulation Phase. In addition, a FAD or equivalent is used to authorize the formulation of a project. (See Appendix E.)

Funding (budget authority). The authority provided by law to incur financial obligations that will result in expenditures. There are four basic forms of budget authority, but only two are applicable to NASA: appropriations and spending authority from offsetting collections (reimbursables and working capital funds). Budget authority is provided or delegated to programs and projects through the Agency's funds distribution process.

Health and Medical Requirements. Requirements defined by the Office of the Chief Health and Medical Officer.

Highly Specialized Information Technology. Highly specialized Information Technology (IT) is a part of, internal to, or embedded in a mission platform. The platform's function (e.g., avionics, guidance, navigation, flight controls, simulation, radar, etc.) is enabled by IT but not driven by IT itself (e.g., computer hardware and software to automate internal functions of a spacecraft or spacecraft support system such as spacecraft control and status, sensor signal and data processing, and operational tasking). Representative examples of highly specialized IT include: avionics software, real-time control systems, onboard processors, the Deep Space Network, spacecraft instrumentation software, wind tunnel control system, human physiology monitoring systems, ground support environment, experiment simulators, Mission Control Centers, and launch cameras. (For the complete definition, see NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements.)

Implementation. The execution of approved plans for the development and operation of the program/project, and the use of control systems to ensure performance to approved plans and continued alignment with the Agency's goals.

Independent Assessment(s) (includes reviews, evaluations, audits, analysis oversight, investigations). Assessments are independent to the extent the involved personnel apply their expertise impartially and without any conflict of interest or inappropriate interference or influence, particularly from the organization(s) being assessed.

Independent Funding (context of Technical Authority). The funding of Technical Authorities is considered independent if funding originating from the Mission Directorate or other Programmatic Authorities is provided to the Center in a manner that cannot be used to influence the technical independence or security of Technical Authorities.

Industrial Base. The capabilities residing in either the commercial or government sector required to design, develop, manufacture, launch, and service the program or project. This encompasses related manufacturing facilities, supply chain operations and management, a skilled workforce, launch infrastructure, research and development, and support services.

Information Technology. Any equipment or interconnected system(s) or subsystem(s) of equipment that is used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the Agency.

Infrastructure Requirements. The facilities and environmental, aircraft, personal property, equipment, and information technology resources that are needed to support programs and projects. Utilization of the capability afforded by the infrastructure includes consideration of the maintenance and other liabilities it presents.

Institutional Authority. Institutional Authority encompasses all those organizations and authorities not in the Programmatic Authority. This includes Engineering, Safety and Mission Assurance, and Health and Medical organizations; Mission Support organizations; and Center Directors.

Institutional Requirements. Requirements that focus on how NASA does business that are independent of the particular program or project. There are five types: Engineering, program/project management, safety and mission assurance, health and medical, and Mission Support Office functional requirements.

Integrated Baseline Review. A risk-based review conducted by Program/Project Management to ensure a mutual understanding between the customer and supplier of the risks inherent in the supplier's Performance Measurement Baseline (PMB) and to ensure that the PMB is realistic for accomplishing all of the authorized work within the authorized schedule and budget.

Integrated Center Management Council. The forum used by projects and programs that are being implemented by more than one Center and includes representatives from all participating Centers. The ICMC will be chaired by the director of the Center (or representative) responsible for program or project management.

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

Integrated Master Schedule. A logic network-based schedule that reflects the total project scope of work, traceable to the WBS, as discrete and measurable tasks/milestones and supporting elements that are time phased through the use of valid durations based on available or projected resources and well-defined interdependencies.

Integration Plan. The integration and verification strategies for a project interface with the system design and decomposition into the lower-level elements. The integration plan is structured to bring the elements together to assemble each subsystem and to bring all of the subsystems together to assemble the system/product. The primary purposes of the integration plan are: (1) to describe this coordinated integration effort that supports the implementation strategy, (2) to describe for the participants what needs to be done in each integration step, and (3) to identify the required resources and when and where they will be needed.

Integrated Program Management Report. The IPMR is the primary means of communicating program/project cost and schedule information between a contractor and the Government.  The IPMR consists of seven report formats that provide program/project managers information to: (1) integrate cost and schedule performance data with technical performance measures, (2) identify the magnitude and impact of actual and potential problem areas causing significant cost and schedule variances, (3) forecast schedule completions, and (4) provide valid, timely program/project status information to higher management for effective decision making.  This is a contract data requirement when EVM is required.

Interface Control Document. An agreement between two or more parties on how interrelated systems will interface with each other. It documents interfaces between things like electrical connectors (what type, how many pins, what signals will be on each of the pins, etc.); fluid connectors (type of connector or of fluid being passed, flow rates of the fluid, etc.); mechanical (types of fasteners, bolt patterns, etc.); and any other interfaces that might be involved.

Joint Cost and Schedule Confidence Level. (1) The probability that cost will be equal to or less than the targeted cost and schedule will be equal to or less than the targeted schedule date. (2) A process and product that helps inform management of the likelihood of a project's programmatic success. (3) A process that combines a project's cost, schedule, and risk into a complete picture. JCL is not a specific methodology (e.g., resource-loaded schedule) or a product from a specific tool. The JCL calculation includes consideration of the risk associated with all elements, regardless of whether or not they are funded from appropriations or managed outside of the project. JCL calculations include the period from KDP C through the hand over to operations, i.e., end of the on-orbit checkout.

Key Decision Point. The event at which the Decision Authority determines the readiness of a program/project to progress to the next phase of the life cycle (or to the next KDP).

Knowledge Management. A collection of policies, processes, and practices relating to the use of intellectual and knowledge-based assets in an organization.

Learned Lession. Captured knowledge or understanding gained through experience which, if shared, would benefit the work of others. Unlike a best practice, lessons learned describes a specific event that occurred and provides recommendations for obtaining a repeat of success or for avoiding reoccurrence of an adverse work practice or experience.

Life-Cycle Cost. The total of the direct, indirect, recurring, nonrecurring, and other related expenses both incurred and estimated to be incurred in the design, development, verification, production, deployment, prime mission operation, maintenance, support, and disposal of a project, including closeout, but not extended operations. The LCC of a project or system can also be defined as the total cost of ownership over the project or system's planned life cycle from Formulation (excluding Pre-Phase A) through Implementation (excluding extended operations). The LCC includes the cost of the launch vehicle.

Life-Cycle Review. A review of a program or project designed to provide a periodic assessment of the technical and programmatic status and health of a program or project at a key point in the life cycle, e.g., Preliminary Design Review (PDR) or Critical Design Review (CDR). Certain life-cycle reviews provide the basis for the Decision Authority to approve or disapprove the transition of a program/project at a KDP to the next life-cycle phase.

Loosely Coupled Programs. These programs address specific objectives through multiple space flight projects of varied scope. While each individual project has an assigned set of mission objectives, architectural and technological synergies and strategies that benefit the program as a whole are explored during the Formulation process. For instance, Mars orbiters designed for more than one Mars year in orbit are required to carry a communication system to support present and future landers.

Management Agreement. Within the Decision Memorandum, the parameters and authorities over which the program or project manager has management control constitute the program or project Management Agreement. A program or project manager has the authority to manage within the Management Agreement and is accountable for compliance with the terms of the agreement.

Margin. The allowances carried in budget, projected schedules, and technical performance parameters (e.g., weight, power, or memory) to account for uncertainties and risks. Margins are allocated 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 the status or performance of a system, process, or activity.

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 Directorate Program Management Council. The forum that evaluates all programs and projects executed within that Mission Directorate and provides input to the MDAA. For programs and Category 1 projects, the MDAA carries forward the MDPMC findings and recommendations to the APMC.

Mission Support Office Requirements. Requirements defined by Mission Support Offices (e.g., procurement and medical).

Non-Applicable Requirement. Any requirement not relevant; not capable of being applied.

Operations Concept (formerly Mission Operations Concept). A description of how the flight system and the ground system are used together to ensure that the concept of operation is reasonable. This might include how mission data of interest, such as engineering or scientific data, are captured, returned to Earth, processed, made available to users, and archived for future reference. The Operations Concept should describe how the flight system and ground system work together across mission phases for launch, cruise, critical activities, science observations, and end of mission to achieve the mission.

Orbital Debris. Any object placed in space by humans that remains in orbit and no longer serves any useful function. Objects range from spacecraft to spent launch vehicle stages to components and also include materials, trash, refuse, fragments, and other objects that are overtly or inadvertently cast off or generated.

Performance Measurement Baseline. The time-phased cost plan for accomplishing all authorized work scope in a project's life cycle, which includes both NASA internal costs and supplier costs. The project's performance against the PMB is measured using earned value management, if required, or other performance measurement techniques if EVM is not required. The PMB does not include UFE.

Preliminary (document context). Implies that the product has received initial review in accordance with Center best practices. The content is considered correct, though some TBDs may remain. All approvals required by Center policies and procedures have been obtained. Major changes are expected.

Prescribed Requirement. A requirement levied on a lower organizational level by a higher organizational level.

Primary Risks. Those undesirable events having both high probability and high impact/severity.

Principal Investigator. A person who conceives an investigation and is responsible for carrying it out and reporting its results. In some cases, PIs from industry and academia act as project managers for smaller development efforts with NASA personnel providing oversight.

Procurement Strategy Meeting. A forum where management reviews and approves the approach for the Agency's major and other selected procurements. Chaired by the assistant administrator for Procurement (or designee), the Procurement Strategy Meeting (PSM) addresses and documents information, activities, and decisions required by the FAR and NFS and incorporates NASA strategic guidance and decisions from the ASM strategic acquisition meeting to ensure the alignment of the individual procurement action with NASA's portfolio and mission.

Program. A strategic investment by a Mission Directorate or Mission Support Office that has a defined architecture and/or technical approach, requirements, funding level, and management structure that initiates and directs one or more projects. A program implements a strategic direction that the Agency has identified as needed to accomplish Agency goals and objectives. (See Section 2.1.2.)

Program Commitment Agreement. The contract between the AA and the responsible MDAA that authorizes transition from Formulation to Implementation of a program. (See Appendix D.)

Program/Project Management Requirements. Requirements that focus on how NASA and Centers perform program and project management activities.

Program Plan. The document that establishes the program's baseline for Implementation, signed by the MDAA, Center Director(s), 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.

Programmatic Authority. Programmatic Authority includes the Mission Directorates and their respective program and project managers. Individuals in these organizations are the official voices for their respective areas. Programmatic Authority sets, oversees, and ensures conformance to applicable programmatic requirements.

Programmatic Requirements. Requirements set by the Mission Directorate, program, project, and PI, if applicable. These include strategic scientific and exploration requirements, system performance requirements, safety requirements, and schedule, cost, and similar nontechnical constraints.

Project. A space flight project is a specific investment identified in a Program Plan having defined requirements, a life-cycle cost, a beginning, and an end. A project also has a management structure and may have interfaces to other projects, agencies, and international partners. A project yields new or revised products that directly address NASA's strategic goals.

Project Plan. The document that establishes the project's baseline for Implementation, signed by the responsible program manager, Center Director, project manager, and the MDAA, if required. (See Appendix H.)

Rebaselining. The process that results in a change to a project's Agency Baseline Commitment.

Reimbursable Program/Project. A project (including work, commodities, or services) for customers other than NASA for which reimbursable agreements have been signed by both the customer and NASA. The customer provides funding for the work performed on their behalf.

Replanning. The process by which a program or project updates or modifies its plans.

Request for Action/Review Item Discrepancy. The most common names for the comment forms that reviewers submit during life-cycle reviews that capture their comments, concerns, and/or issues about the product or documentation. Often, RIDs are used in a more formal way, requiring boards to disposition them and having to get agreements with the submitter, project, and board members for their disposition and closeout. RFAs are often treated more informally, almost as suggestions that may or may not be reacted to.

Reserves. Obsolete term. See Unallocated Future Expenses.

Residual Risk. The remaining risk that exists after all mitigation actions have been implemented or exhausted in accordance with the risk management process. (See NPD 8700.1.)

Risk. In the context of mission execution, risk is the potential for performance shortfalls, which may be realized in the future, with respect to achieving explicitly established and stated performance requirements. The performance shortfalls may be related to any one or more of the following mission execution domains: (1) safety, (2) technical, (3) cost, and (4) schedule. (See NPR 8000.4, Agency Risk Management Procedural Requirements.)

Risk Assessment. An evaluation of a risk item that determines: (1) what can go wrong, (2) how likely is it to occur, (3) what the consequences are, (4) what the uncertainties are that are associated with the likelihood and consequences, and (5) what the mitigation plans are.

Risk Management. Risk management includes risk-informed decision making (RIDM) and continuous risk management (CRM) in an integrated framework. RIDM informs systems engineering decisions through better use of risk and uncertainty information in selecting alternatives and establishing baseline requirements. CRM manages risks over the course of the development and the Implementation Phase of the life cycle to ensure that safety, technical, cost, and schedule requirements are met. This is done to foster proactive risk management, to better inform decision making through better use of risk information, and then to more effectively manage Implementation risks by focusing the CRM process on the baseline performance requirements emerging from the RIDM process. (See NPR 8000.4, Agency Risk Management Procedural Requirements.) These processes are applied at a level of rigor commensurate with the complexity, cost, and criticality of the program.

Risk-Informed Decision Making. A risk-informed decision-making process uses a diverse set of performance measures (some of which are model-based risk metrics) along with other considerations within a deliberative process to inform decision making.

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.

Safety and Mission Assurance Requirements. Requirements defined by the SMA organization related to safety and mission assurance.

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

Signature. A distinctive mark, characteristic, or thing that indicates identity; one's name as written by oneself.

Single-Project Programs. These programs tend to have long development and/or operational lifetimes, represent a large investment of Agency resources, and have contributions from multiple organizations/agencies. These programs frequently combine program and project management approaches, which they document through tailoring.

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

Standards. Formal documents that establish a norm, requirement, or basis for comparison, a reference point to measure or evaluate against. A technical standard, for example, establishes uniform engineering or technical criteria, methods, processes, and practices. (Refer to NPR 7120.10, Technical Standards for NASA Programs and Projects.)

Standing Review Board. The board responsible for conducting independent reviews (life cycle and special) of a program/project and providing objective, expert judgments to the convening authorities. The reviews are conducted in accordance with approved Terms of Reference (ToR) and life-cycle requirements per this document and NPR 7123.1.

Success Criteria. That portion of the top-level requirements that defines what is to be achieved to successfully satisfy NASA Strategic Plan objectives addressed by the program or project.

Suppliers. Each project office is a customer having a unique, multi-tiered hierarchy of suppliers to provide it products and services. A supplier may be a contractor, grantee, another NASA Center, university, international partner, or other government agency. Each project supplier is also a customer if it has authorized work to a supplier lower in the hierarchy.

Supply Chain. The specific group of suppliers and their interrelationships that is necessary to design, develop, manufacture, launch, and service the program or project. This encompasses all levels within a space system, including providers of raw materials, components, subsystems, systems, systems integrators, and services.

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.

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

Tailoring. The process used to adjust or seek relief from a prescribed requirement to accommodate the needs of a specific task or activity (e.g., program or project). The tailoring process results in the generation of deviations and waivers depending on the timing of the request.

Technical Authority. Part of NASA's system of checks and balances that provides independent oversight of programs and projects in support of safety and mission success through the selection of individuals at delegated levels of authority. These individuals are the Technical Authorities. Technical Authority delegations are formal and traceable to the Administrator. Individuals with Technical Authority are funded independently of a program or project.

Technical Authority Requirements. Requirements invoked by OCE, OSMA, and Office of the Chief Health and Medical Officer (OCHMO) documents (e.g., NPRs or technical standards cited as program or project requirements) or contained in Center institutional documents. These requirements are the responsibility of the office or organization that established the requirement unless delegated elsewhere.

Technical Standard. Common and repeated use of rules, conditions, guidelines, or characteristics for products or related processes and production methods and related management systems practices; the definition of terms, classification of components; delineation of procedures; specification of dimensions, materials, performance, designs, or operations; measurement of quality and quantity in describing materials, processes, products, systems, services, or practices; test methods and sampling procedures; or descriptions of fit and measurements of size or strength. (Source: OMB Circular No. A-119, Federal Participation in the Development and Use of Voluntary Consensus Standards and in Conformity Assessment Activities.) (See NPR 7120.10, Technical Standards for NASA Programs and Projects.)

Technology Readiness Level. Provides a scale against which to measure the maturity of a technology. TRLs range from 1, Basic Technology Research, to 9, Systems Test, Launch, and Operations. Typically, a TRL of 6 (i.e., technology demonstrated in a relevant environment) is required for a technology to be integrated into a flight system. (See Systems Engineering Handbook NASA/SP-2007-6105 Rev 1, p. 296 for more information on TRL levels and technology assessment.)

Termination Review. A review initiated by the Decision Authority for the purpose of securing a recommendation as to whether to continue or terminate a program or project. Failing to stay within the parameters or levels specified in controlling documents will result in consideration of a termination review.

Terms of Reference. A document specifying the nature, scope, schedule, and ground rules for an independent review or independent assessment.

Threshold Science Requirements. The mission performance requirements necessary to achieve the minimum science acceptable for the investment. In some AOs used for competed missions, threshold science requirements may be called the "science floor" for the mission. (Also see Baseline Science Requirements.)

Tightly Coupled Programs. Programs with multiple projects that execute portions of a mission(s). No single project is capable of implementing a complete mission. Typically, multiple NASA Centers contribute to the program. Individual projects may be managed at different Centers. The program may also include other agency or international partner contributions.

Unallocated Future Expenses. The portion of estimated cost required to meet specified confidence level that cannot yet be allocated to the specific project WBS sub-elements because the estimate includes probabilistic risks and specific needs that are not known until these risks are realized.

Uncoupled Programs. Programs implemented under a broad theme and/or a common program implementation concept, such as providing frequent flight opportunities for cost-capped projects selected through AO or NASA Research Announcements. Each such project is independent of the other projects within the program.

Validation. The process of showing proof that the product accomplishes the intended purpose based on stakeholder expectations. May be determined by a combination of test, analysis, demonstration, and inspection. (Answers the question, "Am I building the right product?")

Verification. Proof of compliance with requirements. Verification may be determined by a combination of test, analysis, demonstration, and inspection. (Answers the question, "Did I build the product right?")

Waiver. A documented authorization releasing a program or project from meeting a requirement after the requirement is put under configuration control at the level the requirement will be implemented.

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

Appendix B. Acronyms

Appendix C. Compliance Matrix

Template Instructions

The Compliance Matrix documents the program's or project's compliance with the requirements of NPR 7120.5 or how the program or project is tailoring the requirements in accordance with paragraph 3.5. The matrix lists:

• the paragraph reference,

• the NPR 7120.5 requirement statement,

• the requirement owner (the organization or individual responsible for the requirement),

• whether tailoring authority is held at Headquarters for the requirement,

• the organization or individual to whom the requirement applies (MDAA, CD, PM),

• a "Comply?" column to describe applicability or intent to tailor,

• the "Justification" column to justify how tailoring is to be applied, and

• the "Approval" column, when signatures are required to approve tailoring.

The "Requirement Owner" column designates which organization is responsible for maintaining the requirement for the Agency. The head of the requirement owner's organization has the authority for tailoring unless this authority has been formally delegated. An "X" indicates the Headquarters' requirements owner has retained approval authority for tailoring of the requirement. When there is no "X" in the "Tailor" column, tailoring authority may have been delegated by the responsible organization. In this case, program and project managers should work with the Center representative of the responsible organization (e.g., OSMA) to determine if tailoring authority has been delegated to a Center person and, if so, who the delegated authority is. Note that OCE delegations can be found in the "Letter of Delegation" located on the OCE tab under the "Other Policy Documents" menu in the NASA On-Line Directives Information System (NODIS).

The next three columns ("MDAA," "CD," and "PM") designate to whom the requirement applies. An "A" in the column indicates applicability.

The "Comply?" column is filled in by the program or project to identify the program's or project's approach to the requirement. The project inserts an "FC" for "fully compliant," "T" for "tailored," or "NA" for a requirement that is "not applicable," per paragraph 3.5.4. The column titled "Justification" documents the rationale for tailoring, documents how the requirement will be tailored, or justifies why the requirement is not applicable. It is expected that much of the rationale will already have been developed in retrievable program and/or project records and can simply be referenced (in an appropriate, accessible form). The level of documentation should be commensurate with the significance of departure from the norm and is determined by the requirements owner or as delegated. In the case where evaluation indicates that the tailoring of a requirement increases risk, evidence of official acceptance of that risk should be provided as referenced in retrievable program or project records. Columns in the Compliance Matrix can be adjusted to accommodate the necessary information.

For tailored requirements, the name, title, and signature of the responsible authority (requirement owner or delegate) goes in the "Approval" column to indicate that approval to tailor has been obtained from the head of the organization responsible for the requirement (or as delegated) with any required concurrences. The requirement owner consults with the other organizations that were involved in the establishment of the specific requirement and obtains the concurrence of those organizations having a substantive interest. The Compliance Matrix is submitted as part of the Formulation Agreement, Program Plan, or Project Plan. Redundant signatures are not required in the "Approval" column of the Compliance Matrix, if the requirements owner is already a required signatory (e.g., MDAA, CD, Program Manager, and Project Manager) on the Formulation Agreement, Program Plan, or Project Plan. An example of this would be OCE requirements that have been delegated to the Center Director (as designated by a blank in the "tailor" column and the "Letter of Delegation"). In this case, a separate signature by the Center Director is not required in the "Approval" column since the Center Director is a signatory on the plan. However, if tailoring was proposed for a requirement by an owner who isn't normally a signatory on the Formulation Agreement, Program Plan, or Project Plan (e.g., OSMA), the program or project manager should obtain the signature of the approving official in the "Approval" column of the Compliance Matrix prior to submitting the plan for final signature.

The Compliance Matrix is provided to streamline the waiver and deviation process described in paragraph 3.5. If the Compliance Matrix is completed in accordance with these instructions, it meets the requirements for requesting tailoring and serves as a group submittal for waivers to NPR 7120.5. Once the Formulation Agreement or Program or Project Plan is signed, the tailoring is approved. A copy is forwarded to OCE. If the Compliance Matrix changes or if compliance is phased for existing programs or projects, updated versions of the Compliance Matrix are incorporated into an approved Formulation Agreement or Program or Project Plan revision.

Approver Acronyms:

Appendix C. Compliance Matrix

Template Instructions

The Compliance Matrix documents the program's or project's compliance with the requirements of NPR 7120.5 or how the program or project is tailoring the requirements in accordance with paragraph 3.5. The matrix lists:

• the paragraph reference,

• the NPR 7120.5 requirement statement,

• the requirement owner (the organization or individual responsible for the requirement),

• whether tailoring authority is held at Headquarters for the requirement,

• the organization or individual to whom the requirement applies (MDAA, CD, PM),

• a "Comply?" column to describe applicability or intent to tailor,

• the "Justification" column to justify how tailoring is to be applied, and

• the "Approval" column, when signatures are required to approve tailoring.

The "Requirement Owner" column designates which organization is responsible for maintaining the requirement for the Agency. The head of the requirement owner's organization has the authority for tailoring unless this authority has been formally delegated. An "X" indicates the Headquarters' requirements owner has retained approval authority for tailoring of the requirement. When there is no "X" in the "Tailor" column, tailoring authority may have been delegated by the responsible organization. In this case, program and project managers should work with the Center representative of the responsible organization (e.g., OSMA) to determine if tailoring authority has been delegated to a Center person and, if so, who the delegated authority is. Note that OCE delegations can be found in the "Letter of Delegation" located on the OCE tab under the "Other Policy Documents" menu in the NASA On-Line Directives Information System (NODIS).

The next three columns ("MDAA," "CD," and "PM") designate to whom the requirement applies. An "A" in the column indicates applicability.

The "Comply?" column is filled in by the program or project to identify the program's or project's approach to the requirement. The project inserts an "FC" for "fully compliant," "T" for "tailored," or "NA" for a requirement that is "not applicable," per paragraph 3.5.4. The column titled "Justification" documents the rationale for tailoring, documents how the requirement will be tailored, or justifies why the requirement is not applicable. It is expected that much of the rationale will already have been developed in retrievable program and/or project records and can simply be referenced (in an appropriate, accessible form). The level of documentation should be commensurate with the significance of departure from the norm and is determined by the requirements owner or as delegated. In the case where evaluation indicates that the tailoring of a requirement increases risk, evidence of official acceptance of that risk should be provided as referenced in retrievable program or project records. Columns in the Compliance Matrix can be adjusted to accommodate the necessary information.

For tailored requirements, the name, title, and signature of the responsible authority (requirement owner or delegate) goes in the "Approval" column to indicate that approval to tailor has been obtained from the head of the organization responsible for the requirement (or as delegated) with any required concurrences. The requirement owner consults with the other organizations that were involved in the establishment of the specific requirement and obtains the concurrence of those organizations having a substantive interest. The Compliance Matrix is submitted as part of the Formulation Agreement, Program Plan, or Project Plan. Redundant signatures are not required in the "Approval" column of the Compliance Matrix, if the requirements owner is already a required signatory (e.g., MDAA, CD, Program Manager, and Project Manager) on the Formulation Agreement, Program Plan, or Project Plan. An example of this would be OCE requirements that have been delegated to the Center Director (as designated by a blank in the "tailor" column and the "Letter of Delegation"). In this case, a separate signature by the Center Director is not required in the "Approval" column since the Center Director is a signatory on the plan. However, if tailoring was proposed for a requirement by an owner who isn't normally a signatory on the Formulation Agreement, Program Plan, or Project Plan (e.g., OSMA), the program or project manager should obtain the signature of the approving official in the "Approval" column of the Compliance Matrix prior to submitting the plan for final signature.

The Compliance Matrix is provided to streamline the waiver and deviation process described in paragraph 3.5. If the Compliance Matrix is completed in accordance with these instructions, it meets the requirements for requesting tailoring and serves as a group submittal for waivers to NPR 7120.5. Once the Formulation Agreement or Program or Project Plan is signed, the tailoring is approved. A copy is forwarded to OCE. If the Compliance Matrix changes or if compliance is phased for existing programs or projects, updated versions of the Compliance Matrix are incorporated into an approved Formulation Agreement or Program or Project Plan revision.

Approver Acronyms:

Appendix D. Program Commitment Agreement Template

D.1 PCA Title Page

Figure D-1 Program Commitment Agreement Title Page

D.2 PCA Template

PROGRAM COMMITMENT AGREEMENT
(PROGRAM TITLE)

1.0 PROGRAM OBJECTIVES

Identify the broad program objectives. Describe the program's relationship to Mission Directorate goals and objectives as documented in the Directorate's plan. 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

Describe 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 to be included in the program as of the writing date. Specify the type of program (i.e., single-project, uncoupled, loosely coupled, or tightly coupled) and the basis for that classification.

3.0 PROGRAM AUTHORITY

Describe the NASA organizational structure for managing the program and projects from the MDAA to the NASA Center project managers. Include lines of authority and reporting, Center(s) responsibilities, the governing Program Management Councils (PMCs) for the oversight of the program and its known projects, and the approving official for new projects. Identify any delegated Decision Authority, per Section 2.3 of this NPR.

4.0 TECHNICAL PERFORMANCE COMMITMENT

Summarize the technical performance requirements, identifying baselines and thresholds needed to achieve the program objectives, as applicable. If the objectives include a technical performance target (goal) in addition to a threshold requirement, the commitment could be stated as a range. Demonstrate traceability to Agency strategic goals and outcomes and Agency requirements.

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 timeframe for the SDR or MDR.

3. Target date or timeframe for the PDR or the start of implementation.

4. Start of operations.

5. End of prime operations and/or disposal, if applicable.

6. Other milestones or time periods, as appropriate, for a specific program/project.

6.0 COST COMMITMENT

Provide the estimated cost range for the program for the ten-year period beginning in the current fiscal year at a level of detail that identifies the approved individual projects. Identify the constraints and assumptions used to develop this estimated cost range and specifically identify those assumptions that drive the range. This cost range should contain all costs necessary to perform the program, including, but not limited to, customary project activities, required technology developments, facilities costs, launch vehicles, tracking, operations and sustainment, data analysis, and disposal. Either reference the most recent Agency budget to provide the first five years of the estimated program cost or provide the budget required for the next five years. The cost range should be updated when program content changes, such as the addition of new projects entering Implementation or when the estimated cost changes. Reference the annual budget contained in the Integrated Budget and Performance Document (IBPD) for cost phasing. The cost range should be updated when program content changes, such as the addition of new projects entering Implementation.

7.0 ACQUISITION STRATEGY

Provide a high-level summary of the Acquisition Plan (described in Appendix G, Section 3.4) to reflect the results of the process for acquisition process and the Acquisition Strategy Meeting (ASM).

8.0 HIGH-RISK AREAS

Identify the areas of highest risk for the program (covering safety, technical, institutional, cost, and schedule issues) in which failure may result in changes to the program/project baseline cost, schedule, safety, or technical performance requirements. This section should identify, where possible, the specific risk drivers, such as high-risk technologies upon which the program is dependent, and mitigation options.

9.0 INTERNAL AGREEMENTS

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

10.0 EXTERNAL AGREEMENTS

Explain the involvement of external organizations, other agencies, or international support necessary to meet the program objectives. Include a brief overview of the program/project relationships with such external organizations. 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 REVIEWS

Specify the program and project life-cycle reviews (per figures 2-2, 2-3, 2-4, and 2-5 in Chapter 2) that are required to be conducted during the Implementation Phase. Include any other requirements, e.g., the ASM, and any known unique considerations, e.g., international participation. Specify the considerations that will be used to trigger a discussion on the need for a PIR with the NASA AA (see Section 2.4.4.1 and Considerations for a PIR in Appendix A.)

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

13.0 WAIVERS AND DEVIATIONS

Identify known waivers or deviations that will be sought for the program. Provide a 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, including revisions that reflect all waivers to the original PCA. This log includes the information shown in Table D-1 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.

Table D-1 Sample Program Commitment Agreement Activities Log

Appendix E. Formulation Authorization Document Template

E.1 Program FAD Title Page

Figure E-1 Program Formulation Authorization Document Title Page

E.2 Project FAD Title Page

Figure E-2 Project Formulation Authorization Document Title Page

E.3 Program/Project FAD Template

[Program/Project Name] Formulation Authorization Document

[short title or acronym][

1.0 PURPOSE

Describe the purpose of the program/project, including a clear traceability from the goals and objectives in the Mission Directorate Strategies 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 Mission Directorate Associate Administrator (MDAA) to the NASA Center program/project managers, as applicable. Include lines of authority, coordination, and reporting. For projects and single-project programs, the Formulation Authorization Agreement (FAD) provides the basis for the project's Formulation Agreement.

3.0 PROGRAM/PROJECT GOALS AND OBJECTIVES

Describe the level or scope of work, goals, and objectives to be accomplished in the Formulation Phase, Formulation cost targets and 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 known constraints related to their efforts (e.g., the program/project will 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 known constraints related to their efforts (e.g., the program/project will be co-funded by the external participant).

6.0 BUDGET AND COST ESTIMATE

Identify, by fiscal year, the funding that will be committed to the program/project during each year of project Formulation. If the Formulation period is less than five years, provide estimated annual costs through the next five years. For projects, provide an estimated life-cycle cost range that is consistent with this five-year cost runout.

7.0 SCHEDULE

For each project, provide the planned date for the completion of Phase A and estimated completion of Phase B. Provide an estimated date (or range) for the completion of project development. Specify the planned prime operations period.

8.0 LIFE-CYCLE REVIEWS

Specify the program and project life-cycle reviews (per figures 2-2, 2-3, 2-4, and 2-5 in

Chapter 2 of this NPR) that are required to be conducted during the Formulation Phase. Include any other requirements, e.g., the ASM, and any known unique considerations, e.g., international participation.

Appendix F. Project Formulation Agreement Template

F.1 Formulation Agreement Template Instructions

F.1.1 The Formulation Agreement represents the project's or single-project program's response to the Formulation Authorization Document. (See Appendix E.) It establishes technical and acquisition work that needs to be conducted during Formulation and defines the schedule and funding requirements during Phase A and Phase B for that work. The Agreement focuses on the project or single-project program activities necessary to accurately characterize the complexity and scope of the project or single-project program; increase understanding of requirements; and identify and mitigate high technical, acquisition, safety, cost, and schedule risks. It identifies and prioritizes the Phase A and Phase B technical and acquisition work that will have the most value and enables the project or single-project program to develop high-fidelity cost and schedule range estimates at KDP B and high-fidelity cost and schedule commitments at KDP C.

F.1.2 The Formulation Agreement serves as a tool for communicating and negotiating the project's or single-project program's Formulation plans and resource allocations with the program and Mission Directorate. It allows for differences in approach between competed versus assigned missions. Variances with NPR 7120.5 product maturities as documented in Appendix I of NPR 7120.5 are identified with supporting rationale in the Agreement. The approved Agreement serves as authorization for these variances. The Agreement is approved and signed at KDP A and is updated and resubmitted for signature at KDP B. The Formulation Agreement for KDP A includes detailed Phase A information and preliminary Phase B information. The Formulation Agreement for KDP B identifies the progress made during Phase A and updates and details Phase B.

F.1.3 Each section of the Formulation Agreement template is required.If a section is not applicable to a particular project or single-project program, the project or single-project program indicates that in the appropriate section and provides a rationale. If a section is applicable but the project or single-project program desires to omit the section or parts of a section, then a waiver or deviation needs to be obtained in accordance with the tailoring process for NPR 7120.5. (See Section 3.5.) Approvals for waivers are documented in the Compliance Matrix, and the Compliance Matrix for this NPR is attached to the Formulation Agreement. If the format of the completed project or single-project Formulation Agreement differs from this template, a cross-reference table indicating where the information for each template paragraph is needs to be provided with the document when it is submitted for the MDAA signature.

F.1.4 The approval signatures of MDAA, the Center Director, and the program manager certify that the Formulation Agreement implements all the Agency's applicable institutional requirements or that the owner of those requirements, e.g., Safety and Mission Assurance, has agreed to the modification of those requirements contained in the Formulation Agreement.

F.1.5 Products developed as part of or as a result of the Formulation Agreement may be incorporated into the Project or Single-Project Program Plan, if appropriate, as the Project or Single-Project Program Plan is developed during Formulation. The project or single-project program may use the preliminary Project or Single-Project Program Plan to describe and control the project's or single-project program's execution as long as the Project or Single-Project Program Plan does not conflict with the Formulation Agreement.

F.2 Formulation Agreement Title Page

Figure F-1 Formulation Agreement Title Page

F.3 Formulation Agreement Template

1.0 Purpose

Describe the purpose of the program/project, including traceability from Formulation Authorization Agreement (FAD). (See Appendix E.)

2.0 Project or Single-Project Program Formulation Framework

Identify the project or single-project program organization chart for Formulation; identify the initial project or single-project program team, key personnel, and responsible Centers and partnerships (as known) that will contribute during Formulation. Define major roles and responsibilities and identify any Boards and Panels that will be used during Formulation for decision making and managing project or single-project program processes.

3.0 Project or Single-Project Program Plan and Project or Single-Project Program Control Plans

Document the project's or single-project program's proposed milestones for delivery of the Project or Single-Project Program Plan and project or single-project program control plans on the project or single-project program schedule and provide rationale for any differences from requirements in product maturities as documented in Appendix I of NPR 7120.5.

4.0 Project or Single-Project Program, System, and Subsystem Requirements Flow Down

Document the project's or single-project program's proposed milestones for flow down of requirements to the project or single-project program, system, and subsystem levels on the project or single-project program schedule, and provide rationale for any differences from requirements in product maturities as documented in Appendix I of NPR 7120.5. Document the project or single-project program schedule for development of any models needed to support requirements development.

5.0 Mission Scenario, Architectures, and Interfaces

Document the project's or single-project program's proposed milestones for producing the mission concept, mission scenario (or design reference mission), concept of operations, and mission, spacecraft, payload, and ground systems architectures down to the level of subsystem interfaces. Include these milestones on the project or single-project program schedule and provide rationale for any differences from requirements documented in the tables in Appendix I of this NPR.

Reference documentation of the feasible concept, concepts already evaluated, and plans for additional concepts to be evaluated during Formulation. Documentation should include ground rules, assumptions, and constraints used for analysis; key architecture drivers, such as redundancy; preliminary key performance parameters; top-level technical parameters and associated margins; and preliminary driving requirements. Documentation should also include feasible candidate architectures; open architecture issues and how and when those issues will be resolved; basic descriptions of each element; and descriptions of interfaces between elements.

At KDP B update the approved concept and architecture, including a preliminary definition of the operations concept and updated description of composition of payload/suite of instruments. Identify the work required to close all architecture and architectural interface issues.

6.0 Trade Studies

Identify spacecraft and ground systems design trade studies planned during phases A and B, including trade studies that address performance versus cost and risk.

7.0 Risk Mitigation

Document plans for managing risks during Formulation. Identify the project's or single-project program's major technical, acquisition, safety, cost, and schedule risks to be addressed during Formulation, including risks likely to drive the project's or single-project program's cost and schedule range estimates at KDP B, and cost and schedule estimates at KDP C. Describe the associated risk mitigation plans. Provide rationale for addressing these risks during Formulation.

Document the project's or single-project program's risk mitigation schedule and funding requirements. Include intermediate milestones and expected progress by KDP B and KDP C.

8.0 Technology Readiness Assessment and Development

[Identify the specific new technologies (Technology Readiness Levels (TRL) less than 6) that are part of this project or single-project program; their criticality to the project's or single-project program's objectives, goals, and success criteria; and the current status of each planned technology development, including TRL and associated risks. Describe the specific activities and risk mitigation plans, the responsible organizations, models, and key tests to ensure that the technology maturity reaches TRL 6 by PDR. (Refer to NPR 7123.1 for TRL definitions.)

Identify off-ramp decision gates and strategies for ensuring there are alternative development paths available if technologies do not mature as expected. Identify potential cost, schedule, or performance impacts if the technology developments do not reach the required maturity levels.

Provide technology development schedules, including intermediate milestones and funding requirements, during Phases A and B for each identified technology development to achieve TRL 6 by PDR. Describe expected status of each technology development at SRR, MDR/SDR, and PDR. Reference the preliminary or final Technology Development Plan for details as applicable. Describe how the program will transition technologies from the development stage to manufacturing, production, and insertion into the end system. Identify any potential costs and risks associated with the transition to manufacturing, production, and insertion. Develop and document appropriate mitigation plans for the identified risks.

9.0 Engineering Development Assessment, Prototyping, and Software Models

Identify major engineering development risks and any engineering prototyping or software model development that needs to be accomplished during phases A and B to reduce development risk (Engineering development risks include components and assemblies that have not been previously built or flown in the planned environment or that have been significantly modified in functionality, interfaces, power consumption, size, or use of materials.). Provide rationale and potential impacts to project or single-project program performance, cost, and schedule if development risks are not addressed. Describe the scope of the prototyping and modeling activities and the expected reduction of cost and risk by performing this work during Formulation. Include the project or single-project program's testing philosophy, including functional, environmental, and qualification testing, any life testing and protoflight test plans, and rationale.

Describe the prototypes and software models to be built, their fidelity (form, fit, and function, etc.), test environments and objectives, and test dates. Identify any design alternatives if irresolvable problems are encountered.

Provide prototype and software model development and test schedules, including intermediate milestones and funding requirements during phases A and B. Describe expected status and accomplishments for each prototype or software model at SRR, MDR/SDR, and PDR.]

Focus during Phase A should be on component and subassembly prototypes built to approximately the correct size, mass, and power, with "flight-like" parts and materials, and tested in a laboratory environment over the extremes of temperature and radiation (if relevant). Focus during Phase B should be on testing form, fit, and function prototypes over the extremes of what will be experienced during flight.

Identify key performance parameters, associated modeling methodologies, and methods for tracking KPPs throughout Formulation. Identify key performance parameters, associated modeling methodologies, and methods for tracking KPPs throughout Formulation. In addition, identify any rocket propulsion testing and provide for analysis and selection of propulsion testing sites in accordance with NPD 8081.1, NASA Chemical Rocket Propulsion Testing.

10.0 Heritage Assessment and Validation

Identify the major heritage hardware and software assumptions and associated risks and the activities and reviews planned to validate those assumptions during Formulation. Identify schedule and funding requirements for those activities.

11.0 Acquisition Strategy and Long-lead Procurements

Identify acquisition and partnership plans during Formulation. Document the project's or single-project program's proposed milestones for in-house work and procurements, including completing any Contract Statements of Work (SOW) and Requests for Proposal (RFP) during the Formulation phase. Identify long-lead procurements to be initiated and provide associated rationale. Identify procurements of material and services necessary for life-cycle sustainment. Identify anticipated partnerships (other government agencies and U.S. and international partners), if any, including roles and contributed items and plans for getting commitments for contributions and finalizing open inter-agency agreements, domestic partnerships, and foreign contributions. Point to the preliminary or final Acquisition Plan for details, as applicable.

Identify major acquisition risks, including long-lead procurement risks and partnership risks.

Identify funding requirements for procurement activities, long-lead procurements, and partnerships.

12.0 Formulation Phase Reviews

Identify and provide schedules for the project or single-project program life-cycle reviews (SRR, SDR/MDR) and the system and subsystem-level reviews to be held during Formulation. Include inheritance reviews, prototype design reviews, technology readiness reviews, fault protection reviews, etc., necessary to reduce risk and enable more accurate cost and schedule range estimates at KDP B and more accurate cost and schedule estimates at KDP C.

13.0 Formulation Phase Cost and Schedule Estimates

Document the project's or single-project program's Formulation Phase schedule and phased funding requirements, including cost and schedule margins, aligned with the project or single-project program Work Breakdown Structure (WBS). Identify the critical path.

Ensure that all funding requirements in this Agreement are included and clearly identifiable. Summarize funding requirements both in dollars and estimated percent of total costs phases A-D.

Ensure that the schedules for all technology development, engineering prototyping, procurement and risk mitigation activities, and milestones identified in this Agreement are included and clearly identifiable. Provide schedule details to the appropriate level to justify Formulation funding requirements (typically subsystem level).

Include any additional milestones required in product maturities as documented in Appendix I in NPR 7120.5, including the development of life-cycle cost and schedule ranges due at KDP B and the JCL at KDP C, if required.

Identify the schedule for developing the project's or single-project program's EVM capabilities, if EVM is required.

14.0 Leading Indicators

Document the project's or single-project program's programmatic and technical leading indicators for the Formulation Phase.

Project or single-project programs develop and maintain the status of a set of programmatic and technical leading indicators to ensure proper progress and management of the project or single-project program are achieved during Formulation. These include:

• Requirement Trends (percent growth, TBD/TBR (to be resolved) closures, number of requirement changes);

• Interface Trends (percent Interface Control Document (ICD) approvals, TBD/TBR burn down, number of interface requirement changes);

• Review Trends (Review Item Discrepancy (RID)/Request for Action (RFA)/Action Item burn down per review);

• Formulation Cost Trends (Plan, actual, UFE, NOA);

• Schedule Trends (slack/float, critical milestone dates);

• Staffing Trends (Full-Time Employee (FTE)/Work Year Equivalent (WYE));

• Technical Performance Measures (Mass margin, power margin); and

• Additional project or single-project program-specific indicators, as needed.

These indicators are further explained in the NASA Space Flight Program and Project Management Handbook, the NASA Project Planning and Control Handbook, and in a white paper on the Program and Project Management Communities of Practice Web site.

15.0 Appendices

Appendix A Acronyms
Appendix B Definitions
Appendix C Compliance Matrix for this NPR

Appendix G. Program Plan Template

G.1 Template Instructions

G.1.1 The Program Plan is an agreement among the program manager, Center Director, and Mission Directorate Associate Administrator (MDAA). Other Center Directors providing a significant contribution to the program also concur with the Program Plan to document their commitment to provide required Center resources. The Program Plan defines the goals and objectives of the program, the environment within which the program operates, and the Management Agreement commitments of the program, including identifying the high-level requirements on both the program and each constituent project. These requirements on the project may be in the body of the Plan or added as appendices. The Program Plan is to be updated and approved during the program life cycle if warranted by changes in the stated Management Agreement commitments.

G.1.2 In this Program Plan template, all subordinate plans, collectively called control plans, are required unless they are not applicable. They are based on requirements in NASA Policy Directives (NPDs) and NASA Procedural Requirements (NPRs) that affect program/project planning. For tightly coupled programs, the SMA Plan, Risk Management Plan, Product Data and Life-Cycle Management (PDLM) Plan, and SEMP are required to be stand-alone plans with summaries and references provided in the Program Plan. If a control plan is not applicable to a particular program, indicate that by stating it is not applicable in the appropriate section and provide a rationale. The remaining control plans can either be part of the Program Plan or separate stand-alone documents referenced in the appropriate part of the Program Plan. In the case of the latter, the Program Plan contains a summary of and reference to the stand-alone document; the approval authority for the stand-alone Control Plan is the program manager.

G.1.3 Each section of the Program Plan template is required. If a section is not applicable to a particular program, indicate in the appropriate section and provide a rationale. If a section is applicable but the program desires to omit the section or parts of a section, then a waiver needs to be obtained in accordance with the requirement tailoring process for NPR 7120.5. Approvals are documented in Part 4.0, Waivers or Deviations Log, of the Program Plan. In addition, the program's Compliance Matrix for this NPR is attached to the Program Plan. If the format of the completed Program Plan differs from this template, a cross-reference table indicating where the information for each template paragraph is needs to be provided with the document when it is submitted for MDAA signature.

G.1.4 The approval signatures of the MDAA, the Center Director, and the program manager certify that the Program Plan implements all the Agency's applicable institutional requirements or that the authority responsible for those requirements, e.g., Safety and Mission Assurance, have granted a deviation or waiver to the modification of those requirements.

G.1.5 Single-project programs may combine the Program and Project Plans into a single document if the MDAA agrees.

G.2 Program Plan Title Page

Figure G-1 Program Plan Title Page

G.3 Program Plan Template

[Program Name] Program Plan]
[short title or acronym]

1.0 PROGRAM OVERVIEW

1.1 Introduction

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

1.2 Goals and Objectives

State program goals and specific objectives, and provide clear traceability to the Agency's strategic goals and to Mission Directorate strategic goals and objectives. Program performance goals and their relationship to NASA program goals set forth in NPD 1001.0, NASA Strategic Plan should be expressed in an objective, quantifiable, and measurable form. Goals and objectives should include specific commitments to safety and mission success.

1.3 Program Architecture

Briefly describe the architecture of the program, its major components, and the way they will be integrated. Describe how the major program components are intended to operate together, and with legacy systems, as applicable, to achieve program goals and objectives. Specify the type of program (i.e., single-project, uncoupled, loosely coupled, or tightly coupled) and the basis for that classification.

Provide a summary-level technical description of the program, including constituent projects and operations concepts. The description should also include mission description, program interfaces, facilities, logistics concepts, planned mission results, and data analysis, archiving, and reporting. Identify driving ground rules and assumptions and major constraints affecting program systems development (e.g., cost, launch window, required launch vehicle, mission planetary environment, fuel/engine design, and foreign partners).

Describe how the program will relate to other organizations within and outside NASA. Reference Section 3.4, Acquisition Plan of this document (below) or provide the following information here:

For organizations within NASA, describe the roles of each in the program, including technology efforts, space communications, and launch services.

For organizations outside NASA, describe the role of each in the program, including other government agencies, academia, industry, and international partners as they are known at the start of the program.

1.4 Stakeholder Definition

Identify the main stakeholders of the program (e.g., PI, science community, technology community, public, education community, and Mission Directorate sponsor(s)) and the process to be used within the program to ensure stakeholder advocacy.

1.5 Program Authority, Management Approach, and Governance Structure

Describe the program management structure, including each participating organization's responsibilities. Identify:

Describe the chain of accountability and decision path outlining the roles and responsibilities of the Mission Directorate sponsor(s), program manager, Center Director, and other authorities (including the Technical Authorities), as required. Provide a high-level description of the project's organization within the program, showing the chain of accountability. Describe clear lines of authority from projects and Centers to the program, and to the Mission Directorate, and frequency of reporting for each. Illustrate the organization graphically. Describe the process by which projects are formulated, approved, and terminated.

1.6 Implementation Approach

Describe briefly the implementation approach of the program, including any applicable guidance or direction from the ASM review, the acquisition strategy (e.g., in-house, NASA Centers, and contractor primes), partners, and partner contributions, if appropriate. Include make-or-buy decision plans and trade studies.

Describe how knowledge management, lessons learned, and participating NASA Centers' implementation policies and practices will be utilized in the execution of the program. (Note: For tightly coupled programs, the program manager, the NASA Chief Engineer, and the Center Chief Engineers (or designees) participating in the program establish the engineering best practices for the program. These decisions are documented here.) Document the agreements on the use of implementation policies and practices between the program manager and participating NASA Centers in this section (or in appendices to the document), along with the program's approach to ensuring that interfaces do not increase risk to mission success.

2.0 PROGRAM BASELINES

2.1 Requirements Baseline

Program Requirements. Document the high-level program requirements, including performance, safety, and programmatic requirements and correlate them to Agency and Mission Directorate strategic objectives and requirements. Describe the process by which program requirements are verified for compliance. Describe the process for controlling changes to program requirements. Document the traceability of requirements that flow down from Agency- and Center-level policy to the program and from the program to projects.

Requirements Documentation. For tightly coupled programs and single-project programs, decompose these high-level requirements into requirements on constituent projects or systems, specified herein or in a separate, configuration-controlled, program requirements document to be prepared by the program manager and approved by the MDAA. Additional concurrences may be required at the option of the NASA AA. There may also be subordinate project requirements documents controlled at lower levels.

For uncoupled or loosely coupled programs, apply these high-level requirements to generate the program's requirements on each constituent project. This documentation is controlled by the Mission Directorate and may be located in the body of the Program Plan or in a subsequent appendix. Requirements thus documented, and any subsequent changes, require approval of the program manager, MDAA, and participating Center Director(s).

Program Requirements on Projects. For each project, provide a top-level description, including the mission's science or exploration objectives. Document the project's category, governing PMC, and risk classification. Describe the project's mission, performance, and safety requirements. For science missions, include both baseline science requirements and threshold science requirements. (See Appendix A for definitions.) Identify the mission success criteria for each project based on the threshold science requirements. State each requirement in objective, quantifiable, and verifiable terms. Identify the project's principal schedule milestones, including Preliminary Design Review (PDR), Critical Design Review (CDR), launch, mission operational-critical milestones, and the planned decommissioning date. State the development and/or total life-cycle cost constraints on the project. Set forth any budget constraints by fiscal year. State the specific conditions under which a project Termination Review would be triggered. Describe any additional requirements on the project (e.g., international partners). If the mission characteristics indicate a greater emphasis is necessary on maintaining technical, cost, or schedule, then identify which is most important (e.g., state 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, as for a technology demonstration mission).

2.2 WBS Baseline

Provide the program's Work Breakdown Structure (WBS) and WBS dictionary down to the project level developed in accordance with guidance provided by the NASA WBS Handbook, NASA/SP-2010-3404, which can be found on the OCE tab under the "Other Policy Documents" menu in NODIS. The WBS will support cost and schedule allocation down to a project level that allows for unambiguous cost reporting.

2.3 Schedule Baseline

Present a summary of the program's integrated master schedule (IMS), including all critical milestones, major events, life-cycle reviews, and KDPs throughout the program life cycle. The summary of the master schedule should include the logical relationships (interdependencies) for the various program elements and projects and critical paths, as appropriate. Identify driving ground rules, assumptions, and constraints affecting the schedule baseline.

2.4 Resource Baseline

Present the program's funding requirements by fiscal year. State the New Obligation Authority (NOA) in real-year dollars for all years - prior, current, and remaining. The funding requirements are to be consistent with the program's WBS and include funding for all cost elements required by the Agency's full-cost accounting procedures. Funding requirements are to be consistent with the budget. Provide a breakdown of the program's funding requirements to the WBS Level 2 elements. Present the program-specific (i.e., not individual project) workforce requirements by fiscal year, consistent with the program's funding requirements and WBS. Throughout the Implementation Phase, baselines are to be based on the joint cost and schedule confidence level in accordance with NPD 1000.5 and NPR 7120.5.

Describe the program infrastructure requirements (acquisition, renovations, and/or use of real property/facilities, aircraft, personal property, and information technology). Identify means of meeting infrastructure requirements through synergy with other existing and planned programs and projects to avoid duplication of facilities and capabilities. Identify necessary upgrades or new developments, including those needed for environmental compliance.

Identify driving ground rules, assumptions, and constraints affecting the resource baseline.

Document the project Commitment Baselines.

2.5 Joint Cost and Schedule Confidence Level

For implementation and beyond for single-project and tightly coupled programs, document the joint cost and schedule confidence level approved by the Decision Authority.

3.0 PROGRAM CONTROL PLANS

3.1 Technical, Schedule, and Cost Control Plan

Document how the program plans to control program requirements, technical design, schedule, and cost to achieve its high-level requirements. This control plan will include the following:

Describe the plan to monitor and control the requirements, technical design, schedule, and cost of the program.

Describe the program's performance measures in objective, quantifiable, and measurable terms and document how the measures are traced from the program high-level requirements. Establish baseline and threshold values for the performance metrics to be achieved at each Key Decision Point (KDP), as appropriate. In addition, document the mission success criteria associated with the program-level requirements that, if not met, trigger consideration of a Termination Review.

Tightly coupled and single-project programs also develop and maintain the status of a set of programmatic and technical leading indicators to ensure proper progress and management of the program. These include:

Requirement Trends (percent growth, TBD/TBR closures, number of requirement changes); Interface Trends (percent ICD approval, TBD/TBR burn down, number of interface requirement changes);